You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Stephen Davidson <st...@etcc.com> on 2010/01/25 21:18:21 UTC
Include Classpath not sharing Deployed EJBs?
Greetings.
For compatibility with the deployed app server, we can not use the
ejb-jar.xml file, only annotated class files. Unfortunately, it seems
that the clients can only connect when the services.jar file (the jar
that has my ejbs) has an ejb-jar.xml file. When it does not, they fail
to connect. Details follow. Suggestions? Or did I miss something from
http://openejb.apache.org/3.0/application-discovery-via-the-classpath.ht
ml ?
Regards,
Steve
I've set the following in my pom.xml;
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<configuration>
<systemProperties>
<systemProperty>
<name>openejb.deployments.classpath.include</name>
<value>.*services-${service.version}.*</value>
</systemProperty>
</systemProperties>
</configuration>
</plugin>
(Note: project specific settings, dependenicies, and other config items
left out).
Runtime excerpt;
INFO - Beginning load: C:\Documents and
Settings\sdavidson\.m2\repository\org\mortbay\jetty\start\6.1.11\start-6
.1.11.jar
INFO - Configuring enterprise application: classpath.ear
INFO - Configuring Service(id=Default Stateless Container,
type=Container, provider-id=Default Stateless Container)
INFO - Auto-creating a container for bean com/etcc/Account:
Container(type=STATELESS, id=Default Stateless Container)
INFO - Enterprise application "classpath.ear" loaded.
INFO - Assembling app: classpath.ear
INFO - Jndi(name=com/etcc/StateLocal) -->
Ejb(deployment-id=com/etcc/State)
...
Running com.etcc.csc.delegate.StateDelegateEjbTest
TRACE - Getting EJB Client for: com.etcc.csc.service.StateInterface
TRACE - Loading service: State
TRACE - Loading service: State
DEBUG - Unable to access EJB State: Name "com/etcc/StateLocal" not
found.
javax.naming.NameNotFoundException: Name "com/etcc/StateLocal" not
found.
at
org.apache.openejb.core.ivm.naming.IvmContext.federate(IvmContext.java:1
93)
at
org.apache.openejb.core.ivm.naming.IvmContext.lookup(IvmContext.java:150
)
at
org.apache.openejb.core.ivm.naming.ContextWrapper.lookup(ContextWrapper.
java:115)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at
com.etcc.csc.delegate.EjbServiceFactoryTestImpl.getImpl(EjbServiceFactor
yTestImpl.java:50)
at
com.etcc.csc.service.ServiceFactory.getImplementation(ServiceFactory.jav
a:139)
at
com.etcc.csc.delegate.StateDelegate.getStates(StateDelegate.java:27)
at
com.etcc.csc.delegate.StateDelegateTest.testGetStates(StateDelegateTest.
java:46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMet
hod.java:44)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallab
le.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMetho
d.java:41)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod
.java:20)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.jav
a:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:
31)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner
.java:73)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner
.java:46)
at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
at
org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
at
org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.jav
a:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:
31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.jav
a:62)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSe
t(AbstractDirectoryTestSuite.java:140)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Abstr
actDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Suref
ireBooter.java:345)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java
:1009)
ERROR - Failed to retrieve states: Unable to access EJB State: Name
"com/etcc/StateLocal" not found.
java.lang.RuntimeException: Unable to access EJB State: Name
"com/etcc/StateLocal" not found.
at
com.etcc.csc.delegate.EjbServiceFactoryTestImpl.getImpl(EjbServiceFactor
yTestImpl.java:56)
at
com.etcc.csc.service.ServiceFactory.getImplementation(ServiceFactory.jav
a:139)
at
com.etcc.csc.delegate.StateDelegate.getStates(StateDelegate.java:27)
at
com.etcc.csc.delegate.StateDelegateTest.testGetStates(StateDelegateTest.
java:46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMet
hod.java:44)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallab
le.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMetho
d.java:41)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod
.java:20)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.jav
a:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:
31)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner
.java:73)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner
.java:46)
at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
at
org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
at
org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.jav
a:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:
31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.jav
a:62)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSe
t(AbstractDirectoryTestSuite.java:140)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Abstr
actDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Suref
ireBooter.java:345)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java
:1009)
Caused by: javax.naming.NameNotFoundException: Name
"com/etcc/StateLocal" not found.
at
org.apache.openejb.core.ivm.naming.IvmContext.federate(IvmContext.java:1
93)
at
org.apache.openejb.core.ivm.naming.IvmContext.lookup(IvmContext.java:150
)
at
org.apache.openejb.core.ivm.naming.ContextWrapper.lookup(ContextWrapper.
java:115)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at
com.etcc.csc.delegate.EjbServiceFactoryTestImpl.getImpl(EjbServiceFactor
yTestImpl.java:50)
... 31 more
RE: Include Classpath not sharing Deployed EJBs?
Posted by Stephen Davidson <st...@etcc.com>.
Just realized, you might need the getInitialContext() method for the
previous routine.
Regards,
Steve
protected InitialContext getInitialContext() throws NamingException
{
Properties properties = new Properties();
properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,
"org.apache.openejb.client.LocalInitialContextFactory");
InitialContext initialContext = new InitialContext(properties);
return initialContext;
}
-----Original Message-----
From: Stephen Davidson [mailto:stephen.davidson@etcc.com]
Sent: Tuesday, January 26, 2010 11:16 AM
To: users@openejb.apache.org
Subject: RE: Include Classpath not sharing Deployed EJBs?
Sure.
The odd thing is, this works when there IS a ejb-jar.xml file. Only
when there is no ejb-jar.xml does this fail. I think I still have
Jason's(?) test case around. If needed, I can probably modify that to
produce this if you would like.
Regards,
Steve
protected <T extends ServiceInterface> T getImpl(Class<T>
theInterface) {
if (logger.isTraceEnabled())
logger.trace("Getting EJB Client for: " +
theInterface.getName());
InitialContext initialContext = null;
try {
initialContext = getInitialContext();
@SuppressWarnings("unchecked")
T service = (T)initialContext.lookup("com/etcc/" +
getServiceName(theInterface) + "Local");
return service;
} catch (NamingException e) {
String msg = "Unable to access EJB " +
getServiceName(theInterface) + ": " + e.getMessage();
throw new RuntimeException(msg, e);
} finally {
if (initialContext != null){
try {
initialContext.close();
} catch (NamingException e) {
logger.warn("Exception closing initial context: " +
e.getMessage(), e);
}
}
}
}
RE: Include Classpath not sharing Deployed EJBs?
Posted by Stephen Davidson <st...@etcc.com>.
Greetings.
Was out early this week, and only looking at this now. Have not yet
duplicated this issue in the public demo module. Will continue to
enhance to something resembling the main project, or until I figure out
what the issue is.
-Steve
-----Original Message-----
From: David Blevins [mailto:david.blevins@visi.com]
Sent: Sunday, January 31, 2010 12:40 PM
To: users@openejb.apache.org
Subject: Re: Include Classpath not sharing Deployed EJBs?
Hmm. Everything seems in order. Is it possible you can make a sample
we can use to reproduce it? Not sure what else to recommend.
-David
RE: Include Classpath not sharing Deployed EJBs?
Posted by Stephen Davidson <st...@etcc.com>.
Multi-Threaded programming can be tricky enough, but Multi-process???
UGH! Especially when I don't realize that its occurring!
Figured this out.
The long version;
Maven was starting a separate process (not sure if a completely separate
JVM, did not check out the Fork settings) for Jetty, and then launching
the Integration Tests. The reason this was working for my WebService
tests is they were connecting to Jetty via HTTP (and I had some code to
set up the Port). If I had Remote EJBs, then these tests would also
probably work as is in Jetty. But I only have Local Ejbs, and Open EJB
is (quite properly, I might add) looking for the EJBs in the local
process. And since the JUnit tests never configured OpenEjb to deploy
them (handled by Maven during Jetty startup, right?), it was not finding
them.
Bottom line, the test cases I came up with were perfect for Remote EJBs,
but failed when I threw in Local Ejbs.
Regards,
Steve
-----Original Message-----
From: Stephen Davidson [mailto:stephen.davidson@etcc.com]
Sent: Thursday, February 04, 2010 5:35 PM
To: users@openejb.apache.org
Subject: RE: Include Classpath not sharing Deployed EJBs?
Hi David.
I have attached a demo project, which shows (in a much reduced scale)
what I am experiencing. As the Demo project does not have a delegate
tier, I had the Integration Test call the Servlet. In the project, we
have a Delegate Tier that the Servlets call to access the EJBs, and the
test cases are calling the Delegates instead.
As attached, the project works. Delete the ejb-jar.xml file from the
EJB Jar, and watch it fail on "mvn clean install". The goal in the
Integration test is;
mvn integration-test
To just start jetty, mvn jetty:run
Something odd I noticed with the Demo project is that the generated ear
file is being deployed twice. In the case of no ejb-jar.xml file, the
EJBs are deployed only once (the first pass), but not on the second pass
(which seems to be the Test Pass).
In the case of ejb-jar.xml file present, the EJBs are apparently
deployed twice as well.
I've confirmed this occurs for my application for both cases.
Any thoughts?
-Steve
RE: Include Classpath not sharing Deployed EJBs?
Posted by Stephen Davidson <st...@etcc.com>.
Hi David.
I have attached a demo project, which shows (in a much reduced scale)
what I am experiencing. As the Demo project does not have a delegate
tier, I had the Integration Test call the Servlet. In the project, we
have a Delegate Tier that the Servlets call to access the EJBs, and the
test cases are calling the Delegates instead.
As attached, the project works. Delete the ejb-jar.xml file from the
EJB Jar, and watch it fail on "mvn clean install". The goal in the
Integration test is;
mvn integration-test
To just start jetty, mvn jetty:run
Something odd I noticed with the Demo project is that the generated ear
file is being deployed twice. In the case of no ejb-jar.xml file, the
EJBs are deployed only once (the first pass), but not on the second pass
(which seems to be the Test Pass).
In the case of ejb-jar.xml file present, the EJBs are apparently
deployed twice as well.
I've confirmed this occurs for my application for both cases.
Any thoughts?
-Steve
-----Original Message-----
From: David Blevins [mailto:david.blevins@visi.com]
Sent: Sunday, January 31, 2010 12:40 PM
To: users@openejb.apache.org
Subject: Re: Include Classpath not sharing Deployed EJBs?
Hmm. Everything seems in order. Is it possible you can make a sample
we can use to reproduce it? Not sure what else to recommend.
-David
On Jan 29, 2010, at 5:46 PM, Stephen Davidson wrote:
> Ok, I missed something here.
>
> In both cases, with & without ejb-jar.xml, EJBs are getting deployed.
> Just, in one case, the client applications are not actually able to
> access the EJBs, but in the other, they are. The log from the "Not
> Found" case shows the EJBs are getting deployed, but your response
> says
> that they might not be (which is where I got confused).
>
> Service(id=Default Stateless Container, type=Container,
> provider-id=Default Stateless Container) INFO - Auto-creating a
> container for bean com/etcc/Account:
> Container(type=STATELESS, id=Default Stateless Container) INFO -
> Enterprise application "classpath.ear" loaded.
> INFO - Assembling app: classpath.ear
> INFO - Jndi(name=com/etcc/StateLocal) -->
> Ejb(deployment-id=com/etcc/State)
>
> ...
>
> Running com.etcc.csc.delegate.StateDelegateEjbTest
> TRACE - Getting EJB Client for: com.etcc.csc.service.StateInterface
> TRACE - Loading service: State
> TRACE - Loading service: State
> DEBUG - Unable to access EJB State: Name "com/etcc/StateLocal" not
> found.
> javax.naming.NameNotFoundException: Name "com/etcc/StateLocal" not
> found.
>
>
> I figured your scanner issue might be causing an issue. Initially,
> w/o
> the ejb-jar.xml file, the EJBs were not getting deployed at all.
> Hence,
> per
>
http://openejb.apache.org/3.0/application-discovery-via-the-classpath.ht
> ml,
> I had set
> <systemProperty>
>
> <name>openejb.deployments.classpath.include</name>
>
> <value>.*services-${service.version}.*</value>
> </systemProperty>
>
> This resulted in the EJBs apparently getting deployed, at least, as
> far
> as was recorded in the log. But it looks like a step was missed
> during
> deployment?
>
> -Steve
>
> -----Original Message-----
> From: David Blevins [mailto:david.blevins@visi.com]
> Sent: Friday, January 29, 2010 4:57 AM
> To: users@openejb.apache.org
> Subject: Re: Include Classpath not sharing Deployed EJBs?
>
>
> On Jan 26, 2010, at 6:15 PM, Stephen Davidson wrote:
>
>> The odd thing is, this works when there IS a ejb-jar.xml file. Only
>> when there is no ejb-jar.xml does this fail.
>
> It sounds like this might be related to the properties issue. By
> default the "classpath scan" include/exclude settings filter out
> everything resulting in us just looking for ejb-jar.xml files in the
> classpath rather than scanning class files to find apps.
>
> We will log any properties that you change on INFO level, so if it
> doesn't show up, we aren't seeing it.
>
>
> -David
>
> --
> http://blog.dblevins.com/
> http://twitter.com/dblevins
> Like OpenEJB? Tweet it!
>
>
>
>
Re: Include Classpath not sharing Deployed EJBs?
Posted by David Blevins <da...@visi.com>.
Hmm. Everything seems in order. Is it possible you can make a sample
we can use to reproduce it? Not sure what else to recommend.
-David
On Jan 29, 2010, at 5:46 PM, Stephen Davidson wrote:
> Ok, I missed something here.
>
> In both cases, with & without ejb-jar.xml, EJBs are getting deployed.
> Just, in one case, the client applications are not actually able to
> access the EJBs, but in the other, they are. The log from the "Not
> Found" case shows the EJBs are getting deployed, but your response
> says
> that they might not be (which is where I got confused).
>
> Service(id=Default Stateless Container, type=Container,
> provider-id=Default Stateless Container) INFO - Auto-creating a
> container for bean com/etcc/Account:
> Container(type=STATELESS, id=Default Stateless Container) INFO -
> Enterprise application "classpath.ear" loaded.
> INFO - Assembling app: classpath.ear
> INFO - Jndi(name=com/etcc/StateLocal) -->
> Ejb(deployment-id=com/etcc/State)
>
> ...
>
> Running com.etcc.csc.delegate.StateDelegateEjbTest
> TRACE - Getting EJB Client for: com.etcc.csc.service.StateInterface
> TRACE - Loading service: State
> TRACE - Loading service: State
> DEBUG - Unable to access EJB State: Name "com/etcc/StateLocal" not
> found.
> javax.naming.NameNotFoundException: Name "com/etcc/StateLocal" not
> found.
>
>
> I figured your scanner issue might be causing an issue. Initially,
> w/o
> the ejb-jar.xml file, the EJBs were not getting deployed at all.
> Hence,
> per
> http://openejb.apache.org/3.0/application-discovery-via-the-classpath.ht
> ml,
> I had set
> <systemProperty>
>
> <name>openejb.deployments.classpath.include</name>
>
> <value>.*services-${service.version}.*</value>
> </systemProperty>
>
> This resulted in the EJBs apparently getting deployed, at least, as
> far
> as was recorded in the log. But it looks like a step was missed
> during
> deployment?
>
> -Steve
>
> -----Original Message-----
> From: David Blevins [mailto:david.blevins@visi.com]
> Sent: Friday, January 29, 2010 4:57 AM
> To: users@openejb.apache.org
> Subject: Re: Include Classpath not sharing Deployed EJBs?
>
>
> On Jan 26, 2010, at 6:15 PM, Stephen Davidson wrote:
>
>> The odd thing is, this works when there IS a ejb-jar.xml file. Only
>> when there is no ejb-jar.xml does this fail.
>
> It sounds like this might be related to the properties issue. By
> default the "classpath scan" include/exclude settings filter out
> everything resulting in us just looking for ejb-jar.xml files in the
> classpath rather than scanning class files to find apps.
>
> We will log any properties that you change on INFO level, so if it
> doesn't show up, we aren't seeing it.
>
>
> -David
>
> --
> http://blog.dblevins.com/
> http://twitter.com/dblevins
> Like OpenEJB? Tweet it!
>
>
>
>
RE: Include Classpath not sharing Deployed EJBs?
Posted by Stephen Davidson <st...@etcc.com>.
Ok, I missed something here.
In both cases, with & without ejb-jar.xml, EJBs are getting deployed.
Just, in one case, the client applications are not actually able to
access the EJBs, but in the other, they are. The log from the "Not
Found" case shows the EJBs are getting deployed, but your response says
that they might not be (which is where I got confused).
Service(id=Default Stateless Container, type=Container,
provider-id=Default Stateless Container) INFO - Auto-creating a
container for bean com/etcc/Account:
Container(type=STATELESS, id=Default Stateless Container) INFO -
Enterprise application "classpath.ear" loaded.
INFO - Assembling app: classpath.ear
INFO - Jndi(name=com/etcc/StateLocal) -->
Ejb(deployment-id=com/etcc/State)
...
Running com.etcc.csc.delegate.StateDelegateEjbTest
TRACE - Getting EJB Client for: com.etcc.csc.service.StateInterface
TRACE - Loading service: State
TRACE - Loading service: State
DEBUG - Unable to access EJB State: Name "com/etcc/StateLocal" not
found.
javax.naming.NameNotFoundException: Name "com/etcc/StateLocal" not
found.
I figured your scanner issue might be causing an issue. Initially, w/o
the ejb-jar.xml file, the EJBs were not getting deployed at all. Hence,
per
http://openejb.apache.org/3.0/application-discovery-via-the-classpath.ht
ml,
I had set
<systemProperty>
<name>openejb.deployments.classpath.include</name>
<value>.*services-${service.version}.*</value>
</systemProperty>
This resulted in the EJBs apparently getting deployed, at least, as far
as was recorded in the log. But it looks like a step was missed during
deployment?
-Steve
-----Original Message-----
From: David Blevins [mailto:david.blevins@visi.com]
Sent: Friday, January 29, 2010 4:57 AM
To: users@openejb.apache.org
Subject: Re: Include Classpath not sharing Deployed EJBs?
On Jan 26, 2010, at 6:15 PM, Stephen Davidson wrote:
> The odd thing is, this works when there IS a ejb-jar.xml file. Only
> when there is no ejb-jar.xml does this fail.
It sounds like this might be related to the properties issue. By
default the "classpath scan" include/exclude settings filter out
everything resulting in us just looking for ejb-jar.xml files in the
classpath rather than scanning class files to find apps.
We will log any properties that you change on INFO level, so if it
doesn't show up, we aren't seeing it.
-David
--
http://blog.dblevins.com/
http://twitter.com/dblevins
Like OpenEJB? Tweet it!
Re: Include Classpath not sharing Deployed EJBs?
Posted by David Blevins <da...@visi.com>.
On Jan 26, 2010, at 6:15 PM, Stephen Davidson wrote:
> The odd thing is, this works when there IS a ejb-jar.xml file. Only
> when there is no ejb-jar.xml does this fail.
It sounds like this might be related to the properties issue. By
default the "classpath scan" include/exclude settings filter out
everything resulting in us just looking for ejb-jar.xml files in the
classpath rather than scanning class files to find apps.
We will log any properties that you change on INFO level, so if it
doesn't show up, we aren't seeing it.
-David
--
http://blog.dblevins.com/
http://twitter.com/dblevins
Like OpenEJB? Tweet it!
RE: Include Classpath not sharing Deployed EJBs?
Posted by Stephen Davidson <st...@etcc.com>.
Sure.
The odd thing is, this works when there IS a ejb-jar.xml file. Only
when there is no ejb-jar.xml does this fail. I think I still have
Jason's(?) test case around. If needed, I can probably modify that to
produce this if you would like.
Regards,
Steve
protected <T extends ServiceInterface> T getImpl(Class<T>
theInterface) {
if (logger.isTraceEnabled())
logger.trace("Getting EJB Client for: " +
theInterface.getName());
InitialContext initialContext = null;
try {
initialContext = getInitialContext();
@SuppressWarnings("unchecked")
T service = (T)initialContext.lookup("com/etcc/" +
getServiceName(theInterface) + "Local");
return service;
} catch (NamingException e) {
String msg = "Unable to access EJB " +
getServiceName(theInterface) + ": " + e.getMessage();
throw new RuntimeException(msg, e);
} finally {
if (initialContext != null){
try {
initialContext.close();
} catch (NamingException e) {
logger.warn("Exception closing initial context: " +
e.getMessage(), e);
}
}
}
}
-----Original Message-----
From: David Blevins [mailto:david.blevins@visi.com]
Sent: Monday, January 25, 2010 9:44 PM
To: users@openejb.apache.org
Subject: Re: Include Classpath not sharing Deployed EJBs?
On Jan 25, 2010, at 9:18 PM, Stephen Davidson wrote:
> Runtime excerpt;
> INFO - Beginning load: C:\Documents and
> Settings\sdavidson\.m2\repository\org\mortbay\jetty\start
> \6.1.11\start-6
> .1.11.jar
> INFO - Configuring enterprise application: classpath.ear
> INFO - Configuring Service(id=Default Stateless Container,
> type=Container, provider-id=Default Stateless Container)
> INFO - Auto-creating a container for bean com/etcc/Account:
> Container(type=STATELESS, id=Default Stateless Container)
> INFO - Enterprise application "classpath.ear" loaded.
> INFO - Assembling app: classpath.ear
> INFO - Jndi(name=com/etcc/StateLocal) -->
> Ejb(deployment-id=com/etcc/State)
>
> ...
>
> Running com.etcc.csc.delegate.StateDelegateEjbTest
> TRACE - Getting EJB Client for: com.etcc.csc.service.StateInterface
> TRACE - Loading service: State
> TRACE - Loading service: State
> DEBUG - Unable to access EJB State: Name "com/etcc/StateLocal" not
> found.
> javax.naming.NameNotFoundException: Name "com/etcc/StateLocal" not
It looks like everything should work. The log shows the bean you want
has been created and the exception shows you're using the right JNDI
name. Is it possible you can post some of the test code?
-David
--
http://blog.dblevins.com/
http://twitter.com/dblevins
Like OpenEJB? Tweet it!
Re: Include Classpath not sharing Deployed EJBs?
Posted by David Blevins <da...@visi.com>.
On Jan 25, 2010, at 9:18 PM, Stephen Davidson wrote:
> Runtime excerpt;
> INFO - Beginning load: C:\Documents and
> Settings\sdavidson\.m2\repository\org\mortbay\jetty\start
> \6.1.11\start-6
> .1.11.jar
> INFO - Configuring enterprise application: classpath.ear
> INFO - Configuring Service(id=Default Stateless Container,
> type=Container, provider-id=Default Stateless Container)
> INFO - Auto-creating a container for bean com/etcc/Account:
> Container(type=STATELESS, id=Default Stateless Container)
> INFO - Enterprise application "classpath.ear" loaded.
> INFO - Assembling app: classpath.ear
> INFO - Jndi(name=com/etcc/StateLocal) -->
> Ejb(deployment-id=com/etcc/State)
>
> ...
>
> Running com.etcc.csc.delegate.StateDelegateEjbTest
> TRACE - Getting EJB Client for: com.etcc.csc.service.StateInterface
> TRACE - Loading service: State
> TRACE - Loading service: State
> DEBUG - Unable to access EJB State: Name "com/etcc/StateLocal" not
> found.
> javax.naming.NameNotFoundException: Name "com/etcc/StateLocal" not
It looks like everything should work. The log shows the bean you want
has been created and the exception shows you're using the right JNDI
name. Is it possible you can post some of the test code?
-David
--
http://blog.dblevins.com/
http://twitter.com/dblevins
Like OpenEJB? Tweet it!