Re: method interceptor is never called

[Jacek Laskowski]

On Mon, Jan 4, 2010 at 10:12 PM, Jacek Laskowski  wrote:
> On Mon, Jan 4, 2010 at 8:16 PM, Christian Bourque
>  wrote:
>
>> There you go! It's a maven project so simply run it with: mvn test
>>
>> You'll see that the second test will fail when it shouldn't...
>
> Failed tests:
>  testWithGenerics(test.test.AppTest)
>
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0
>
> [INFO] 
> 
> [ERROR] BUILD FAILURE
> [INFO] 
> 
>
> Looking into it...will report the findings soon.

Found the issue - openejb doesn't support "Using Generics in EJBs".
See [1] for a workaround that works (I don't mean you should migrate
to WLS though :)). I've just committed corresponding changes to the
interceptor example [2] to let you see what the workaround looks like.
In the nutshell, you should extend the interface with generics with
the one without and annotate it with @Local. It will work.

In the upcoming days I'm going to fix it -
https://issues.apache.org/jira/browse/OPENEJB-1128.

[1] 
http://download.oracle.com/docs/cd/E11035_01/wls100/ejb30/implementing.html#wp1129878
[2] 
https://svn.apache.org/repos/asf/openejb/trunk/openejb3/examples/interceptors

Jacek

-- 
Jacek Laskowski
Notatnik Projektanta Java EE - http://wszystkojawne.pl
p.s. Szukam speca/firmy od grafiki/CSS/HTML

Re: resource adapter config with openEJB

[Jason Russo]

Thanks for responding David.

I've tried to package the adapter in an ear, as well as install the rar
and ejb separately.  In either case, I can see messages in the logs
indicating that the adapter and ejb installed, but for some reason, my
MDB cannot seem to access the adapter.  It appears that openEjb is auto
creating a container that uses the default ActiveMQ adapter instead of
the one I deploy.

This is my openejb-jar.xml:








My resource adapter file is named genscape-generic-adapter.rar.  I'm not
sure what the res-ref-name & res-id I need to provide should be, but
this is what openejb reports in the log when i install the adapter:

2010-01-04 17:38:36,496 - INFO  - Configuring
Service(id=genscape-generic-adapterRA, type=Resource,
provider-id=genscape-generic-adapterRA)
2010-01-04 17:38:36,499 - INFO  - Configuring
Service(id=genscape-generic-adapter, type=Container, provider-id=Default
MDB Container)


However, when I install my MDB, I see the following in the logs, which
suggests that it is using the default ActiveMQ adapter instead of the
one I am trying to reference:

