StackOverflow on InitialContext() lookup when using OpenEJB3.1.1

[Totsline, Greg]

Hi -

I am using Open EJB3.1.1 (just upgraded) from 3.0.  I am regression testing some code using JUnit 4 in Eclipse and am getting a stack overflow exception due to infinite recursion when I do a new InitialContext() in my test setup.  A similar problem was reported in http://osdir.com/ml/users.openejb.apache.org/2009-08/msg00089.html

Has this been reported as a bug and is there a patch / workaround for this issue?

Many Thanks.

-greg

[Quintin Beukes-2]

Is your case exactly the same as the one on the URL, ie. you're using
the ejblocal JDNI  template?

Can you perhaps post a reproducing test case, or at least describe how
to reproduce it.

Quintin Beukes



On Wed, Oct 7, 2009 at 7:51 PM, Totsline, Greg <greg.totsline@...> wrote:

> Hi -
>
> I am using Open EJB3.1.1 (just upgraded) from 3.0.  I am regression testing some code using JUnit 4 in Eclipse and am getting a stack overflow exception due to infinite recursion when I do a new InitialContext() in my test setup.  A similar problem was reported in http://osdir.com/ml/users.openejb.apache.org/2009-08/msg00089.html
>
> Has this been reported as a bug and is there a patch / workaround for this issue?
>
> Many Thanks.
>
> -greg
>
>
>
>
>

[Jean-Louis MONTEIRO]

Hi Greg,

actually, i tried to reproduce the problem but i didn't succeed.
Basically, using a semi-colon breaks jndi template behavior in OpenEJB. I guess your are trying to develop in OpenEJB and then run in WebSphere and you don't want to change lookups.

Don't know if we can hack easily OpenEJB to allow that, but as a workaround you use a service locator with a property file so that you just need to switch properties when deploying in WebSphere.

By the way, as suggested by Quintin, can you please give use a sample to reproduce the problem?

Hope it helps.
Jean-Louis

Totsline, Greg wrote:

Hi -

I am using Open EJB3.1.1 (just upgraded) from 3.0.  I am regression testing some code using JUnit 4 in Eclipse and am getting a stack overflow exception due to infinite recursion when I do a new InitialContext() in my test setup.  A similar problem was reported in http://osdir.com/ml/users.openejb.apache.org/2009-08/msg00089.html

Has this been reported as a bug and is there a patch / workaround for this issue?

Many Thanks.

-greg

[Totsline, Greg]

Hi Quintin -

No, I am not using the ejblocal JDNI  template, we use the java: prefix for resources that are looked up.  In my Junit setup I am setting the properties:

- openejb.jndiname.format, "{ejbClass.simpleName}/{interfaceType.annotationName}"
- openejb.configuration, config.toExternalForm()  where config is a URL obtained from the test class's class loader
- openejb.logger.external, "true"

The recursion is happening when I attempt to construct the initial context:  ctx = new InitialContext();  

So I am actually not even getting to my 1st test case, the stack overflow is occurring in the setup.  If I swap OpenEJB3.1.1 with OpenEJB3.1, the problem goes away.  We are using Maven v2.1.9 in Eclipse 3.4.2.  What's puzzling is that this is happening for the majority of our projects, but we have at least one that seems to pass its Junit tests in the same environment, even with the same properties being set.

We deploy to JBoss and would like to use 3.1.1 so that we can control jndi name formats with:
jndiname.format, "{ejbClass.simpleName}/{interfaceType.annotationNameLowerCase}"

Thanks very much.

-greg

-----Original Message-----
From: Quintin Beukes [mailto:quintin@...]
Sent: Wednesday, October 07, 2009 2:54 PM
To: users@...
Subject: Re: StackOverflow on InitialContext() lookup when using OpenEJB3.1.1

Is your case exactly the same as the one on the URL, ie. you're using
the ejblocal JDNI  template?

Can you perhaps post a reproducing test case, or at least describe how
to reproduce it.

Quintin Beukes



On Wed, Oct 7, 2009 at 7:51 PM, Totsline, Greg <greg.totsline@...> wrote:

> Hi -
>
> I am using Open EJB3.1.1 (just upgraded) from 3.0.  I am regression testing some code using JUnit 4 in Eclipse and am getting a stack overflow exception due to infinite recursion when I do a new InitialContext() in my test setup.  A similar problem was reported in http://osdir.com/ml/users.openejb.apache.org/2009-08/msg00089.html
>
> Has this been reported as a bug and is there a patch / workaround for this issue?
>
> Many Thanks.
>
> -greg
>
>
>
>
>

