EJBContext cannot be injected in 3.1-SNAPSHOT

2008-06-27 Thread Karsten.Ohme
Hi,

I can inject the session context successfully with:

@Resource
private SessionContext ctx;

But when I only what to have the EJBContext

@Resource
private EJBContext ctx;

it cannot be injected.

Is this intended? Well, SessionContext is fine, but I was wondering why
the super interface cannot be injected.

Regards,
Karsten


Re: EJBContext cannot be injected in 3.1-SNAPSHOT

2008-06-27 Thread David Blevins


On Jun 27, 2008, at 7:24 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] 
 wrote:



Hi,

I can inject the session context successfully with:

   @Resource
   private SessionContext ctx;

But when I only what to have the EJBContext

   @Resource
   private EJBContext ctx;

it cannot be injected.

Is this intended? Well, SessionContext is fine, but I was wondering  
why

the super interface cannot be injected.


In general, we don't check isAssignable on injection types, primarily  
cause it gets very hairy around business interfaces.  But we could  
probably support this particular use case.


-David



Re: AW: @ApplicationException(rollback=true) ignored from external API

2008-06-27 Thread David Blevins
I think there was something with the binaries I published.  Had to  
clean out all the old snapshots and redeploy to a clean repo before I  
could get the updates to come down.


Try it again. (clean out the openejb section of your repo for good  
measure).


-David


On Jun 27, 2008, at 8:45 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] 
 wrote:




No, does not work. See the attached sample project.

In the API is the annotated ServiceAddressException class. But the  
unit tests fails.


Regards,
Karsten



-Ursprüngliche Nachricht-
Von: David Blevins [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 27. Juni 2008 07:32
An: users@openejb.apache.org
Betreff: Re: @ApplicationException(rollback=true) ignored
from external API


On Jun 25, 2008, at 4:42 PM, Karsten Ohme wrote:


David Blevins schrieb:

On Jun 25, 2008, at 9:38 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED]

wrote:
I run a test which provokes an application exception. The

exception

is defined in the same module and annotated with
@ApplicationException(rollback=true). The Exception is

rolled back.

Fine.

Another test checks also an exception. The exception is

not from an

EJB module, but from an imported API. The exception has the same
annotation, but the transaction is not rolled back. It

seams to me

that the annotation in this class is ignored.

We definitely don't check the annotations at runtime,

simply because

you can override them via the deployment descriptor so the

merged

set of meta data is the only safe thing to execute against

at runtime

(not if we expect to pass the tck anyway ;).  But as you

point out we

just check the module itself for @ApplicationException annotated
classes.


I don't have them annotated in the deployment descriptor.

This would

be very uncomfortable, because each module which uses the exception
from the other module would have to do this.


Agree, that would be an unnecessary pain.


Hmm...
Is the annotated exception class listed in any of the

throws clauses

of the business interface methods in module B?



Yes, it is.


(where module A has the exception class, module B does

not) If so, we

could expand our support to looking there too in addition

to scraping

the module jar.


Would be nice.


Ok. Implemented that technique.  Should you decide to
override the app exception in the deployment descriptor of
module B, for example, that will work too.

New 3.1-SNAPSHOT binaries have been published.  Give it a try
and let us know if it works out.

-David



applicationexceptiontest.zip




Re: AW: @ApplicationException(rollback=true) ignored from external API

2008-06-27 Thread Karsten Ohme

David Blevins schrieb:
I think there was something with the binaries I published.  Had to clean 
out all the old snapshots and redeploy to a clean repo before I could 
get the updates to come down.


Try it again. (clean out the openejb section of your repo for good 
measure).


Well at the moment I cannot get 
org.apache.openejb:xbean-finder:jar:3.4-r636443-SNAPSHOT form the repo. 
I will try it again tomorrow.


Regards,
Karsten


-David


On Jun 27, 2008, at 8:45 AM, [EMAIL PROTECTED] 
[EMAIL PROTECTED] wrote:




No, does not work. See the attached sample project.

In the API is the annotated ServiceAddressException class. But the 
unit tests fails.


Regards,
Karsten



-Ursprüngliche Nachricht-
Von: David Blevins [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 27. Juni 2008 07:32
An: users@openejb.apache.org
Betreff: Re: @ApplicationException(rollback=true) ignored
from external API


On Jun 25, 2008, at 4:42 PM, Karsten Ohme wrote:


David Blevins schrieb:

On Jun 25, 2008, at 9:38 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED]

wrote:
I run a test which provokes an application exception. The

exception

is defined in the same module and annotated with
@ApplicationException(rollback=true). The Exception is

rolled back.

Fine.

Another test checks also an exception. The exception is

not from an

EJB module, but from an imported API. The exception has the same
annotation, but the transaction is not rolled back. It

seams to me

that the annotation in this class is ignored.

We definitely don't check the annotations at runtime,

simply because

you can override them via the deployment descriptor so the

merged

set of meta data is the only safe thing to execute against

at runtime

(not if we expect to pass the tck anyway ;).  But as you

point out we

just check the module itself for @ApplicationException annotated
classes.


I don't have them annotated in the deployment descriptor.

This would

be very uncomfortable, because each module which uses the exception
from the other module would have to do this.


Agree, that would be an unnecessary pain.


Hmm...
Is the annotated exception class listed in any of the

throws clauses

of the business interface methods in module B?



Yes, it is.


(where module A has the exception class, module B does

not) If so, we

could expand our support to looking there too in addition

to scraping

the module jar.


Would be nice.


Ok. Implemented that technique.  Should you decide to
override the app exception in the deployment descriptor of
module B, for example, that will work too.

New 3.1-SNAPSHOT binaries have been published.  Give it a try
and let us know if it works out.

-David



applicationexceptiontest.zip