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