2010-01-04 17:38:36,504 - DEBUG - Beginning
load: /home/jrusso/bin/apache-tomcat-6.0.20/apps/TestMDB.jar
2010-01-04 17:38:36,505 - DEBUG - Using default
'openejb.tempclassloader.skip=none'  Possible values are: none,
annotations, enums or NONE or ALL
2010-01-04 17:38:36,505 - DEBUG - Using default
'openejb.tempclassloader.skip=none'  Possible values are: none,
annotations, enums or NONE or ALL
2010-01-04 17:38:36,508 - DEBUG - Destroying classLoader
urlclassloa...@711090443
2010-01-04 17:38:36,508 - INFO  - Configuring enterprise
application: /home/jrusso/bin/apache-tomcat-6.0.20/apps/TestMDB.jar
2010-01-04 17:38:36,551 - DEBUG - Searching for inherited application
exceptions (see OPENEJB-980) - it doesn't care whether inherited is
true/false
2010-01-04 17:38:36,565 - INFO  - Auto-assigning deployment-id for ejb
TestFioranoMDB: EjbDeployment(deployment-id=TestFioranoMDB)
2010-01-04 17:38:36,795 - INFO  - Configuring Service(id=Default MDB
Container, type=Container, provider-id=Default MDB Container)
2010-01-04 17:38:36,795 - INFO  - Auto-creating a container for bean
TestFioranoMDB: Container(type=MESSAGE, id=Default MDB Container)
2010-01-04 17:38:36,796 - DEBUG - No existing resource found while
attempting to Auto-link unmapped resource-ref 'Default JMS Resource
Adapter' of type 'null' for 'TestFioranoMDB'.  Looked for
Resource(id=Default JMS Resource Adapter) and Resource(id=Default JMS
Resource Adapter)
2010-01-04 17:38:36,796 - INFO  - Configuring Service(id=Default JMS
Resource Adapter, type=Resource, provider-id=Default JMS Resource
Adapter)
2010-01-04 17:38:36,797 - DEBUG - No existing resource found while
attempting to Auto-link unmapped resource-ref 'Default Unmanaged JDBC
Database' of type 'null' for 'TestFioranoMDB'.  Looked for
Resource(id=Default Unmanaged JDBC Database) and Resource(id=Default
Unmanaged JDBC Database)
2010-01-04 17:38:36,798 - INFO  - Configuring Service(id=Default
Unmanaged JDBC Database, type=Resource, provider-id=Default Unmanaged
JDBC Database)
2010-01-04 17:38:36,798 - DEBUG - Using default
'openejb.descriptors.output=false'
2010-01-04 17:38:36,798 - DEBUG - Using default
'openejb.descriptors.output=false'
2010-01-04 17:38:36,800 - DEBUG - Using default
'openejb.validation.output.level=medium'.  Possible values are: terse,
medium, verbose
2010-01-04 17:38:36,800 - INFO  - Enterprise application
"/home/jrusso/bin/apache-tomcat-6.0.20/apps/TestMDB.jar" loaded.

Any ideas?



Jason Russo

Application Developer

Genscape– See the Energy

445 E. Market St, Suite 200

Louisville, KY 40202

Tel: 502-583-2091

www.genscape.com



On Mon, 2010-01-04 at 16:47 -0500, David Blevins wrote:

> On Dec 30, 2009, at 8:25 PM, Jason Russo wrote:
> 
> > Well, I feel a bit dumb, but I think I figured out the problem
> > here.  It
> > seems that the ra.xml within the generic adapter rar package has a tag
> > within the  tag as such:
> >
> >
> >XATransaction
> >
> >
> > Notice the whitespace.  It appears that openEjb chokes with the below
> > error when reading this tag because of the whitespace in between the
> > tag
> > ends.  When I remove the carriage returns and other whitespace, like
> > so:
> >
> >XATransaction
> >
> > The adapter deploys fine.  So I had to rebuild the genericra.rar
> > with a
> > modified ra.xml to correct this tag.  What I don't understand is that
> > there are many other tags in the ra.xml that have the same kind
> > whitespace within them, but openEjb does not have a problem with those
> > tags.  I'm going to suggest that this is a bug.
> 
> Definitely seems so.  Might be something we can just have trimmed
> right that JAXB tree.  Seem to recall there is some easy way to ask
> jaxb to trim text input.
> 
> > So now that I have been able to deploy the generic adapter, I seem to
> > have this problem with getting my MDB to 

Re: Problem Running quartz-app RAR JUnit Test

[David Blevins]

Definitely a bug and *thank you* for digging around and finding it!   
Very appreciated!  It's open source and we're all volunteers, so maybe  
closer to the truth is my wife appreciates it ;)


Anyway, if you can attach a patch here, I'll commit it and mark you  
down as the "fixer"


  https://issues.apache.org/jira/browse/OPENEJB-1127

Happy new year!

-David

On Jan 1, 2010, at 11:20 PM, thabach wrote:



Heya David

I investigated some more and observed that a resource adapter  
project - a
non packed Maven module, like the one in the quartz-app, to be  
precise - is
detected as a Connector module, but does NOT get loaded. A top-level  
"mvn
install" only works for the quartz-app as Maven uses the jar'ed  
quartz-ra as

