You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Will Glass-Husain (JIRA)" <ji...@apache.org> on 2005/09/19 00:58:54 UTC
[jira] Resolved: (VELOCITY-286) CORBA structs used for data transfer - need field introspection
[ http://issues.apache.org/jira/browse/VELOCITY-286?page=all ]
Will Glass-Husain resolved VELOCITY-286:
----------------------------------------
Resolution: Invalid
Assign To: (was: Velocity-Dev List)
There's a field introspector written by a Velocity user in the Wiki. You can configure velocity.properties to reference this.
See
http://wiki.apache.org/jakarta-velocity/PublicFieldUberspect
> CORBA structs used for data transfer - need field introspection
> ---------------------------------------------------------------
>
> Key: VELOCITY-286
> URL: http://issues.apache.org/jira/browse/VELOCITY-286
> Project: Velocity
> Type: Bug
> Components: Source
> Versions: 1.4
> Environment: Operating System: other
> Platform: Other
> Reporter: Paul Steyn
>
> I read the FAQ in the developer guide regarding field introspection, but still
> require it with good reason.
> Background:
> Our company uses CORBA for middleware. The most portable and efficient method
> of data transfer from our application servers is by using CORBA structs
> (including nested structs).
> Problem:
> Attributes in CORBA structs map to Java public fields.
> Velocityâs FieldMethodizer wonât work because:
> The mapped attributes are not static fields as is required by the
> FieldMethodizer. Even if it allowed instance fields, we would still have a
> problem because our structs are often nested. The FieldMethodizer would
> therefore need to handle the nesting recursively.
> Writing accessors wont work because:
> The Java code for the CORBA structs are generated by vendor idl2java. We would
> therefore have to duplicate all these data transfer classes with similar ones
> that have assessor methods AND write copy code to get the data from the struct
> objects into our objects. However, we have TONS of these data transfer
> structs. We will not be able to get approval from business to develop a whole
> data layer (with assessor methods and copy code) JUST to cater for Velocity.
> The reason we want to use Velocity is to save time.
> From a purist point of view I can understand why you donât want to allow field
> introspection i.e. âWe don't do that because we wish to promote the idea that
> you hide your raw data in your data objectsâ. However, the FACT is that Java
> classes allow public fields i.e. Java allows one to expose the data in objects â
> the reasons are irrelevant. Therefore, from a completeness point of view,
> Velocity should allow field introspection.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org