Re: JNDI lookup in Tomcat
On my side, I was specifically interested in looking up the transaction
manager from JNDI,
so if you could add 'openejb/TransactionManager' and
'openejb/UserTransaction' and map them to the proper instances, that would
have been great.
David Blevins wrote:
>
> Hi Guys,
>
> We don't currently expose the full internal JNDI tree via the
> LocalInitialContextFactory. Basically the LocalInitialContextFactory
> and the RemoteInitialContextFactory are designed to be identical with
> the exception that the RemoteInitialContextFactory doesn't have local
> interface objects in it. They both serve ejbs only.
>
> We can certainly hook up more functionality to get at the internal
> JNDI tree. What entries do you need specifically?
>
> -David
>
> On Jan 9, 2009, at 4:51 PM, JensToerber wrote:
>
>>
>> Hi,
>>
>> i can confirm this behaviour. Is it really the intention to use
>> org.apache.openejb.client.LocalInitialContextFactory. I thought this
>> is only
>> for standalone local testing.
>>
>> Any news about looking from Web-Tier via IntialContext()?
>>
>> Best regards,
>>
>> Jens
>>
>> Zog wrote:
>>>
>>> In a servlet listener for my webapp, I'm using this:
>>>
>>>public void contextInitialized(ServletContextEvent aArg0)
>>>{
>>>System.setProperty(Context.INITIAL_CONTEXT_FACTORY,
>>>"org.apache.openejb.client.LocalInitialContextFactory");
>>>System.err.println(">>>>>>> FULL JNDI TREE FROM STARTUP");
>>>try {
>>>InitialContext ic = new InitialContext();
>>>listContext("",ic);
>>>} catch (NamingException e) {
>>>System.err.println("Could not list tree."+e);
>>>}
>>>System.err.println("<<<<<<< FULL JNDI TREE FROM STARTUP");
>>>}
>>>
>>>private static final void listContext(String s, Context c) throws
>>> NamingException
>>>{
>>>NamingEnumeration pairs = c.list("");
>>>for (; pairs.hasMoreElements();)
>>>{
>>>NameClassPair p = pairs.next();
>>>System.err.println(s+"/"+p.getName() + " " +
>>> p.getClassName());
>>>Object o = c.lookup(p.getName());
>>>if (o instanceof Context)
>>>{
>>>Context child = (Context) o;
>>>listContext(s+"/"+p.getName(), child);
>>>}
>>>}
>>>}
>>>
>>> And here's what I get:
>>> /. java.lang.String
>>> /openejb org.apache.openejb.core.ivm.naming.IvmContext
>>> /openejb/ConfigurationInfoBusinessRemote
>>> org.apache.openejb.core.ivm.naming.Busi
>>> nessRemoteReference
>>> /openejb/DeployerBusinessRemote
>>> org.apache.openejb.core.ivm.naming.BusinessRemot
>>> eReference
>>> ...and then other contexts created by my MDB/SB.
>>>
>>> I don't see any /openejb/TransactionManager there.
>>>
>>>/Zog
>>>
>>>
>>> David Blevins wrote:
>>>>
>>>>
>>>> On Oct 8, 2008, at 12:37 PM, Zog wrote:
>>>>
>>>>> I installed the openejb.war in tomcat-6.0.18 and my ear as a
>>>>> collapsed ear.
>>>>> When I lookup objects in the JNDI tree, I realized that I can
>>>>> freely
>>>>> look up
>>>>> injected resources (I use the in ejb-jar.xml for ex
>>>>> for data
>>>>> sources),
>>>>> but non injected are failing - is this normal ?
>>>>> Specifically, one of my ejb is doing
>>>>> InitialContext ic = new InitialContext(); // Properly initialized
>>>>> with the
>>>>> OpenEJB ICfactory
>>>>> ic.lookup("openejb/TransactionManager");
>>>>> and this always throws a NameNotFoundException.
>>>>
>>>> Hmm. If it was created with the LocalInitialContextFactory as so..
>>>>
>>>> Properties properties = new Properties();
>>>> properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,
>>>> "org.apache.openejb.client.LocalInitialContextFactory");
>>>>
>>>> InitialContext initialContext = new InitialContext(properties);
>>>>
>>>> Then it should definitely work. If it was done as so...
>>>>
>>>> InitialContext initialContext = new InitialContext();
>>>>
>>>> Then I'm not as confident that it will work. We have code in the
>>>> integration to add the "openejb" subcontext into the webapp's jndi
>>>> context, or so I thought. I added code along these lines, but it's
>>>> been while and I can't recall the details. Maybe in this second
>>>> case
>>>> you have to lookup "java:openejb/TransactionManager".
>>>>
>>>> Can you verify which technique you are using?
>>>>
>>>>
>>>> -David
>>>>
>>>>
>>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/JNDI-lookup-in-Tomcat-tp19883726p21383331.html
>> Sent from the OpenEJB User mailing list archive at Nabble.com.
>>
>>
>
>
>
--
View this message in context:
http://www.nabble.com/JNDI-lookup-in-Tomcat-tp19883726p21562354.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: OpenEJB in an OSGi container
Succeeded to load OpenEJB in Felix 1.2.1 OSGi container.
See
https://issues.apache.org/jira/browse/OPENEJB-921
for details.
It's not perfect but it fits my needs (for now - just had to produce
a proof of concept).
/zog
Zog wrote:
>
> Thought I should give a first update here:
> I took the approach to package the whole OpenEJB (except the javaee jar)
> inside a single bundle,
> trying to run from inside OSGi but still configuring from
> openejb.home/conf/openejb.xml and
> loading my EJBs from openejb.home/apps.
> I did 2 things:
> - created an osgi bundle with proper Import-Package and Bundle-Classpath
> entries
> (classpath contains the whole openejb/lib minus javaee)
> - dropped openejb installation in a local './openejb' dir
> - used adapted code from Guillaume OpenEjbFactory to load openejb in my
> bundle activator:
> properties = new Properties();
> properties.put("openejb.home", "./openejb");
> properties.put("openejb.base", "./openejb");
> properties.put("openejb.configuration",
> "./openejb/conf/openejb.xml");
> properties.put("openejb.deployments.classpath.include", " ");
> properties.put("openejb.deployments.classpath", "true");
>
> properties.put("openejb.deployments.classpath.filter.system.apps",
> "false");
> SystemInstance system = SystemInstance.get();
>
> ApplicationServer appServer = new ServerFederation();
> system.setComponent(ApplicationServer.class, appServer);
>
> Assembler assembler = new Assembler();
>
> SystemInstance.get().setComponent(org.apache.openejb.spi.Assembler.class,
> assembler);
> Properties props = new Properties();
> props.putAll(system.getProperties());
> props.putAll(properties);
> assembler.init(props);
> assembler.build();
>
> This works almost ok, BUT
> - because OpenEJB expect resources to be accessible through jars URLs, the
> openejb-core-3.0.jar EJBs do not load. Actually, if I use the default
> empty value for
> openejb.deployments.classpath.include, I get a NPE in
> DeploymentLoader.getWebDescriptors
> because the META-INF dirs have classpath URLs that look like
> 'bundle://5.0:1/META-INF" - looks
> like xbean ResourceFinder doesn't work well in OSGi - will look into it.
> - JNDI tree doesn't seem to be working well: I can find my beans, but not
> my datasources and
> openejb/ subcontext is missing.
>
> I attach the log in case someone want to have a look.
>
> http://www.nabble.com/file/p19924199/openejb.log openejb.log
>
>
>
>
--
View this message in context:
http://www.nabble.com/OpenEJB-in-an-OSGi-container-tp19905326p19977951.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: OpenEJB in an OSGi container
Thought I should give a first update here:
I took the approach to package the whole OpenEJB (except the javaee jar)
inside a single bundle,
trying to run from inside OSGi but still configuring from
openejb.home/conf/openejb.xml and
loading my EJBs from openejb.home/apps.
I did 2 things:
- created an osgi bundle with proper Import-Package and Bundle-Classpath
entries
(classpath contains the whole openejb/lib minus javaee)
- dropped openejb installation in a local './openejb' dir
- used adapted code from Guillaume OpenEjbFactory to load openejb in my
bundle activator:
properties = new Properties();
properties.put("openejb.home", "./openejb");
properties.put("openejb.base", "./openejb");
properties.put("openejb.configuration",
"./openejb/conf/openejb.xml");
properties.put("openejb.deployments.classpath.include", " ");
properties.put("openejb.deployments.classpath", "true");
properties.put("openejb.deployments.classpath.filter.system.apps",
"false");
SystemInstance system = SystemInstance.get();
ApplicationServer appServer = new ServerFederation();
system.setComponent(ApplicationServer.class, appServer);
Assembler assembler = new Assembler();
SystemInstance.get().setComponent(org.apache.openejb.spi.Assembler.class,
assembler);
Properties props = new Properties();
props.putAll(system.getProperties());
props.putAll(properties);
assembler.init(props);
assembler.build();
This works almost ok, BUT
- because OpenEJB expect resources to be accessible through jars URLs, the
openejb-core-3.0.jar EJBs do not load. Actually, if I use the default empty
value for
openejb.deployments.classpath.include, I get a NPE in
DeploymentLoader.getWebDescriptors
because the META-INF dirs have classpath URLs that look like
'bundle://5.0:1/META-INF" - looks
like xbean ResourceFinder doesn't work well in OSGi - will look into it.
- JNDI tree doesn't seem to be working well: I can find my beans, but not my
datasources and
openejb/ subcontext is missing.
I attach the log in case someone want to have a look.
http://www.nabble.com/file/p19924199/openejb.log openejb.log
--
View this message in context:
http://www.nabble.com/OpenEJB-in-an-OSGi-container-tp19905326p19924199.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: OpenEJB in an OSGi container
I'm using apache Felix 1.2.1 with OSGi 1.4. I've no code to share yet - I started on this just recently and am still in information gathering mode :) but for sure I'll share this once I get it to work. Thanks a lot for the help /Zog David Blevins wrote: > > Thanks, Guillaume. That gives me a pretty good idea on what the > pieces are. > > Zog, let me know what OSGi kernel and version you're using and I'll > see if I can't whip up some boot code for you. If you've got any > starter code you can share, feel free to zip it up and attach it do a > JIRA (created a jira for you here > https://issues.apache.org/jira/browse/OPENEJB-921) > > -David > > > On Oct 9, 2008, at 2:47 PM, Guillaume Nodet wrote: > >> It's been a long time since I work on that and I still have not found >> the time to continue this integration work. >> Anyway, the code I used is available at: >> http://svn.apache.org/repos/asf/servicemix/smx4/features/branches/ >> ejb3 >> It uses a spring-powered bundle to set up OpenEJB: >> >> http://svn.apache.org/repos/asf/servicemix/smx4/features/branches/ejb3/deployer/src/main/resources/META-INF/spring/openejb-spring.xml >> and the related java classes are available at: >> >> http://svn.apache.org/repos/asf/servicemix/smx4/features/branches/ejb3/deployer/src/main/java/org/apache/servicemix/ejb3/deployer/ >> >> Unfortunately, this may be a bit outdated :-( >> >> Anyway, the idea was to be able to listen to newly installed bundles >> and discover EJB inside those so that they are automatically >> configured as plain EJB or web services. >> Though, this was in the context of ServiceMix, where the EJBs were to >> be exposed on the JBI bus and eventually through HTTP/SOAP too. >> >> On Thu, Oct 9, 2008 at 9:26 PM, David Blevins >> <[EMAIL PROTECTED]> wrote: >>> Guillaume is the one who's done most the work in this area in >>> regards to his >>> use of OpenEJB in the OSGi-based ServiceMix 4. >>> >>> What boot technique did you use in ServieMix? >>> >>> >>> -David >>> >>> >>> On Oct 9, 2008, at 2:08 PM, Zog wrote: >>> >>>> >>>> Hi >>>> So, I managed to get my EJB app running just fine in Tomcat/ >>>> OpeneEJB. Now >>>> that it validates the J2EE support I need from OpenEJB, I'd like >>>> to move >>>> all >>>> this >>>> to an OSGi container. >>>> Any hints on where I should look for information ? >>>> I scanned through the web and although it's stated everywhere that >>>> OpenEJB >>>> is packaged as OSGi bundled, I couldn't find information on how to >>>> start >>>> openejb >>>> in osgi. >>>> I tried a simple approach where I load everything in openejb/lib >>>> from the >>>> system classpath, >>>> but got a mysterious exception: >>>> Caused by: org.apache.openejb.core.ivm.naming.NamingException: >>>> Cannot >>>> initailize >>>> OpenEJB: null >>>> at >>>> org >>>> .apache.openejb.core.ivm.naming.InitContextFactory.initializeOpenE >>>> JB(InitContextFactory.java:88) >>>> at >>>> org >>>> .apache.openejb.core.ivm.naming.InitContextFactory.getInitialConte >>>> xt(InitContextFactory.java:35) >>>> at >>>> org >>>> .apache.openejb.client.LocalInitialContextFactory.getIntraVmContex >>>> t(LocalInitialContextFactory.java:114) >>>> >>>> That's most probably related to the way OSGi does classloading, >>>> and I'm >>>> investigating. >>>> >>>> Should I look at the way you embedded OpenEJB for Tomcat ? Or >>>> should I >>>> look >>>> elsewhere ? >>>> Any clue welcomed :) >>>>/Zog >>>> >>>> PS: Btw, finding http://openejb.apache.org/apidocs is not very >>>> easy on the >>>> openejb site - >>>> I had to scan through the forums to find that one. >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/OpenEJB-in-an-OSGi-container-tp19905326p19905326.html >>>> Sent from the OpenEJB User mailing list archive at Nabble.com. >>>> >>>> >>> >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> >> Blog: http://gnodet.blogspot.com/ >> >> Open Source SOA >> http://open.iona.com >> > > > -- View this message in context: http://www.nabble.com/OpenEJB-in-an-OSGi-container-tp19905326p19907692.html Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: OpenEJB in an OSGi container
(in case that was for me and not for Guillaume N): I'm not using servicemix - I'd like to have openejb running in a plain barebone Felix installation. That would be the start, then I'd take a look at how to deploy ejbs in there (i.e. directly via the openeejb conf or as bundles like Guillaume has done). David Blevins wrote: > > Guillaume is the one who's done most the work in this area in regards > to his use of OpenEJB in the OSGi-based ServiceMix 4. > > What boot technique did you use in ServieMix? > > > -David > > > On Oct 9, 2008, at 2:08 PM, Zog wrote: > >> >> Hi >> So, I managed to get my EJB app running just fine in Tomcat/ >> OpeneEJB. Now >> that it validates the J2EE support I need from OpenEJB, I'd like to >> move all >> this >> to an OSGi container. >> Any hints on where I should look for information ? >> I scanned through the web and although it's stated everywhere that >> OpenEJB >> is packaged as OSGi bundled, I couldn't find information on how to >> start >> openejb >> in osgi. >> I tried a simple approach where I load everything in openejb/lib >> from the >> system classpath, >> but got a mysterious exception: >> Caused by: org.apache.openejb.core.ivm.naming.NamingException: Cannot >> initailize >> OpenEJB: null >>at >> org.apache.openejb.core.ivm.naming.InitContextFactory.initializeOpenE >> JB(InitContextFactory.java:88) >>at >> org.apache.openejb.core.ivm.naming.InitContextFactory.getInitialConte >> xt(InitContextFactory.java:35) >>at >> org.apache.openejb.client.LocalInitialContextFactory.getIntraVmContex >> t(LocalInitialContextFactory.java:114) >> >> That's most probably related to the way OSGi does classloading, and >> I'm >> investigating. >> >> Should I look at the way you embedded OpenEJB for Tomcat ? Or should >> I look >> elsewhere ? >> Any clue welcomed :) >> /Zog >> >> PS: Btw, finding http://openejb.apache.org/apidocs is not very easy >> on the >> openejb site - >> I had to scan through the forums to find that one. >> -- >> View this message in context: >> http://www.nabble.com/OpenEJB-in-an-OSGi-container-tp19905326p19905326.html >> Sent from the OpenEJB User mailing list archive at Nabble.com. >> >> > > > -- View this message in context: http://www.nabble.com/OpenEJB-in-an-OSGi-container-tp19905326p19905846.html Sent from the OpenEJB User mailing list archive at Nabble.com.
OpenEJB in an OSGi container
Hi So, I managed to get my EJB app running just fine in Tomcat/OpeneEJB. Now that it validates the J2EE support I need from OpenEJB, I'd like to move all this to an OSGi container. Any hints on where I should look for information ? I scanned through the web and although it's stated everywhere that OpenEJB is packaged as OSGi bundled, I couldn't find information on how to start openejb in osgi. I tried a simple approach where I load everything in openejb/lib from the system classpath, but got a mysterious exception: Caused by: org.apache.openejb.core.ivm.naming.NamingException: Cannot initailize OpenEJB: null at org.apache.openejb.core.ivm.naming.InitContextFactory.initializeOpenE JB(InitContextFactory.java:88) at org.apache.openejb.core.ivm.naming.InitContextFactory.getInitialConte xt(InitContextFactory.java:35) at org.apache.openejb.client.LocalInitialContextFactory.getIntraVmContex t(LocalInitialContextFactory.java:114) That's most probably related to the way OSGi does classloading, and I'm investigating. Should I look at the way you embedded OpenEJB for Tomcat ? Or should I look elsewhere ? Any clue welcomed :) /Zog PS: Btw, finding http://openejb.apache.org/apidocs is not very easy on the openejb site - I had to scan through the forums to find that one. -- View this message in context: http://www.nabble.com/OpenEJB-in-an-OSGi-container-tp19905326p19905326.html Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: JNDI lookup in Tomcat
In a servlet listener for my webapp, I'm using this:
public void contextInitialized(ServletContextEvent aArg0)
{
System.setProperty(Context.INITIAL_CONTEXT_FACTORY,
"org.apache.openejb.client.LocalInitialContextFactory");
System.err.println(">>>>>>> FULL JNDI TREE FROM STARTUP");
try {
InitialContext ic = new InitialContext();
listContext("",ic);
} catch (NamingException e) {
System.err.println("Could not list tree."+e);
}
System.err.println("<<<<<<< FULL JNDI TREE FROM STARTUP");
}
private static final void listContext(String s, Context c) throws
NamingException
{
NamingEnumeration pairs = c.list("");
for (; pairs.hasMoreElements();)
{
NameClassPair p = pairs.next();
System.err.println(s+"/"+p.getName() + " " + p.getClassName());
Object o = c.lookup(p.getName());
if (o instanceof Context)
{
Context child = (Context) o;
listContext(s+"/"+p.getName(), child);
}
}
}
And here's what I get:
/. java.lang.String
/openejb org.apache.openejb.core.ivm.naming.IvmContext
/openejb/ConfigurationInfoBusinessRemote
org.apache.openejb.core.ivm.naming.Busi
nessRemoteReference
/openejb/DeployerBusinessRemote
org.apache.openejb.core.ivm.naming.BusinessRemot
eReference
...and then other contexts created by my MDB/SB.
I don't see any /openejb/TransactionManager there.
/Zog
David Blevins wrote:
>
>
> On Oct 8, 2008, at 12:37 PM, Zog wrote:
>
>> I installed the openejb.war in tomcat-6.0.18 and my ear as a
>> collapsed ear.
>> When I lookup objects in the JNDI tree, I realized that I can freely
>> look up
>> injected resources (I use the in ejb-jar.xml for ex
>> for data
>> sources),
>> but non injected are failing - is this normal ?
>> Specifically, one of my ejb is doing
>> InitialContext ic = new InitialContext(); // Properly initialized
>> with the
>> OpenEJB ICfactory
>> ic.lookup("openejb/TransactionManager");
>> and this always throws a NameNotFoundException.
>
> Hmm. If it was created with the LocalInitialContextFactory as so..
>
> Properties properties = new Properties();
> properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,
> "org.apache.openejb.client.LocalInitialContextFactory");
>
> InitialContext initialContext = new InitialContext(properties);
>
> Then it should definitely work. If it was done as so...
>
> InitialContext initialContext = new InitialContext();
>
> Then I'm not as confident that it will work. We have code in the
> integration to add the "openejb" subcontext into the webapp's jndi
> context, or so I thought. I added code along these lines, but it's
> been while and I can't recall the details. Maybe in this second case
> you have to lookup "java:openejb/TransactionManager".
>
> Can you verify which technique you are using?
>
>
> -David
>
>
>
--
View this message in context:
http://www.nabble.com/JNDI-lookup-in-Tomcat-tp19883726p19898308.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Unknown error in Assembler for MessageDriven bean
That's a very complete and clear explanation - as a
newbie in the EJB world, I was not aware of those subtleties.
Thank you very much for the help.
Zog
David Blevins wrote:
>
>
> On Oct 3, 2008, at 8:01 AM, Zog wrote:
>
>>
>> Hi
>> Unfortunately I cant' post the code - but I solved the issue by just
>> adding
>> a
>> javax.jms.MessageListener
>> in ejb-jar.xml for all my MDBs.
>> One thing to note though is that my MDBs do not directly imlpement
>> this
>> interface, they extend a class that does - could it be possible that
>> you're
>> using Class.getDeclaredClasses() instead of getClasses() to
>> introspect the
>> class ?
>
> That's definitely what we are doing. Couple notes on that.
>
> For EJb 2.1 and prior the is a required xml element
> -- autodiscovery via introspection is an EJB 3.0 feature. If you were
> to grab an old version of weblogic, the bean would likely not deploy
> without the declared. Something to keep in mind if
> you intend your app to be an EJB 2.1 compliant app.
>
> In EJB 3.0 there are some things that the vendor must look into the
> superclasses for such as @PostConstruct, @PreDestroy, @Resource, and
> @EJB. But others like @Stateless, @MessageDriven, @Stateful, @Local,
> @Remote as well as business interfaces (including message listener
> interfaces) are only supported in the bean class itself, not the super
> class. Some vendors may support searching in super classes for
> business interfaces, but this is not a compliant behavior and other
> platforms are not guaranteed to do the same. A very special note here
> is that apps that rely on non-compliant auto-discovery of business
> interfaces in the super class may actually *break* as in EJB 3.1 any
> ejb that doesn't declare any business interfaces in the bean class
> itself will be considered a no-interface bean. This won't affect
> MDBs, but is something to be aware of.
>
>
> -David
>
>
>> Dain Sundstrom wrote:
>>>
>>> Can you post the code for you message driven bean or at the very
>>> least
>>> the class declaration with any extends clause, implements clause and
>>> class annotations?
>>>
>>> My guess is the MDB class is not-spec-compliant and Weblogic has some
>>> special logic to guess the proper message listener interface. Or, we
>>> have a bug :)
>>>
>>> -dain
>>>
>>> On Sep 30, 2008, at 10:34 AM, Jacques-Olivier Goussard wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm trying to deploy a bunch of MDBs on openejb and encounter this
>>>> error:
>>>>
>>>> 2008-09-30 15:52:51,328 - ERROR - FATAL ERROR: Unknown error in
>>>> Assembler.
>>>> Plea
>>>>
>>>> se send the following stack trace and this message to
>>>> [EMAIL PROTECTED] :
>>>>
>>>> java.lang.IllegalStateException: When annotating a bean class as
>>>> @MessageDriven
>>>>
>>>> without declaring messageListenerInterface, the bean must implement
>>>> exactly
>>>> one
>>>>
>>>> interface, no more and no less.
>>>> beanClass=com.oz.shared.transcoding.sti.protoco
>>>>
>>>> l.ejb.TranscodingProviderMessageListenerBean interfaces=
>>>>
>>>> at
>>>> org.apache.openejb.config.AnnotationDeployer
>>>> $ProcessAnnotatedBeans.de
>>>>
>>>> ploy(AnnotationDeployer.java:854)
>>>>
>>>> (see full stack below)
>>>>
>>>> Those EJB were deployed successfully in weblogic, and I didn't yet
>>>> properly
>>>> create the corresponding
>>>>
>>>> Deployment descriptors for openejb – but this error seems an
>>>> internal one
>>>> and given
>>>>
>>>> My EJB are 2.0 (no annotations), I find it strange it complains
>>>> about this
>>>> annotation.
>>>>
>>>> Any ideas someone ?
>>>>
>>>> /jog
>>>>
>>>>
>>>>
>>>> 2008-09-30 15:52:51,328 - ERROR - FATAL ERROR: Unknown error in
>>>> Assembler.
>>>> Plea
>>>>
>>>> se send the following stack trace and this message to
>>>> [EMAIL PROTECTED] :
>>>>
>>>> java.lang.IllegalStateException: When annotating a bean class as
>>>> @Messag
JNDI lookup in Tomcat
Hi
I installed the openejb.war in tomcat-6.0.18 and my ear as a collapsed ear.
When I lookup objects in the JNDI tree, I realized that I can freely look up
injected resources (I use the in ejb-jar.xml for ex for data
sources),
but non injected are failing - is this normal ?
Specifically, one of my ejb is doing
InitialContext ic = new InitialContext(); // Properly initialized with the
OpenEJB ICfactory
ic.lookup("openejb/TransactionManager");
and this always throws a NameNotFoundException.
If I start OpenEJB standalone and connect through telnet, I can see
the transactionmanager using the lookup command.
Is this the expected behavior for the Tomcat integration ?
Thanks
/zog
--
View this message in context:
http://www.nabble.com/JNDI-lookup-in-Tomcat-tp19883726p19883726.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
weblogic support and
Hi I'm porting MDBs developed for weblogic into OpenEJB. I have the following issue. I declared the queues I use in openejb.xml, like destination My_Real_Queue and my weblogic.xml descriptors contain MyMDB My_JNDI_Queue If I use just this (hoping that OpenEJB will fully support my weblogic-ejb-jar.xml) then the embedded instance of activemq seems to create a queue named queue://MyMDB instead of queue://My_Real_Queue i.e. the lookup from the JNDI name to the real name is not done. However, if I add destination My_Real_Queue then the queue is properly created and all works well. So - question is: am I right to assume OpenEJB doesn't support the in weblogic descriptors or is my configuration screwed up somehow ? Can you confirm one or the other :) ? Thanks /jog -- View this message in context: http://www.nabble.com/weblogic-support-and-%3Cdestination-jndi-name%3E-tp19877049p19877049.html Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Unknown error in Assembler for MessageDriven bean
Hi Unfortunately I cant' post the code - but I solved the issue by just adding a javax.jms.MessageListener in ejb-jar.xml for all my MDBs. One thing to note though is that my MDBs do not directly imlpement this interface, they extend a class that does - could it be possible that you're using Class.getDeclaredClasses() instead of getClasses() to introspect the class ? /jog Dain Sundstrom wrote: > > Can you post the code for you message driven bean or at the very least > the class declaration with any extends clause, implements clause and > class annotations? > > My guess is the MDB class is not-spec-compliant and Weblogic has some > special logic to guess the proper message listener interface. Or, we > have a bug :) > > -dain > > On Sep 30, 2008, at 10:34 AM, Jacques-Olivier Goussard wrote: > >> Hi, >> >> I'm trying to deploy a bunch of MDBs on openejb and encounter this >> error: >> >> 2008-09-30 15:52:51,328 - ERROR - FATAL ERROR: Unknown error in >> Assembler. >> Plea >> >> se send the following stack trace and this message to >> [EMAIL PROTECTED] : >> >> java.lang.IllegalStateException: When annotating a bean class as >> @MessageDriven >> >> without declaring messageListenerInterface, the bean must implement >> exactly >> one >> >> interface, no more and no less. >> beanClass=com.oz.shared.transcoding.sti.protoco >> >> l.ejb.TranscodingProviderMessageListenerBean interfaces= >> >>at >> org.apache.openejb.config.AnnotationDeployer$ProcessAnnotatedBeans.de >> >> ploy(AnnotationDeployer.java:854) >> >> (see full stack below) >> >> Those EJB were deployed successfully in weblogic, and I didn't yet >> properly >> create the corresponding >> >> Deployment descriptors for openejb – but this error seems an >> internal one >> and given >> >> My EJB are 2.0 (no annotations), I find it strange it complains >> about this >> annotation. >> >> Any ideas someone ? >> >> /jog >> >> >> >> 2008-09-30 15:52:51,328 - ERROR - FATAL ERROR: Unknown error in >> Assembler. >> Plea >> >> se send the following stack trace and this message to >> [EMAIL PROTECTED] : >> >> java.lang.IllegalStateException: When annotating a bean class as >> @MessageDriven >> >> without declaring messageListenerInterface, the bean must implement >> exactly >> one >> >> interface, no more and no less. >> beanClass=com.oz.shared.transcoding.sti.protoco >> >> l.ejb.TranscodingProviderMessageListenerBean interfaces= >> >>at >> org.apache.openejb.config.AnnotationDeployer$ProcessAnnotatedBeans.de >> >> ploy(AnnotationDeployer.java:854) >> >>at >> org.apache.openejb.config.AnnotationDeployer$ProcessAnnotatedBeans.de >> >> ploy(AnnotationDeployer.java:489) >> >>at >> org.apache.openejb.config.AnnotationDeployer.deploy(AnnotationDeploye >> >> r.java:169) >> >>at >> org.apache.openejb.config.ConfigurationFactory$Chain.deploy(Configura >> >> tionFactory.java:148) >> >>at >> org.apache.openejb.config.ConfigurationFactory.configureApplication(C >> >> onfigurationFactory.java:440) >> >>at >> org.apache.openejb.config.ConfigurationFactory.configureApplication(C >> >> onfigurationFactory.java:391) >> >>at >> org.apache.openejb.config.ConfigurationFactory.getOpenEjbConfiguratio >> >> n(ConfigurationFactory.java:309) >> >>at >> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:2 >> >> 49) >> >>at org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:149) >> >>at org.apache.openejb.OpenEJB.init(OpenEJB.java:288) >> >>at org.apache.openejb.server.Server.init(Server.java:63) >> >>at org.apache.openejb.server.Main.initServer(Main.java:155) >> >>at org.apache.openejb.server.Main.main(Main.java:128) >> >>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> >>at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. >> >> java:39) >> >>at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces >> >> sorImpl.java:25) >> >>at java.lang.reflect.Method.invoke(Method.java:585) >> >>at org.apache.openejb.cli.MainImpl.main(MainImpl.java:151) >> >>at org.apache.openejb.cli.Bootstrap.main(Bootstrap.java:103) >> >> >> >> 2008-09-30 15:52:51,331 - FATAL - OpenEJB has encountered a fatal >> error and >> cann >> >> ot be started: Assembler failed to build the container system. >> >> org.apache.openejb.OpenEJBException: >> java.lang.IllegalStateException: When >> annot >> >> ating a bean class as @MessageDriven without declaring >> messageListenerInterface, >> >> the bean must implement exactly one interface, no more and no less. >> beanClass=c >> >> om >> .oz >> .shared >> .transcoding.sti.protocol.ejb.TranscodingProviderMessageListenerBean >> >> interfaces=: When annotating a bean class as @MessageDriven without >> declaring m >> >> essageListenerInterface, the bean must implement exactly one >> interfa
