On 08/02/2011 10:08, ant elder wrote:
On Tue, Feb 8, 2011 at 9:56 AM, Simon Laws<simonsl...@googlemail.com> wrote:
I can see that relaxing the current spec restrictiveness would be
difficult as things would break in some circumstances, but it does
seem like there will be situations when the assembler really knows it
would be fine but even so they can't get the PBR optimization because
the impls aren't coded with the @AllowsPassByReference annotation.
Isn't that a similar situation to where the remotable annotation was
added to the interface SCDL element, and there could be a similar
allowsPassByReference attribute added to the service and reference
SCDL elements?
...ant
Hi Ant.
Can you say a bit more about the "situations when the assembler really
knows it would be fine"? Reading previous posts to this thread doesn't
convince me that that is the case.
Simon
We'll have to wait for Raymond to see if thats anything like his
situation, but there are lots of ways the assembler could know, he may
well have full access to the source but still be limited in making any
updates due to production lifecycle or control issues. This seems like
a similar situation as Java EE appservers have and I believe many
appservers have mechanisims for overriding and enabling PBR support in
their ORB or EJB modules to gain performance benefits.
...ant
Folks,
One possibility to start with would be to add a Tuscany extension attribute which could be used by
an Assembler to mark a particular service and/or reference as "AllowsPassByReference".
This would cope with the situation where the Java components are not marked, but the assembler knows
enough about them to know that the marking is correct.
Yours, Mike.