a dependency, which does get loaded by OpenEJB.

I added the following ra.xml specific code, similar to the one for
ejb-jar.xml and applicaiton.xml in
org.apache.openejb.config.DeploymentsResolver:

public static void loadFrom(Deployments dep, FileUtils path,  
List

jarList) {

..

  
   //
   //  Unpacked "Jar" directory with descriptor
   //
   
   File ejbJarXml = new File(dir, "META-INF" + File.separator +
"ejb-jar.xml");
   if (ejbJarXml.exists()) {
   if (!jarList.contains(dir.getAbsolutePath())) {
   jarList.add(dir.getAbsolutePath());
   }
   return;
   }

   File appXml = new File(dir, "META-INF" + File.separator +
"application.xml");
   if (appXml.exists()) {
   if (!jarList.contains(dir.getAbsolutePath())) {
   jarList.add(dir.getAbsolutePath());
   }
   return;
   }

   File raXml = new File(dir, "META-INF" + File.separator +  
"ra.xml");

   if (raXml.exists()) {
   if (!jarList.contains(dir.getAbsolutePath())) {
   jarList.add(dir.getAbsolutePath());
   }
   return;
   }

and now it all works fine !

So to me this looks like something that got forgotten. Shall I raise  
a JIRA

for this and do you want me to supply a patch with the above ?

Regards and a happy new year, Christian.


thabach wrote:


I tried what you suggested, had to actually try with
getClass().getClassLoader().getSystemResource("META-INF/ra.xml") to
succeed, but the ra.xml is on the Classpath.

The quartz-beans JUnit Test in Eclipse runs fine as soon as I move  
the
ra.xml from the quartz-ra module to the quartz-beans module, but  
only as
long as I do not put an ejb-jar.xml into the src/main/resources/ 
META-INF

as well.

It really seems that it all depends on some ordering constraint,  
does one

have to manage rar before ejb deployment somehow ?

Cheers Christian.



David Blevins wrote:



On Oct 27, 2009, at 12:54 AM, thabach wrote:



Heya

I am investigating RAR support in OpenEJB and was playing with the
quartz-app from some earlier post (
http://www.nabble.com/need-help-getting-quartz-ra.rar-file-to-deploy-td18531000.html#a18538001
http://www.nabble.com/need-help-getting-quartz-ra.rar-file-to-deploy-td18531000.html#a18538001
).

When running a top-level mvn clean install the tests are executed
fine.
Running the quartz-beans module test from within Eclipse as a JUnit
test,
leads to a problem in matching the message listener interface of  
the

MDB
against the message listener interface of the automatically  
deployed

MdbContainer and yields this:

org.apache.openejb.OpenEJBException: Creating application failed:
classpath.ear: Error deploying 'TimerJob'.  Exception: class
org.apache.openejb.OpenEJBException: Deployment 'TimerJob' has  
message
listener interface org.quartz.Job but this MDB container only  
supports
interface javax.jms.MessageListener: Deployment 'TimerJob' has  
message
listener interface org.quartz.Job but this MDB container only  
supports

interface javax.jms.MessageListener


It seems there's something about the way the Eclipse project is  
setup

that does not match the Maven setup.  If Eclipse isn't including the
META-INF/ra.xml file in the classpath, then OpenEJB will not be able
to see and deploy the resource adapter and create the required MDB
container.

Try a little test code like this to verify your Eclipse setup:

  import junit.framework.TestCase;

  import java.net.URL;

  public class ClasspathTest extends TestCase {

  public void test() throws Exception {

  URL raXml = this.getClass().getResource("META-INF/ 
ra.xml");


  assertNotNull("There is no resource adapter in the
classpath", raXml);
  }
  }


Hope that helps!

-David








--
View this message in context: 
http://n4.nabble.com/Problem-Running-quartz-app-RAR-JUnit-Test-tp979722p991998.html
Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: resource adapter config with openEJB

[David Blevins]

On Dec 30, 2009, at 8:25 PM, Jason Russo wrote:

Well, I feel a bit dumb, but I think I figured out the problem  
here.  It

seems that the ra.xml within the generic adapter rar package has a tag
within the  tag as such:

   
   XATransaction
   

Notice the whitespace.  It appears that openEjb chokes with the below
error when reading this tag because of the whitespace in between the  
tag
ends.  When I remove the carriage returns and other whitespace, like  
so:


   XATransaction

The adapter deploys fine.  So I had to rebuild the genericra.rar  
with a

modified ra.xml to correct this tag.  What I don't understand is that
there are many other tags in the ra.xml that have the same kind
whitespace within them, but openEjb does not have a problem with those
tags.  I'm going to suggest that this is a bug.


Definitely seems so.  Might be something we can just have trimmed  
right that JAXB tree.  Seem to recall there is some easy way to ask  
jaxb to trim text input.



So now that I have been able to deploy the generic adapter, I seem to
have this problem with getting my MDB to use this adapter.  It appears
that instead of using this adapter, my MDB is using the 'Default JMS
Resource Adapter'.  Can anyone tell me how to link to the reference  
for

my own adapter?  Is this something I would set up in the
openejb-jar.xml?


Are you packaging your rar inside the app or deploying it separately?   
We can get it to work either way, just the "automatic" way is when the  
rar is in an ear with the MDB.


-David






Jason Russo

Application Developer

Genscape– See the Energy

445 E. Market St, Suite 200

Louisville, KY 40202

Tel: 502-583-2091

www.genscape.com



On Wed, 2009-12-30 at 12:45 -0500, Jason Russo wrote:


To be more specific, when I install the adapter, I keep getting the
following error message in the log.  Again, this is from openEjb
embedded in Tomcat 6.x (You may notice the references to Fiorano  
JMS.  I
am first trying to test with Fiorano, as that is our older JMS  
provider,

but eventually we want to use this with Tibco).  Any help would be
appreciated:


2009-12-30 12:39:17,229 - INFO  - Configuring
Service(id=genscape-generic-adapter-1.0-SNAPSHOTRA, type=Resource,
provider-id=genscape-generic-adapter-1.0-SNAPSHOTRA)
2009-12-30 12:39:17,229 - DEBUG -
[XATopicConnectionFactoryClassName 
=fiorano.jms.runtime.pubsub.xa.FioranoXATopicConnectionFactoryProxy]

2009-12-30 12:39:17,229 - DEBUG -
[QueueConnectionFactoryClassName 
=fiorano.jms.runtime.ptp.FioranoQueueConnectionFactory]

2009-12-30 12:39:17,229 - DEBUG -
[TopicConnectionFactoryClassName 
=fiorano.jms.runtime.pubsub.FioranoTopicConnectionFactory]

2009-12-30 12:39:17,229 - DEBUG -
[QueueClassName=fiorano.jms.runtime.ptp.FioranoQueue]
2009-12-30 12:39:17,229 - DEBUG -
[ConnectionFactoryClassName 
=fiorano.jms.runtime.common.FioranoConnectionFactoryProxy]

2009-12-30 12:39:17,229 - DEBUG - [UserName=anonymous]
2009-12-30 12:39:17,229 - DEBUG - [Password=]
2009-12-30 12:39:17,229 - DEBUG - [ProviderIntegrationMode=jndi]
2009-12-30 12:39:17,229 - DEBUG -
[JndiProperties 
=java.naming.factory.url.pkgs=fiorano.jms.runtime.naming
java 
.naming 
.factory 
.initial=fiorano.jms.runtime.naming.FioranoInitialContextFactory  
java.naming.provider.url=http://hades.genscape.com:1656  
java.naming.provider.principal=anonymous  
java.naming.provider.credentials=anonymous]

2009-12-30 12:39:17,229 - DEBUG - [SupportsXA=false]
2009-12-30 12:39:17,229 - DEBUG -
[XAConnectionFactoryClassName 
=fiorano.jms.runtime.common.FioranoXAConnectionFactory]

2009-12-30 12:39:17,229 - DEBUG -
[TopicClassName=fiorano.jms.runtime.pubsub.FioranoTopic]
2009-12-30 12:39:17,230 - DEBUG -
[XAQueueConnectionFactoryClassName 
=fiorano.jms.runtime.ptp.xa.FioranoXAQueueConnectionFactory]

2009-12-30 12:39:17,231 - ERROR - FATAL ERROR: Unknown error in
Assembler.  Please send the following stack trace and this message to
users@openejb.apache.org :
java.lang.NullPointerException
at
org 
.apache 
.openejb 
.config.AppInfoBuilder.buildConnectorModules(AppInfoBuilder.java:346)

at
org.apache.openejb.config.AppInfoBuilder.build(AppInfoBuilder.java: 
106)

at
org 
.apache 
.openejb 
.config 
.ConfigurationFactory 
.configureApplication(ConfigurationFactory.java:604)

at
org 
.apache 
.openejb 
.config 
.ConfigurationFactory 
.configureApplication(ConfigurationFactory.java:488)

at
org 
.apache 
.openejb 
.config 
.ConfigurationFactory 
.getOpenEjbConfiguration(ConfigurationFactory.java:356)

at
org 
.apache 
.openejb 
.assembler.classic.Assembler.getOpenEjbConfiguration(Assembler.java: 
299)

at
org.apache.openejb.assembler.classic.Assembler.build(Assembler.java: 
278)

at org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:137)
at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
at
org 
.apache.openejb.tomcat.catalina.TomcatLoader.init(TomcatLoader.java: 
123)

   

Re: transaction rolls back when returning from a remove method of a SFSB

[David Blevins]

On Dec 30, 2009, at 4:25 PM, is_maximum wrote:



Hi Jean Louis,
Currently we are using OpenEJB v3.1.1 but I don't think this is the  
case

because in our app server (GlassFish) the problem exists as well.

Anyway, I will try with the version 3.1.2 that you stated and I will  
give

the feedback.


Definitely try this with 3.1.2 and let us know how it goes.  I'd like  
to look into this, but we did have some work that went into  
transaction handling with regards to nesting and exception handling  
between 3.1.1 and 3.1.2 which could have a very direct impact on this.


-David



Jean-Louis MONTEIRO wrote:


Hi Mohammad,

Can you provide the OpenEJB version please?
There was a bug in transaction management for stateful beans.

It was fixed in 3.1.2. Can you give it a try?

Jean-Louis


is_maximum wrote:


Thanks John, You said if this happens it seems that you do  
something that

is not allowed in the @Remove method but I add another method say
remove() with no body and no return value and just mark it as  
@Remove but

still the same problem exists.

I also monitored the pool and cache of app server to see what  
happens if
I don't call remove method and unfortunately each request I send  
that
session beans remains in cache and in method-ready state for a  
long time
(the time as set to be expired in app server configuration) and  
this is
reallt bad!! This application is a banking system and the  
performance is

highly required!



John Ament wrote:


I'm not disputing that part, remove is meant to say "Ok, I don't  
need

this
bean anymore."  But it may be a case of something in the code  
that's in

your
remove is messing with the state of the bean.  Since you can call  
it

fine
without the @Remove, the only likely scenario is that you're doing
something
that's not allowed in the @Remove method, but I honestly can't  
think of

anything that falls into that scenario.

-Original Message-
From: is_maximum [mailto:mnr...@gmail.com]
Sent: Saturday, December 19, 2009 12:31 AM
To: users@openejb.apache.org
Subject: Re: transaction rolls back when returning from a remove  
method

of a
SFSB


Hi
As far as I understood from this document and EJB3 spec. if the  
client
doesn't invoke the remove method, that instance wont be  
availablable for

any
other request and will be passivated until its timeout reaches  
and then

the
container will remove it and this has performance issues and we  
have to

call
remove method so release resources.
I hope David can shed some light on this


meetoblivion wrote:


Sorry was thinking of Passivate/Activate

Here's the more up to date docs:

http://java.sun.com/javaee/5/docs/tutorial/doc/bnbmt.html#bnbmu

I'm

curious
to know what it is you're doing in postProcess, I'm still  
inclined to

say
that it's behaving correctly but it depends on what you're doing  
in

there.

On Mon, Dec 14, 2009 at 2:03 PM, is_maximum   
wrote:






meetoblivion wrote:


What you're describing is exactly what's supposed to be  
happening.

You're
not supposed to invoke the @Remove method from your own code.   
When

the

bean
container passivates the instance, it calls @Remove for you.




Thanks.
As far as I know, it is the client that invokes the remove  
method and

if
the
container passivates the SFSB the session bean will not reset its
state

http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBConcepts9.html



-
--
Regards

Mohammad Norouzi

Help each other to reach the future faster

http://pixelshot.wordpress.com Pixelshot Photoblog

http://brainable.blogspot.com Brainable Blog


--
View this message in context:


http://old.nabble.com/transaction-rolls-back-when-returning-from-a-remove-me
thod-of-a-SFSB-tp26775547p26779956.html

Sent from the OpenEJB User mailing list archive at Nabble.com.








-
--
Regards

Mohammad Norouzi

Help each other to reach the future faster

http://pixelshot.wordpress.com Pixelshot Photoblog

http://brainable.blogspot.com Brainable Blog


--
View this message in context:
http://old.nabble.com/transaction-rolls-back-when-returning-from-a-remove-me
thod-of-a-SFSB-tp26775547p26852910.html
Sent from the OpenEJB User mailing list archive at Nabble.com.


No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.427 / Virus Database: 270.14.114/2574 - Release Date:
12/18/09
19:38:00












-
--
Regards
Mohammad
http://pixelshot.wordpress.com Pixelshot
--
View this message in context: 
http://n4.nabble.com/transaction-rolls-back-when-returning-from-a-remove-method-of-a-SFSB-tp979527p990971.html
Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: jbosscmp

[David Blevins]

On Dec 21, 2009, at 4:22 PM, tbush wrote:



So essentially, this class just converts the vendor specific  
descriptors into

a JPA orm class.  Right?


Right.  Our CMP impl is just a layer on top of JPA.  (sorry for the  
delay in that simple response -- holidays :)


I think we have some Sun descriptor tests you can copy.  Maybe grab  
those and replace the sun descriptor with a jboss descriptor.   
Theoretically they should output the same jpa mapping file.  Might  
help severely narrow down and make more obvious the work required in  
the middle.  And of course, feel free to ask even simple questions on  
the dev@ list.  No need to wait for just "big" things.



Also, where/how would you like my changes?


Took some time and got this resolved.  Sent a note on it, let me know  
if you didn't get it.


-David



David Blevins wrote:



On Dec 10, 2009, at 11:15 PM, tbush wrote:


I'm working on using openejb to unit test an older application which
is
currently deployed to JBoss.  Can OpenEBJ read and process the
jbosscmp-jdbc.xml?  I found
org.apache.openejb.jee.jba.cmp.JbosscmpJdbc in
the 3.1.2 codebase; but I haven't see how to configure OpenEJB to
read the
xml.


We do for the GlassFish descriptors, and would like to for the JBoss
stuff as well.  We have the JAXB tree in there to read the  
descriptor,

but don't have any conversion code in there yet.  I'm not aware of
anyone working on it at the moment.  It may have even been me who
added that jaxb tree, but it's been a while and I don't recall - I
added a bunch of JAXB trees when we did the GlassFish specific work.

If you wanted to do some work here, we would *love* it. Doesn't have
to be complete.  Here's the GlassFish converter which you could copy
from:

http://svn.apache.org/repos/asf/openejb/trunk/openejb3/container/openejb-core/src/main/java/org/apache/openejb/config/SunConversion.java

-David





--
View this message in context: 
http://old.nabble.com/jbosscmp-tp26735489p26875456.html
Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: javax.naming.NameAlreadyBoundException: ParsedName{path=openejb/client/foundation/comp/env, component=env}

[David Blevins]

On Dec 15, 2009, at 10:25 PM, Stephan Bauer wrote:

Nevertheless I would be interested in knowing why these jar files  
get reflected in the JNDI in that "client" namespace...


Just an FYI, this is high on my list of issues to look into.   
Basically it's due to jar files being added as Application Clients  
because they fit that definition per the Java EE spec (i.e. they have  
a Main-Class entry in the MANIFEST.MF).  I had thought that we  
tightened this up while in an embedded mode so that you had to also  
have a META-INF/application-client.xml file to qualify, but it seems  
that needs to be revisited.



-David

Re: method interceptor is never called

[Jacek Laskowski]

On Mon, Jan 4, 2010 at 8:16 PM, Christian Bourque
 wrote:

> There you go! It's a maven project so simply run it with: mvn test
>
> You'll see that the second test will fail when it shouldn't...

Failed tests:
  testWithGenerics(test.test.AppTest)

Tests run: 2, Failures: 1, Errors: 0, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 

Looking into it...will report the findings soon.

Jacek

-- 
Jacek Laskowski
Notatnik Projektanta Java EE - http://wszystkojawne.pl
p.s. Szukam speca/firmy od grafiki/CSS/HTML

Re: method interceptor is never called

[Christian Bourque]

Hi Jacek,

There you go! It's a maven project so simply run it with: mvn test

You'll see that the second test will fail when it shouldn't...

Christian

On Sun, Jan 3, 2010 at 1:18 PM, Jacek Laskowski wrote:

> On Wed, Dec 30, 2009 at 2:24 AM, Christian Bourque
>  wrote:
>
> > I'm having a problem with a session bean and the latest version of
> OpenEJB
> > (3.1.2): my method interceptor is never called by the container, if I
> change
> > it to a class level interceptor it works as expected!
> >
> > This doesn't work:
> >
> > @Local(Test.class)
> > @Stateless
> > public class TestBean extends ... implements Test
> > {
> > @Override
> > @Interceptors(TagInterceptor.class)
> > public Entity makePersistent(Entity entity) { ... }
> > }
>
> Hi Christian,
>
> I've been looking into it and couldn't figure out what might've caused
> the issue. I've even made some changes to the interceptor example [1]
> to reproduce the issue with no joy hence your help is greatly
> appreciated to hunt it down. Could you give the example a try with
>
> mvn clean test
>
> and see if it works for you. I'm sure it will, so change it so it
> reflects your failing example or send the failing example to the
> mailing list as an attachment (if you can't, send it to my mailbox -
> jlaskowski...apache.org). I'd love giving it a try myself.
>
> A couple of notes while I was looking into the issue:
>
> 1. @Override can only be declared if you override a method from a
> parent class. It seems the TestBean class overrides a method from a
> parent class (commented out unfortunately) as well as implements the
> method from the Test intf. Is this a case?
>
> 2. TagInterceptor.class can only have a single @AroundInvoke-annotated
> method. Is this a case? (I'm not sure if openejb validates it)
>
> 3. How do you execute your bean?
>
> [1]
> http://svn.apache.org/repos/asf/openejb/trunk/openejb3/examples/interceptors
>
> Jacek
>
> --
> Jacek Laskowski
> Notatnik Projektanta Java EE - http://wszystkojawne.pl
> p.s. Szukam speca/firmy od grafiki/CSS/HTML
>


test.tar.gz
Description: GNU Zip compressed data