[David Blevins]

On Oct 8, 2009, at 6:20 AM, Totsline, Greg wrote:

> Hi Quintin -
>
> No, I am not using the ejblocal JDNI  template, we use the java:  
> prefix for resources that are looked up.

I can't seem to replicate this issue.  I took a stab at fixing it  
regardless using just the stack trace as a guide.  As far as I can see  
the issue would only occur if you use a prefix that isn't either  
"java:" or "openejb:".  If either of those are used, we strip off the  
prefix and delegate the lookup to those namespaces.  The only time we  
leave the prefix on is when we don't know what it is, in which case we  
delegate the lookup back to the JNDI system via "new  
InitialContext().lookup(theNameWithThePrefix)".

Normally this is fine as the VM will just look for a  
"<foo>.<foo>URLContextFactory" class inside each of the java packages  
listed via the Context.URL_PKG_PREFIXES system variable.  Most of the  
time it won't find anything and will just throw an exception.  I don't  
recall the details as we don't use this JNDI feature, but I seem to  
recall that there is a way to skip all of that and specify your JNDI  
system as the provider for everything and it's as simple as setting a  
JNDI property slightly differently -- don't exactly recall how.  If  
that's the case then that "we don't understand this prefix, so default  
back to the JNDI system" call is going to come right back to us and  
boom, infinite loop.

Anyway, I've simply removed the code where we go back to JNDI for  
prefixes we don't understand.  I've also tightened up the  
openejb.jndiname.format code to complain about formats that use  
prefixes and strip them off.  Not sure if either of those changes will  
help, but I've published new 3.1.2-SNAPSHOT binaries that you can try  
out.

If you can give those new snapshots a try and let me know if the  
problem goes away, that'd be great.  If it doesn't, then a test case  
that reproduces it would be really great.

-David

[Totsline, Greg]

Hi Dave -

