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