You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Henning Schmiedehausen (JIRA)" <de...@velocity.apache.org> on 2007/03/08 01:10:41 UTC

[jira] Closed: (VELOCITY-286) CORBA structs used for data transfer - need field introspection

     [ https://issues.apache.org/jira/browse/VELOCITY-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Henning Schmiedehausen closed VELOCITY-286.
-------------------------------------------


> CORBA structs used for data transfer - need field introspection
> ---------------------------------------------------------------
>
>                 Key: VELOCITY-286
>                 URL: https://issues.apache.org/jira/browse/VELOCITY-286
>             Project: Velocity
>          Issue Type: Bug
>          Components: Engine
>    Affects 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.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org