We cannot seem to find 3.1.2-SNAPSHOT, can you please send pom file dependency that we should use to download it?  Looks like the repositories (<http://download.java.net/maven/1>  and <http://download.java.net/maven/2> )  do not have the group org.apache.openejb.

Thanks.

-greg

-----Original Message-----
From: David Blevins [mailto:david.blevins@...]
Sent: Friday, October 09, 2009 5:10 PM
To: users@...
Subject: Re: StackOverflow on InitialContext() lookup when using OpenEJB3.1.1


On Oct 8, 2009, at 6:20 AM, Totsline, Greg wrote:

> Hi Quintin -
>
> No, I am not using the ejblocal JDNI  template, we use the java:  
> prefix for resources that are looked up.

I can't seem to replicate this issue.  I took a stab at fixing it  
regardless using just the stack trace as a guide.  As far as I can see  
the issue would only occur if you use a prefix that isn't either  
"java:" or "openejb:".  If either of those are used, we strip off the  
prefix and delegate the lookup to those namespaces.  The only time we  
leave the prefix on is when we don't know what it is, in which case we  
delegate the lookup back to the JNDI system via "new  
InitialContext().lookup(theNameWithThePrefix)".

Normally this is fine as the VM will just look for a  
"<foo>.<foo>URLContextFactory" class inside each of the java packages  
listed via the Context.URL_PKG_PREFIXES system variable.  Most of the  
time it won't find anything and will just throw an exception.  I don't  
recall the details as we don't use this JNDI feature, but I seem to  
recall that there is a way to skip all of that and specify your JNDI  
system as the provider for everything and it's as simple as setting a  
JNDI property slightly differently -- don't exactly recall how.  If  
that's the case then that "we don't understand this prefix, so default  
back to the JNDI system" call is going to come right back to us and  
boom, infinite loop.

Anyway, I've simply removed the code where we go back to JNDI for  
prefixes we don't understand.  I've also tightened up the  
openejb.jndiname.format code to complain about formats that use  
prefixes and strip them off.  Not sure if either of those changes will  
help, but I've published new 3.1.2-SNAPSHOT binaries that you can try  
out.

If you can give those new snapshots a try and let me know if the  
problem goes away, that'd be great.  If it doesn't, then a test case  
that reproduces it would be really great.

-David

[Quintin Beukes-2]

    <repository>
      <id>apache-m2-snapshot</id>
      <name>Apache M2 Snapshot Repository</name>
      <url>http://repository.apache.org/snapshots/</url>
      <releases>
        <enabled>false</enabled>
      </releases>
      <snapshots>
        <enabled>true</enabled>
      </snapshots>
    </repository>

Quintin Beukes



On Tue, Oct 13, 2009 at 5:36 PM, Totsline, Greg <greg.totsline@...> wrote:

> Hi Dave -
>
> We cannot seem to find 3.1.2-SNAPSHOT, can you please send pom file dependency that we should use to download it?  Looks like the repositories (<http://download.java.net/maven/1>  and <http://download.java.net/maven/2> )  do not have the group org.apache.openejb.
>
> Thanks.
>
> -greg
>
> -----Original Message-----
> From: David Blevins [mailto:david.blevins@...]
> Sent: Friday, October 09, 2009 5:10 PM
> To: users@...
> Subject: Re: StackOverflow on InitialContext() lookup when using OpenEJB3.1.1
>
>
> On Oct 8, 2009, at 6:20 AM, Totsline, Greg wrote:
>
>> Hi Quintin -
>>
>> No, I am not using the ejblocal JDNI  template, we use the java:
>> prefix for resources that are looked up.
>
> I can't seem to replicate this issue.  I took a stab at fixing it
> regardless using just the stack trace as a guide.  As far as I can see
> the issue would only occur if you use a prefix that isn't either
> "java:" or "openejb:".  If either of those are used, we strip off the
> prefix and delegate the lookup to those namespaces.  The only time we
> leave the prefix on is when we don't know what it is, in which case we
> delegate the lookup back to the JNDI system via "new
> InitialContext().lookup(theNameWithThePrefix)".
>
> Normally this is fine as the VM will just look for a
> "<foo>.<foo>URLContextFactory" class inside each of the java packages
> listed via the Context.URL_PKG_PREFIXES system variable.  Most of the
> time it won't find anything and will just throw an exception.  I don't
> recall the details as we don't use this JNDI feature, but I seem to
> recall that there is a way to skip all of that and specify your JNDI
> system as the provider for everything and it's as simple as setting a
> JNDI property slightly differently -- don't exactly recall how.  If
> that's the case then that "we don't understand this prefix, so default
> back to the JNDI system" call is going to come right back to us and
> boom, infinite loop.
>
> Anyway, I've simply removed the code where we go back to JNDI for
> prefixes we don't understand.  I've also tightened up the
> openejb.jndiname.format code to complain about formats that use
> prefixes and strip them off.  Not sure if either of those changes will
> help, but I've published new 3.1.2-SNAPSHOT binaries that you can try
> out.
>
> If you can give those new snapshots a try and let me know if the
> problem goes away, that'd be great.  If it doesn't, then a test case
> that reproduces it would be really great.
>
> -David
>
>

[Totsline, Greg]

Hi David -

We pulled down 3.1.2 and are now seeing a different behavior.

We are no longer getting the stack overflow, but now the lookup for the data source we have ('java:afitDS') is failing with an OpenEJBException: Could not lookup <jta-data-source> 'openejb/Resource/java:afitsDS' for unit AFIT : Unknown JNDI name prefix 'openejb/Resource/java:'.

As you can see, we are using a 'java:' for this resource.

To summarize:
- Works under OpenEJB3.1
- Stack trace overflow under OpenEJB3.1.1
- Lookup failure under OpenEJB3.1.2 SNAPSHOT

Any thoughts or suggestions?  It's very difficult for me to submit a test case since our project is on a closed network.

Thanks.

-greg

-----Original Message-----
From: David Blevins [mailto:david.blevins@...]
Sent: Friday, October 09, 2009 5:10 PM
To: users@...
Subject: Re: StackOverflow on InitialContext() lookup when using OpenEJB3.1.1


On Oct 8, 2009, at 6:20 AM, Totsline, Greg wrote:

> Hi Quintin -
>
> No, I am not using the ejblocal JDNI  template, we use the java:  
> prefix for resources that are looked up.

I can't seem to replicate this issue.  I took a stab at fixing it  
regardless using just the stack trace as a guide.  As far as I can see  
the issue would only occur if you use a prefix that isn't either  
"java:" or "openejb:".  If either of those are used, we strip off the  
prefix and delegate the lookup to those namespaces.  The only time we  
leave the prefix on is when we don't know what it is, in which case we  
delegate the lookup back to the JNDI system via "new  
InitialContext().lookup(theNameWithThePrefix)".

Normally this is fine as the VM will just look for a  
"<foo>.<foo>URLContextFactory" class inside each of the java packages  
listed via the Context.URL_PKG_PREFIXES system variable.  Most of the  
time it won't find anything and will just throw an exception.  I don't  
recall the details as we don't use this JNDI feature, but I seem to  
recall that there is a way to skip all of that and specify your JNDI  
system as the provider for everything and it's as simple as setting a  
JNDI property slightly differently -- don't exactly recall how.  If  
that's the case then that "we don't understand this prefix, so default  
back to the JNDI system" call is going to come right back to us and  
boom, infinite loop.

Anyway, I've simply removed the code where we go back to JNDI for  
prefixes we don't understand.  I've also tightened up the  
openejb.jndiname.format code to complain about formats that use  
prefixes and strip them off.  Not sure if either of those changes will  
help, but I've published new 3.1.2-SNAPSHOT binaries that you can try  
out.

If you can give those new snapshots a try and let me know if the  
problem goes away, that'd be great.  If it doesn't, then a test case  
that reproduces it would be really great.

-David

[David Blevins]

On Oct 19, 2009, at 8:30 AM, Totsline, Greg wrote:

> We pulled down 3.1.2 and are now seeing a different behavior.
>
> We are no longer getting the stack overflow, but now the lookup for  
> the data source we have ('java:afitDS') is failing with an  
> OpenEJBException: Could not lookup <jta-data-source> 'openejb/
> Resource/java:afitsDS' for unit AFIT : Unknown JNDI name prefix  
> 'openejb/Resource/java:'.

That's very strange, we adjust the data source names listed in the  
persistence.xml if they don't match exactly what we have in our  
system.  I added a "java:" prefix to on of our tests and all worked  
fine:

INFO - Adjusting PersistenceUnit orange-unit <jta-data-source> to  
Resource ID 'Orange' from 'java:Orange'
INFO - Adjusting PersistenceUnit orange-unit <non-jta-data-source> to  
Resource ID 'OrangeUnmanaged' from 'orangeUnmanaged'

Do you have a stack trace we can look at?


-David

[Andy Gumbrecht]

Using 3.1.2-SNAPSHOT

The 'mx4j-tools.jar' (http://mx4j.sourceforge.net/) seems to be a
requirement for ActiveMQ 4.x in OpenEJB irrespective of the useJmx=false
setting .

Turning on debug for ActiveMQ shows a trace:

java.lang.ClassNotFoundException: mx4j.tools.naming.NamingService

Regards,

Andy.

[Quintin Beukes-2]

Is this the standalone or embedded distribution?

Quintin Beukes



On Tue, Oct 20, 2009 at 12:49 PM, Andy Gumbrecht
<andy.gumbrecht@...> wrote:

> Using 3.1.2-SNAPSHOT
>
> The 'mx4j-tools.jar' (http://mx4j.sourceforge.net/) seems to be a
> requirement for ActiveMQ 4.x in OpenEJB irrespective of the useJmx=false
> setting .
>
> Turning on debug for ActiveMQ shows a trace:
>
> java.lang.ClassNotFoundException: mx4j.tools.naming.NamingService
>
> Regards,
>
> Andy.
>
>

[Totsline, Greg]

Hi David -

An update.  I double checked my openejb.xml definitions for our data source.  By simply removing the "java:" prefix in the datasource definition, our unit tests now pass under the 3.1.2 snapshot version.  We are using JPA and curiously we are still able to refer to the datasource using the "java:" prefix in persistence.xml.  So the working config is:

- openejb.xml: <Resource id="myDS" type="DataSource">
- persistence.xml <jta-data-source>java:myDS</ jta-data-source>

With the changes made in the 3.1.2 SNAPSHOT version, does this make sense that it would be working with the above config?  The good news is that we are no longer seeing the InitialContext:lookup() recursion we were seeing under 3.1.1.

This made me wonder if I re-ran under 3.1.1 without the "java:" prefix in openejb.xml what would happen.  Now when I run under 3.1.1 without the prefix in openejb.xml, it seems to work fine so it appears that between 3.1 and 3.1.1 that using the java: prefix when defining the datasource resource results in the recursion.  

Finally - we ultimately wanted 3.1.1 because we are under the impression that we can control jndi name formats with new:
jndiname.format, "{ejbClass.simpleName}/{interfaceType.annotationNameLowerCase}"  Is this supported by 3.1.1?

Thanks.

-greg

-----Original Message-----
From: David Blevins [mailto:david.blevins@...]
Sent: Monday, October 19, 2009 4:43 PM
To: users@...
Subject: Re: StackOverflow on InitialContext() lookup when using OpenEJB3.1.1


On Oct 19, 2009, at 8:30 AM, Totsline, Greg wrote:

> We pulled down 3.1.2 and are now seeing a different behavior.
>
> We are no longer getting the stack overflow, but now the lookup for  
> the data source we have ('java:afitDS') is failing with an  
> OpenEJBException: Could not lookup <jta-data-source> 'openejb/
> Resource/java:afitsDS' for unit AFIT : Unknown JNDI name prefix  
> 'openejb/Resource/java:'.

That's very strange, we adjust the data source names listed in the  
persistence.xml if they don't match exactly what we have in our  
system.  I added a "java:" prefix to on of our tests and all worked  
fine:

INFO - Adjusting PersistenceUnit orange-unit <jta-data-source> to  
Resource ID 'Orange' from 'java:Orange'
INFO - Adjusting PersistenceUnit orange-unit <non-jta-data-source> to  
Resource ID 'OrangeUnmanaged' from 'orangeUnmanaged'

Do you have a stack trace we can look at?


-David

[David Blevins]

On Oct 20, 2009, at 7:29 AM, Totsline, Greg wrote:

> Hi David -
>
> An update.  I double checked my openejb.xml definitions for our data  
> source.  By simply removing the "java:" prefix in the datasource  
> definition, our unit tests now pass under the 3.1.2 snapshot version.

Aha!  So the datasource was defined as so:

<Resource id="java:myDS" type="DataSource">

The "id" is not a JNDI name (i.e. no code would have been able to  
lookup "java:myDS" in any context).  In the past that "java:" prefix  
was stripped off as a side effect of some internal code and ignoring  
it wasn't intended as a feature.

We can definitely add this in explicitly along with a test case to  
ensure it doesn't lapse in a future release.  Would be a good idea to  
throw a log message in that says "java:foo" is not valid and we are  
changing your resource ID to "foo".


>  We are using JPA and curiously we are still able to refer to the  
> datasource using the "java:" prefix in persistence.xml.  So the  
> working config is:
>
> - openejb.xml: <Resource id="myDS" type="DataSource">
> - persistence.xml <jta-data-source>java:myDS</ jta-data-source>
>
> With the changes made in the 3.1.2 SNAPSHOT version, does this make  
> sense that it would be working with the above config?

The above should have always "worked" and is.  I say worked in quotes  
as the above would always result in us adapting your <jta-data-source>  
or <non-jta-data-source> to something that didn't contain "java:" and  
lined up with your openejb configuration.  That code was very  
intentional and well tested, the aim being to support persistence.xml  
files setup for other vendors without the need for the user to modify  
them just to get them to work in OpenEJB.

So we do have some pretty fancy code (and tests) to try really hard to  
figure out what you meant with <jta-data-source> or <non-jta-data-
source> and log what understanding we reached.

> This made me wonder if I re-ran under 3.1.1 without the "java:"  
> prefix in openejb.xml what would happen.

It should work fine.

> Now when I run under 3.1.1 without the prefix in openejb.xml, it  
> seems to work fine so it appears that between 3.1 and 3.1.1 that  
> using the java: prefix when defining the datasource resource results  
> in the recursion.

Note I was able to get recursion with non "java:" prefixes using not  
default settings because of an if/ifelse/else case where "java:" and  
another internal prefix were explicitly handled and all other prefixes  
delegated back to the VM's JNDI system.

I was never able to reproduce the recursion issue with a "java:" url  
against the 3.1.1 codebase, but I was attempting actual lookups and  
using the "java:" in the persistence.xml.  I'm still pretty curious  
how that could ever happen.

I hadn't tried using "java:" as the ID of a Resource declaration,  
maybe that is the difference.  I'll definitely try that.

> Finally - we ultimately wanted 3.1.1 because we are under the  
> impression that we can control jndi name formats with new:
> jndiname.format, "{ejbClass.simpleName}/
> {interfaceType.annotationNameLowerCase}"  Is this supported by 3.1.1?

We added that for you in 3.1.2.  You can now put ".lc", ".uc", or  
".cc" on any variable in the JNDI format string to force it to lower  
case, upper case, or camel case respectively.

So this should work:

   {ejbClass.simpleName}/{interfaceType.annotationName.lc}


Thanks for working through this with us!  Anytime someone comes with  
assumptions from another vendor it's always challenging to figure out  
what they are and compensate for them so as little user time is wasted  
as possible.  The "java:" prefix in the <Resource> declaration turned  
out to be one area where we had compensating code and didn't know it! :)

We definitely appreciate you pointing this out.


-David