You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Ivan <xh...@gmail.com> on 2009/06/11 08:18:57 UTC
When to set openejb.strict.interface.declaration
Hi,
With the latest openejb 3.1.1 snapshot, I found if the env property
openejb.strict.interface.declaration is not set to true, both local and
remote interfaces are added to SessionBeanInfo.businessLocal.
Here is bean structure:
1. interface *LocalInterface *{}
2. interface *RemoveInterface *{}
3. class *MyBeanBase *implements *LocalInterface, RemoteInterface* {}
4 @Stateful
@Remote({RemoteInterface.class})
@Local({LocalInterface.class})
class *MyBean* extends *MyBaseBean *implements *LocalInterface,
RemoteInterface* {}
So is it by design, and do I always to set that env property with the
value true, or I miss anything ? Thanks !
--
Ivan
Re: When to set openejb.strict.interface.declaration
Posted by Ivan <xh...@gmail.com>.
Thanks, David !
2009/7/3 David Blevins <da...@visi.com>
> I've committed patches OPENEJB-1041 and OPENEJB-1042. Thanks very much for
> those. I fear there may be more bugs like OPENEJB-1042. Admittedly, I'm
> not very fond of the allowed operations code we have. The whole thing needs
> to be simplified. But that's for another day.
>
> Just a note, you've been pinging me offline about committing looking at the
> patches. Feel free to ping me online, I don't mind at all. It does help
> keep things on the radar. All contributors are encouraged to do the same as
> JIRA comments and patches are easily overlooked. Also, if it is a TCK
> related issue, definitely feel encouraged to post the related test names to
> the Geronimo TCK list.
>
> Keep up the great work, Ivan!
>
>
> -David
>
>
>
> On Jun 24, 2009, at 12:15 AM, Ivan wrote:
>
> A testcase is attached to 1042.
>> Thanks !
>> Ivan
>>
>> 2009/6/24 Ivan <xh...@gmail.com>
>>
>> By the way, 1039 should be a new feature for EJB 3.1.1.
>>> And for 1041/1042, I just compared the codes between 3.1.1 and 3.0.1,
>>> and
>>> copied what 3.0.1 did. :-)
>>> Ivan
>>>
>>> 2009/6/24 Ivan <xh...@gmail.com>
>>>
>>> Sure, I will try it. But in my environment, after I applied those
>>> patches,
>>>
>>>> it works as defined. :-(
>>>> Ivan
>>>>
>>>>
>>>> 2009/6/24 David Blevins <da...@visi.com>
>>>>
>>>>
>>>> On Jun 14, 2009, at 6:41 AM, Ivan wrote:
>>>>>
>>>>> 2009/6/11 David Blevins <da...@visi.com>
>>>>>
>>>>>>
>>>>>> On Jun 10, 2009, at 11:18 PM, Ivan wrote:
>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> With the latest openejb 3.1.1 snapshot, I found if the env property
>>>>>>>> openejb.strict.interface.declaration is not set to true, both local
>>>>>>>> and
>>>>>>>> remote interfaces are added to SessionBeanInfo.businessLocal.
>>>>>>>> Here is bean structure:
>>>>>>>>
>>>>>>>> 1. interface *LocalInterface *{}
>>>>>>>> 2. interface *RemoveInterface *{}
>>>>>>>> 3. class *MyBeanBase *implements *LocalInterface, RemoteInterface*
>>>>>>>> {}
>>>>>>>> 4 @Stateful
>>>>>>>> @Remote({RemoteInterface.class})
>>>>>>>> @Local({LocalInterface.class})
>>>>>>>> class *MyBean* extends *MyBaseBean *implements *LocalInterface,
>>>>>>>> RemoteInterface* {}
>>>>>>>>
>>>>>>>> So is it by design, and do I always to set that env property with
>>>>>>>> the
>>>>>>>> value true, or I miss anything ? Thanks !
>>>>>>>>
>>>>>>>>
>>>>>>>> The intent was that it would have to be explicitly tagged as both
>>>>>>> @Local
>>>>>>> and @Remote for it to be considered both. Seems like we need to
>>>>>>> smarten up
>>>>>>> the code so that it won't use local as a default when it was
>>>>>>> explicitly
>>>>>>> tagged as @Remote.
>>>>>>>
>>>>>>>
>>>>>> Hi Ivan,
>>>>>
>>>>> The patch for OPENEJB-1039 doesn't have any affect on the scenario
>>>>> above.
>>>>> I started creating a rather large test case to better define the
>>>>> requirements and in the process noticed what I think might be a second
>>>>> potential bug in the existing code. Need to get a little more time to
>>>>> investigate.
>>>>>
>>>>> In the meantime, is it possible you can supply a test case to reproduce
>>>>> OPENEJB-1042 ?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Ivan
>>>>
>>>>
>>>
>>>
>>> --
>>> Ivan
>>>
>>>
>>
>>
>> --
>> Ivan
>>
>
>
--
Ivan
Re: When to set openejb.strict.interface.declaration
Posted by David Blevins <da...@visi.com>.
I've committed patches OPENEJB-1041 and OPENEJB-1042. Thanks very
much for those. I fear there may be more bugs like OPENEJB-1042.
Admittedly, I'm not very fond of the allowed operations code we have.
The whole thing needs to be simplified. But that's for another day.
Just a note, you've been pinging me offline about committing looking
at the patches. Feel free to ping me online, I don't mind at all. It
does help keep things on the radar. All contributors are encouraged
to do the same as JIRA comments and patches are easily overlooked.
Also, if it is a TCK related issue, definitely feel encouraged to post
the related test names to the Geronimo TCK list.
Keep up the great work, Ivan!
-David
On Jun 24, 2009, at 12:15 AM, Ivan wrote:
> A testcase is attached to 1042.
> Thanks !
> Ivan
>
> 2009/6/24 Ivan <xh...@gmail.com>
>
>> By the way, 1039 should be a new feature for EJB 3.1.1.
>> And for 1041/1042, I just compared the codes between 3.1.1 and
>> 3.0.1, and
>> copied what 3.0.1 did. :-)
>> Ivan
>>
>> 2009/6/24 Ivan <xh...@gmail.com>
>>
>> Sure, I will try it. But in my environment, after I applied those
>> patches,
>>> it works as defined. :-(
>>> Ivan
>>>
>>>
>>> 2009/6/24 David Blevins <da...@visi.com>
>>>
>>>
>>>> On Jun 14, 2009, at 6:41 AM, Ivan wrote:
>>>>
>>>> 2009/6/11 David Blevins <da...@visi.com>
>>>>>
>>>>> On Jun 10, 2009, at 11:18 PM, Ivan wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>> With the latest openejb 3.1.1 snapshot, I found if the env
>>>>>>> property
>>>>>>> openejb.strict.interface.declaration is not set to true, both
>>>>>>> local
>>>>>>> and
>>>>>>> remote interfaces are added to SessionBeanInfo.businessLocal.
>>>>>>> Here is bean structure:
>>>>>>>
>>>>>>> 1. interface *LocalInterface *{}
>>>>>>> 2. interface *RemoveInterface *{}
>>>>>>> 3. class *MyBeanBase *implements *LocalInterface,
>>>>>>> RemoteInterface* {}
>>>>>>> 4 @Stateful
>>>>>>> @Remote({RemoteInterface.class})
>>>>>>> @Local({LocalInterface.class})
>>>>>>> class *MyBean* extends *MyBaseBean *implements
>>>>>>> *LocalInterface,
>>>>>>> RemoteInterface* {}
>>>>>>>
>>>>>>> So is it by design, and do I always to set that env property
>>>>>>> with the
>>>>>>> value true, or I miss anything ? Thanks !
>>>>>>>
>>>>>>>
>>>>>> The intent was that it would have to be explicitly tagged as both
>>>>>> @Local
>>>>>> and @Remote for it to be considered both. Seems like we need to
>>>>>> smarten up
>>>>>> the code so that it won't use local as a default when it was
>>>>>> explicitly
>>>>>> tagged as @Remote.
>>>>>>
>>>>>
>>>> Hi Ivan,
>>>>
>>>> The patch for OPENEJB-1039 doesn't have any affect on the
>>>> scenario above.
>>>> I started creating a rather large test case to better define the
>>>> requirements and in the process noticed what I think might be a
>>>> second
>>>> potential bug in the existing code. Need to get a little more
>>>> time to
>>>> investigate.
>>>>
>>>> In the meantime, is it possible you can supply a test case to
>>>> reproduce
>>>> OPENEJB-1042 ?
>>>>
>>>> Thanks!
>>>>
>>>> -David
>>>>
>>>>
>>>
>>>
>>> --
>>> Ivan
>>>
>>
>>
>>
>> --
>> Ivan
>>
>
>
>
> --
> Ivan
Re: When to set openejb.strict.interface.declaration
Posted by Ivan <xh...@gmail.com>.
A testcase is attached to 1042.
Thanks !
Ivan
2009/6/24 Ivan <xh...@gmail.com>
> By the way, 1039 should be a new feature for EJB 3.1.1.
> And for 1041/1042, I just compared the codes between 3.1.1 and 3.0.1, and
> copied what 3.0.1 did. :-)
> Ivan
>
> 2009/6/24 Ivan <xh...@gmail.com>
>
> Sure, I will try it. But in my environment, after I applied those patches,
>> it works as defined. :-(
>> Ivan
>>
>>
>> 2009/6/24 David Blevins <da...@visi.com>
>>
>>
>>> On Jun 14, 2009, at 6:41 AM, Ivan wrote:
>>>
>>> 2009/6/11 David Blevins <da...@visi.com>
>>>>
>>>> On Jun 10, 2009, at 11:18 PM, Ivan wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>> With the latest openejb 3.1.1 snapshot, I found if the env property
>>>>>> openejb.strict.interface.declaration is not set to true, both local
>>>>>> and
>>>>>> remote interfaces are added to SessionBeanInfo.businessLocal.
>>>>>> Here is bean structure:
>>>>>>
>>>>>> 1. interface *LocalInterface *{}
>>>>>> 2. interface *RemoveInterface *{}
>>>>>> 3. class *MyBeanBase *implements *LocalInterface, RemoteInterface* {}
>>>>>> 4 @Stateful
>>>>>> @Remote({RemoteInterface.class})
>>>>>> @Local({LocalInterface.class})
>>>>>> class *MyBean* extends *MyBaseBean *implements *LocalInterface,
>>>>>> RemoteInterface* {}
>>>>>>
>>>>>> So is it by design, and do I always to set that env property with the
>>>>>> value true, or I miss anything ? Thanks !
>>>>>>
>>>>>>
>>>>> The intent was that it would have to be explicitly tagged as both
>>>>> @Local
>>>>> and @Remote for it to be considered both. Seems like we need to
>>>>> smarten up
>>>>> the code so that it won't use local as a default when it was explicitly
>>>>> tagged as @Remote.
>>>>>
>>>>
>>> Hi Ivan,
>>>
>>> The patch for OPENEJB-1039 doesn't have any affect on the scenario above.
>>> I started creating a rather large test case to better define the
>>> requirements and in the process noticed what I think might be a second
>>> potential bug in the existing code. Need to get a little more time to
>>> investigate.
>>>
>>> In the meantime, is it possible you can supply a test case to reproduce
>>> OPENEJB-1042 ?
>>>
>>> Thanks!
>>>
>>> -David
>>>
>>>
>>
>>
>> --
>> Ivan
>>
>
>
>
> --
> Ivan
>
--
Ivan
Re: When to set openejb.strict.interface.declaration
Posted by Ivan <xh...@gmail.com>.
By the way, 1039 should be a new feature for EJB 3.1.1.
And for 1041/1042, I just compared the codes between 3.1.1 and 3.0.1, and
copied what 3.0.1 did. :-)
Ivan
2009/6/24 Ivan <xh...@gmail.com>
> Sure, I will try it. But in my environment, after I applied those patches,
> it works as defined. :-(
> Ivan
>
>
> 2009/6/24 David Blevins <da...@visi.com>
>
>
>> On Jun 14, 2009, at 6:41 AM, Ivan wrote:
>>
>> 2009/6/11 David Blevins <da...@visi.com>
>>>
>>> On Jun 10, 2009, at 11:18 PM, Ivan wrote:
>>>>
>>>> Hi,
>>>>
>>>>> With the latest openejb 3.1.1 snapshot, I found if the env property
>>>>> openejb.strict.interface.declaration is not set to true, both local and
>>>>> remote interfaces are added to SessionBeanInfo.businessLocal.
>>>>> Here is bean structure:
>>>>>
>>>>> 1. interface *LocalInterface *{}
>>>>> 2. interface *RemoveInterface *{}
>>>>> 3. class *MyBeanBase *implements *LocalInterface, RemoteInterface* {}
>>>>> 4 @Stateful
>>>>> @Remote({RemoteInterface.class})
>>>>> @Local({LocalInterface.class})
>>>>> class *MyBean* extends *MyBaseBean *implements *LocalInterface,
>>>>> RemoteInterface* {}
>>>>>
>>>>> So is it by design, and do I always to set that env property with the
>>>>> value true, or I miss anything ? Thanks !
>>>>>
>>>>>
>>>> The intent was that it would have to be explicitly tagged as both @Local
>>>> and @Remote for it to be considered both. Seems like we need to smarten
>>>> up
>>>> the code so that it won't use local as a default when it was explicitly
>>>> tagged as @Remote.
>>>>
>>>
>> Hi Ivan,
>>
>> The patch for OPENEJB-1039 doesn't have any affect on the scenario above.
>> I started creating a rather large test case to better define the
>> requirements and in the process noticed what I think might be a second
>> potential bug in the existing code. Need to get a little more time to
>> investigate.
>>
>> In the meantime, is it possible you can supply a test case to reproduce
>> OPENEJB-1042 ?
>>
>> Thanks!
>>
>> -David
>>
>>
>
>
> --
> Ivan
>
--
Ivan
Re: When to set openejb.strict.interface.declaration
Posted by Ivan <xh...@gmail.com>.
Sure, I will try it. But in my environment, after I applied those patches,
it works as defined. :-(
Ivan
2009/6/24 David Blevins <da...@visi.com>
>
> On Jun 14, 2009, at 6:41 AM, Ivan wrote:
>
> 2009/6/11 David Blevins <da...@visi.com>
>>
>> On Jun 10, 2009, at 11:18 PM, Ivan wrote:
>>>
>>> Hi,
>>>
>>>> With the latest openejb 3.1.1 snapshot, I found if the env property
>>>> openejb.strict.interface.declaration is not set to true, both local and
>>>> remote interfaces are added to SessionBeanInfo.businessLocal.
>>>> Here is bean structure:
>>>>
>>>> 1. interface *LocalInterface *{}
>>>> 2. interface *RemoveInterface *{}
>>>> 3. class *MyBeanBase *implements *LocalInterface, RemoteInterface* {}
>>>> 4 @Stateful
>>>> @Remote({RemoteInterface.class})
>>>> @Local({LocalInterface.class})
>>>> class *MyBean* extends *MyBaseBean *implements *LocalInterface,
>>>> RemoteInterface* {}
>>>>
>>>> So is it by design, and do I always to set that env property with the
>>>> value true, or I miss anything ? Thanks !
>>>>
>>>>
>>> The intent was that it would have to be explicitly tagged as both @Local
>>> and @Remote for it to be considered both. Seems like we need to smarten
>>> up
>>> the code so that it won't use local as a default when it was explicitly
>>> tagged as @Remote.
>>>
>>
> Hi Ivan,
>
> The patch for OPENEJB-1039 doesn't have any affect on the scenario above.
> I started creating a rather large test case to better define the
> requirements and in the process noticed what I think might be a second
> potential bug in the existing code. Need to get a little more time to
> investigate.
>
> In the meantime, is it possible you can supply a test case to reproduce
> OPENEJB-1042 ?
>
> Thanks!
>
> -David
>
>
--
Ivan
Re: When to set openejb.strict.interface.declaration
Posted by David Blevins <da...@visi.com>.
On Jun 14, 2009, at 6:41 AM, Ivan wrote:
> 2009/6/11 David Blevins <da...@visi.com>
>
>> On Jun 10, 2009, at 11:18 PM, Ivan wrote:
>>
>> Hi,
>>> With the latest openejb 3.1.1 snapshot, I found if the env property
>>> openejb.strict.interface.declaration is not set to true, both
>>> local and
>>> remote interfaces are added to SessionBeanInfo.businessLocal.
>>> Here is bean structure:
>>>
>>> 1. interface *LocalInterface *{}
>>> 2. interface *RemoveInterface *{}
>>> 3. class *MyBeanBase *implements *LocalInterface, RemoteInterface*
>>> {}
>>> 4 @Stateful
>>> @Remote({RemoteInterface.class})
>>> @Local({LocalInterface.class})
>>> class *MyBean* extends *MyBaseBean *implements *LocalInterface,
>>> RemoteInterface* {}
>>>
>>> So is it by design, and do I always to set that env property with
>>> the
>>> value true, or I miss anything ? Thanks !
>>>
>>
>> The intent was that it would have to be explicitly tagged as both
>> @Local
>> and @Remote for it to be considered both. Seems like we need to
>> smarten up
>> the code so that it won't use local as a default when it was
>> explicitly
>> tagged as @Remote.
Hi Ivan,
The patch for OPENEJB-1039 doesn't have any affect on the scenario
above. I started creating a rather large test case to better define
the requirements and in the process noticed what I think might be a
second potential bug in the existing code. Need to get a little more
time to investigate.
In the meantime, is it possible you can supply a test case to
reproduce OPENEJB-1042 ?
Thanks!
-David
Re: When to set openejb.strict.interface.declaration
Posted by David Blevins <da...@visi.com>.
Thanks, Ivan. Post the test names on the TCK list if you have time.
The first one seems related, the second one is very strange.
-David
On Jul 19, 2009, at 7:55 PM, Ivan wrote:
> Hi, David:
> I tried the ejb 3.0 test, I guess the changes for it should only
> take
> effect on EJB 3.0
> 1. With the stirct option on (true), there are many cases failed,
> those
> errors are something like Jndi(name=***) cannot be bound to
> Ejb(deployment-id=***.jar/***). Name already taken by
> Ejb(deployment-id=***.jar/***).
> .2 With the strict option off (false), there are nine cases
> failed. The
> error is org.apache.openejb.NoSuchApplicationException,
> PersistenceUnit
> '***' not found for EXTENDED ref '***'
> I will check the detailed info once I finish the other stuff on my
> hands. Anyway, I would remove the strict option setting from Geronimo
> soon.
>
> 2009/7/18 Ivan <xh...@gmail.com>
>
>> Many thanks, David !
>> I will let you know the results as soon as possible ^_^
>>
>> 2009/7/18 David Blevins <da...@visi.com>
>>
>> Ok the logic for business interface processing is in there and
>> looking
>>> solid based on the test case I wrote and some tck feedback.
>>>
>>> The new code seems much more clean and straight forward. I
>>> recommend
>>> everyone update and take a look at the AnnotationDeployer's
>>> processSessionInterfaces() method and let me know what you think.
>>> I can
>>> document it more while it's still fresh in my head, so do feel
>>> encouraged to
>>> say "what's this part about", etc.
>>>
>>> Ivan, this seems to fix OPENEJB-1039 by my trials with the TCK,
>>> though I
>>> haven't run the whole thing. Give it a try with strict mode off
>>> and let me
>>> know how it goes.
>>>
>>> Still need to keep flushing out the BusinessInterfacesTest, but it's
>>> pretty large already. In testing negative scenarios (i.e. illegal
>>> annotation usage and whatnot) I discovered a nasty bug in our
>>> Messages.properties support code. Basically, escaping does not
>>> work. So
>>> given the three messages below, the third will not work.
>>>
>>> 1.ann.remote.noAttributes = Ambiguous @Remote() usage on bean class
>>> 2.ann.remote.noAttributes = Ambiguous @Remote() usage on bean
>>> class. Must
>>> list interfaces explicitly in annotation.
>>> 3.ann.remote.noAttributes = When annotating a bean class as
>>> @Remote with
>>> no annotation attributes, the bean must implement exactly one
>>> business
>>> interface, no more and no less. List the remote interfaces
>>> explicitly in
>>> the annotation, such as @Remote(\{{0}\}). Alternatively, apply
>>> the @Remote
>>> annotation to the individual interfaces and remove it from the
>>> bean class.
>>>
>>> The desired output for the third message would look something like
>>> this:
>>>
>>> ---
>>> When annotating a bean class as @Remote with no annotation
>>> attributes, the
>>> bean must implement exactly one business interface, no more and no
>>> less.
>>> List the remote interfaces explicitly in the annotation, such as
>>> @Remote({AccountProcessor.class, Warehouse.class}).
>>> Alternatively, apply
>>> the @Remote annotation to the individual interfaces and remove it
>>> from the
>>> bean class.
>>> ---
>>>
>>> But any attempt to escape { does not work and comes out like
>>> {{0}}, which
>>> is not valid. Will have to take a look.
>>>
>>> -David
>>>
>>>
>>>
>>
>>
>> --
>> Ivan
>>
>
>
>
> --
> Ivan
Re: When to set openejb.strict.interface.declaration
Posted by Ivan <xh...@gmail.com>.
Hi, David:
I tried the ejb 3.0 test, I guess the changes for it should only take
effect on EJB 3.0
1. With the stirct option on (true), there are many cases failed, those
errors are something like Jndi(name=***) cannot be bound to
Ejb(deployment-id=***.jar/***). Name already taken by
Ejb(deployment-id=***.jar/***).
.2 With the strict option off (false), there are nine cases failed. The
error is org.apache.openejb.NoSuchApplicationException, PersistenceUnit
'***' not found for EXTENDED ref '***'
I will check the detailed info once I finish the other stuff on my
hands. Anyway, I would remove the strict option setting from Geronimo
soon.
2009/7/18 Ivan <xh...@gmail.com>
> Many thanks, David !
> I will let you know the results as soon as possible ^_^
>
> 2009/7/18 David Blevins <da...@visi.com>
>
> Ok the logic for business interface processing is in there and looking
>> solid based on the test case I wrote and some tck feedback.
>>
>> The new code seems much more clean and straight forward. I recommend
>> everyone update and take a look at the AnnotationDeployer's
>> processSessionInterfaces() method and let me know what you think. I can
>> document it more while it's still fresh in my head, so do feel encouraged to
>> say "what's this part about", etc.
>>
>> Ivan, this seems to fix OPENEJB-1039 by my trials with the TCK, though I
>> haven't run the whole thing. Give it a try with strict mode off and let me
>> know how it goes.
>>
>> Still need to keep flushing out the BusinessInterfacesTest, but it's
>> pretty large already. In testing negative scenarios (i.e. illegal
>> annotation usage and whatnot) I discovered a nasty bug in our
>> Messages.properties support code. Basically, escaping does not work. So
>> given the three messages below, the third will not work.
>>
>> 1.ann.remote.noAttributes = Ambiguous @Remote() usage on bean class
>> 2.ann.remote.noAttributes = Ambiguous @Remote() usage on bean class. Must
>> list interfaces explicitly in annotation.
>> 3.ann.remote.noAttributes = When annotating a bean class as @Remote with
>> no annotation attributes, the bean must implement exactly one business
>> interface, no more and no less. List the remote interfaces explicitly in
>> the annotation, such as @Remote(\{{0}\}). Alternatively, apply the @Remote
>> annotation to the individual interfaces and remove it from the bean class.
>>
>> The desired output for the third message would look something like this:
>>
>> ---
>> When annotating a bean class as @Remote with no annotation attributes, the
>> bean must implement exactly one business interface, no more and no less.
>> List the remote interfaces explicitly in the annotation, such as
>> @Remote({AccountProcessor.class, Warehouse.class}). Alternatively, apply
>> the @Remote annotation to the individual interfaces and remove it from the
>> bean class.
>> ---
>>
>> But any attempt to escape { does not work and comes out like {{0}}, which
>> is not valid. Will have to take a look.
>>
>> -David
>>
>>
>>
>
>
> --
> Ivan
>
--
Ivan
Re: When to set openejb.strict.interface.declaration
Posted by Ivan <xh...@gmail.com>.
Many thanks, David !
I will let you know the results as soon as possible ^_^
2009/7/18 David Blevins <da...@visi.com>
> Ok the logic for business interface processing is in there and looking
> solid based on the test case I wrote and some tck feedback.
>
> The new code seems much more clean and straight forward. I recommend
> everyone update and take a look at the AnnotationDeployer's
> processSessionInterfaces() method and let me know what you think. I can
> document it more while it's still fresh in my head, so do feel encouraged to
> say "what's this part about", etc.
>
> Ivan, this seems to fix OPENEJB-1039 by my trials with the TCK, though I
> haven't run the whole thing. Give it a try with strict mode off and let me
> know how it goes.
>
> Still need to keep flushing out the BusinessInterfacesTest, but it's pretty
> large already. In testing negative scenarios (i.e. illegal annotation usage
> and whatnot) I discovered a nasty bug in our Messages.properties support
> code. Basically, escaping does not work. So given the three messages
> below, the third will not work.
>
> 1.ann.remote.noAttributes = Ambiguous @Remote() usage on bean class
> 2.ann.remote.noAttributes = Ambiguous @Remote() usage on bean class. Must
> list interfaces explicitly in annotation.
> 3.ann.remote.noAttributes = When annotating a bean class as @Remote with no
> annotation attributes, the bean must implement exactly one business
> interface, no more and no less. List the remote interfaces explicitly in
> the annotation, such as @Remote(\{{0}\}). Alternatively, apply the @Remote
> annotation to the individual interfaces and remove it from the bean class.
>
> The desired output for the third message would look something like this:
>
> ---
> When annotating a bean class as @Remote with no annotation attributes, the
> bean must implement exactly one business interface, no more and no less.
> List the remote interfaces explicitly in the annotation, such as
> @Remote({AccountProcessor.class, Warehouse.class}). Alternatively, apply
> the @Remote annotation to the individual interfaces and remove it from the
> bean class.
> ---
>
> But any attempt to escape { does not work and comes out like {{0}}, which
> is not valid. Will have to take a look.
>
> -David
>
>
>
--
Ivan
Re: When to set openejb.strict.interface.declaration
Posted by David Blevins <da...@visi.com>.
Ok the logic for business interface processing is in there and looking
solid based on the test case I wrote and some tck feedback.
The new code seems much more clean and straight forward. I recommend
everyone update and take a look at the AnnotationDeployer's
processSessionInterfaces() method and let me know what you think. I
can document it more while it's still fresh in my head, so do feel
encouraged to say "what's this part about", etc.
Ivan, this seems to fix OPENEJB-1039 by my trials with the TCK, though
I haven't run the whole thing. Give it a try with strict mode off and
let me know how it goes.
Still need to keep flushing out the BusinessInterfacesTest, but it's
pretty large already. In testing negative scenarios (i.e. illegal
annotation usage and whatnot) I discovered a nasty bug in our
Messages.properties support code. Basically, escaping does not work.
So given the three messages below, the third will not work.
1.ann.remote.noAttributes = Ambiguous @Remote() usage on bean class
2.ann.remote.noAttributes = Ambiguous @Remote() usage on bean class.
Must list interfaces explicitly in annotation.
3.ann.remote.noAttributes = When annotating a bean class as @Remote
with no annotation attributes, the bean must implement exactly one
business interface, no more and no less. List the remote interfaces
explicitly in the annotation, such as @Remote(\{{0}\}).
Alternatively, apply the @Remote annotation to the individual
interfaces and remove it from the bean class.
The desired output for the third message would look something like this:
---
When annotating a bean class as @Remote with no annotation attributes,
the bean must implement exactly one business interface, no more and no
less. List the remote interfaces explicitly in the annotation, such
as @Remote({AccountProcessor.class, Warehouse.class}). Alternatively,
apply the @Remote annotation to the individual interfaces and remove
it from the bean class.
---
But any attempt to escape { does not work and comes out like {{0}},
which is not valid. Will have to take a look.
-David
Re: When to set openejb.strict.interface.declaration
Posted by Ivan <xh...@gmail.com>.
Great !
Thanks, David.
2009/7/9 David Blevins <da...@visi.com>
>
> On Jun 14, 2009, at 6:41 AM, Ivan wrote:
>
> 2009/6/11 David Blevins <da...@visi.com>
>>
>> On Jun 10, 2009, at 11:18 PM, Ivan wrote:
>>>
>>> Hi,
>>>
>>>> With the latest openejb 3.1.1 snapshot, I found if the env property
>>>> openejb.strict.interface.declaration is not set to true, both local and
>>>> remote interfaces are added to SessionBeanInfo.businessLocal.
>>>> Here is bean structure:
>>>>
>>>> 1. interface *LocalInterface *{}
>>>> 2. interface *RemoveInterface *{}
>>>> 3. class *MyBeanBase *implements *LocalInterface, RemoteInterface* {}
>>>> 4 @Stateful
>>>> @Remote({RemoteInterface.class})
>>>> @Local({LocalInterface.class})
>>>> class *MyBean* extends *MyBaseBean *implements *LocalInterface,
>>>> RemoteInterface* {}
>>>>
>>>> So is it by design, and do I always to set that env property with the
>>>> value true, or I miss anything ? Thanks !
>>>>
>>>>
>>> The intent was that it would have to be explicitly tagged as both @Local
>>> and @Remote for it to be considered both. Seems like we need to smarten
>>> up
>>> the code so that it won't use local as a default when it was explicitly
>>> tagged as @Remote.
>>>
>>
> Some online followup for OPENEJB-1039. A few other business interface
> issues have been discovered by both Ivan and I. I checked in a new TestCase
> called BusinessInterfacesTest to cover those and really all the many rules
> regarding the many ways of declaring business interfaces either implicitly
> or explicitly. Still a work in progress and doesn't yet run without
> failures.
>
> Once complete, though, it should give us better-than-tck coverage for both
> the standard functionality and our extensions to it. Enough to help us
> straighten out the current issues as well as protect us from breaking things
> again when we get around to implementing the EJB 3.1 no-interface bean view
> and async interfaces.
>
> -David
>
>
--
Ivan
Re: When to set openejb.strict.interface.declaration
Posted by David Blevins <da...@visi.com>.
On Jun 14, 2009, at 6:41 AM, Ivan wrote:
> 2009/6/11 David Blevins <da...@visi.com>
>
>> On Jun 10, 2009, at 11:18 PM, Ivan wrote:
>>
>> Hi,
>>> With the latest openejb 3.1.1 snapshot, I found if the env property
>>> openejb.strict.interface.declaration is not set to true, both
>>> local and
>>> remote interfaces are added to SessionBeanInfo.businessLocal.
>>> Here is bean structure:
>>>
>>> 1. interface *LocalInterface *{}
>>> 2. interface *RemoveInterface *{}
>>> 3. class *MyBeanBase *implements *LocalInterface, RemoteInterface*
>>> {}
>>> 4 @Stateful
>>> @Remote({RemoteInterface.class})
>>> @Local({LocalInterface.class})
>>> class *MyBean* extends *MyBaseBean *implements *LocalInterface,
>>> RemoteInterface* {}
>>>
>>> So is it by design, and do I always to set that env property with
>>> the
>>> value true, or I miss anything ? Thanks !
>>>
>>
>> The intent was that it would have to be explicitly tagged as both
>> @Local
>> and @Remote for it to be considered both. Seems like we need to
>> smarten up
>> the code so that it won't use local as a default when it was
>> explicitly
>> tagged as @Remote.
Some online followup for OPENEJB-1039. A few other business interface
issues have been discovered by both Ivan and I. I checked in a new
TestCase called BusinessInterfacesTest to cover those and really all
the many rules regarding the many ways of declaring business
interfaces either implicitly or explicitly. Still a work in progress
and doesn't yet run without failures.
Once complete, though, it should give us better-than-tck coverage for
both the standard functionality and our extensions to it. Enough to
help us straighten out the current issues as well as protect us from
breaking things again when we get around to implementing the EJB 3.1
no-interface bean view and async interfaces.
-David
Re: When to set openejb.strict.interface.declaration
Posted by Ivan <xh...@gmail.com>.
Hi, David
I opened a JIRA 1039 for it, and tried to create a patch, could you pleae
help to review it, thanks !
And another JIRA 1041, it is for ejb entity bean.
Thanks very much !
Ivan
2009/6/11 David Blevins <da...@visi.com>
> On Jun 10, 2009, at 11:18 PM, Ivan wrote:
>
> Hi,
>> With the latest openejb 3.1.1 snapshot, I found if the env property
>> openejb.strict.interface.declaration is not set to true, both local and
>> remote interfaces are added to SessionBeanInfo.businessLocal.
>> Here is bean structure:
>>
>> 1. interface *LocalInterface *{}
>> 2. interface *RemoveInterface *{}
>> 3. class *MyBeanBase *implements *LocalInterface, RemoteInterface* {}
>> 4 @Stateful
>> @Remote({RemoteInterface.class})
>> @Local({LocalInterface.class})
>> class *MyBean* extends *MyBaseBean *implements *LocalInterface,
>> RemoteInterface* {}
>>
>> So is it by design, and do I always to set that env property with the
>> value true, or I miss anything ? Thanks !
>>
>
> The intent was that it would have to be explicitly tagged as both @Local
> and @Remote for it to be considered both. Seems like we need to smarten up
> the code so that it won't use local as a default when it was explicitly
> tagged as @Remote.
>
> Happy to take a patch if you want to take a stab at it.
>
> Nice catch!
>
> -David
>
>
--
Ivan
Re: When to set openejb.strict.interface.declaration
Posted by David Blevins <da...@visi.com>.
On Jun 10, 2009, at 11:18 PM, Ivan wrote:
> Hi,
> With the latest openejb 3.1.1 snapshot, I found if the env property
> openejb.strict.interface.declaration is not set to true, both local
> and
> remote interfaces are added to SessionBeanInfo.businessLocal.
> Here is bean structure:
>
> 1. interface *LocalInterface *{}
> 2. interface *RemoveInterface *{}
> 3. class *MyBeanBase *implements *LocalInterface, RemoteInterface*
> {}
> 4 @Stateful
> @Remote({RemoteInterface.class})
> @Local({LocalInterface.class})
> class *MyBean* extends *MyBaseBean *implements *LocalInterface,
> RemoteInterface* {}
>
> So is it by design, and do I always to set that env property with
> the
> value true, or I miss anything ? Thanks !
The intent was that it would have to be explicitly tagged as both
@Local and @Remote for it to be considered both. Seems like we need
to smarten up the code so that it won't use local as a default when it
was explicitly tagged as @Remote.
Happy to take a patch if you want to take a stab at it.
Nice catch!
-David