RE: FailOnUnknowActivationSpec for MessageDriven Bean
Hi,
the documentation http://tomee.apache.org/admin/configuration/containers.html
is not updated, so I used the 'old' wrong spelling. The spelling was fixed in
https://issues.apache.org/jira/browse/TOMEE-2093 without updating the
documentation. This was a pain to resolve. For anyone who is looking for a
solution, I updated my openejb test repository with a working configuration:
https://github.com/vgropp/openEjbContainer
Regards Volker Gropp
From: Gropp Volker [mailto:volker.gr...@e-velopment.de]
Sent: Freitag, 22. Juni 2018 17:06
To: users@tomee.apache.org
Subject: FailOnUnknowActivationSpec for MessageDriven Bean
Hi,
is it possible to either not deploy MessageDriven Beans at all in openejb or
turn off FailOnUnknowActivationSpec for all Container/MDB using properties? I
use openEjb for my container based unit-tests and it fails to deploy a JMS MDB
with
messageListenerInterface = MessageListener.class,
activationConfig = {
@ActivationConfigProperty(propertyName="maxSession", propertyValue="1")
}
I found you can declare it in Properties using
http://tomee.apache.org/admin/configuration/containers.html
But after adding that I get:
Assembler failed to build the container system.
org.apache.openejb.OpenEJBException: No existing resource adapter defined with
id 'Default JMS Resource Adapter'.
My original error without trying to set FailOnUnknowActivationSpec to false is:
org.apache.openejb.OpenEjbContainer$AssembleApplicationException:
org.apache.openejb.OpenEJBException: Creating application failed: C:\test:
Error deploying 'ListenerMDB'. Exception: class
org.apache.openejb.OpenEJBException: Unable to create activation spec: No
setter found for the activation spec properties: [maxSession]: Unable to create
activation spec: No setter found for the activation spec properties:
[maxSession]
at
org.apache.openejb.OpenEjbContainer$Provider.createEJBContainer(OpenEjbContainer.java:347)
at
javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:127)
at
de.evelopment.openejb.util.EjbTestHelper.startContainer(EjbTestHelper.java:91)
at de.evelopment.openejb.EjbTestCase.startUp(EjbTestCase.java:39)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:538)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:760)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:206)
Caused by: org.apache.openejb.OpenEJBException: Creating application failed:
C:\test: Error deploying 'ListenerMDB'. Exception: class
org.apache.op
FailOnUnknowActivationSpec for MessageDriven Bean
Hi,
is it possible to either not deploy MessageDriven Beans at all in openejb or
turn off FailOnUnknowActivationSpec for all Container/MDB using properties? I
use openEjb for my container based unit-tests and it fails to deploy a JMS MDB
with
messageListenerInterface = MessageListener.class,
activationConfig = {
@ActivationConfigProperty(propertyName="maxSession", propertyValue="1")
}
I found you can declare it in Properties using
http://tomee.apache.org/admin/configuration/containers.html
But after adding that I get:
Assembler failed to build the container system.
org.apache.openejb.OpenEJBException: No existing resource adapter defined with
id 'Default JMS Resource Adapter'.
My original error without trying to set FailOnUnknowActivationSpec to false is:
org.apache.openejb.OpenEjbContainer$AssembleApplicationException:
org.apache.openejb.OpenEJBException: Creating application failed: C:\test:
Error deploying 'ListenerMDB'. Exception: class
org.apache.openejb.OpenEJBException: Unable to create activation spec: No
setter found for the activation spec properties: [maxSession]: Unable to create
activation spec: No setter found for the activation spec properties:
[maxSession]
at
org.apache.openejb.OpenEjbContainer$Provider.createEJBContainer(OpenEjbContainer.java:347)
at
javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:127)
at
de.evelopment.openejb.util.EjbTestHelper.startContainer(EjbTestHelper.java:91)
at de.evelopment.openejb.EjbTestCase.startUp(EjbTestCase.java:39)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:538)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:760)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:206)
Caused by: org.apache.openejb.OpenEJBException: Creating application failed:
C:\test: Error deploying 'ListenerMDB'. Exception: class
org.apache.openejb.OpenEJBException: Unable to create activation spec: No
setter found for the activation spec properties: [maxSession]: Unable to create
activation spec: No setter found for the activation spec properties:
[maxSession]
at
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:1050)
at
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:721)
at
org.apache.openejb.OpenEjbContainer$Provider.createEJBContainer(OpenEjbContainer.java:343)
... 33 more
Caused by: org.apache.openejb.OpenEJBException: Error deploying 'ListenerMDB'.
Exception: class org.apache.openejb.OpenEJBException: Unable to crea
RE: openejb 7 failure deploying MessageDriven (Cannot bind Container with id Default MDB Container)
Hi,
thanks a lot for your help. Adding a MessageListenerInterface config as well
got it working:
p.put("SocketResourceAdapter",
"new://Resource?type=ActiveMQResourceAdapter");
p.put("SocketResourceAdapter.BrokerXmlConfig", "");
p.put("MyOtherContainer", "new://Container?type=MESSAGE");
p.put("MyOtherContainer.ResourceAdapter",
"SocketResourceAdapter");
p.put("MyOtherContainer.MessageListenerInterface",
"de.evelopment.messagedriven.SocketConnectionEndpoint");
Volker Gropp
-Original Message-
From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Sent: Freitag, 9. September 2016 13:24
To: users@tomee.apache.org
Subject: Re: openejb 7 failure deploying MessageDriven (Cannot bind Container
with id Default MDB Container)
you need to define the container for that interface, see
MessageListenerInterface on
http://tomee.apache.org/ng/admin/configuration/containers.html
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-09-09 13:17 GMT+02:00 Gropp Volker :
> Hi,
>
> ok, setting an extra container for JMS brings back the error
> "Deployment 'SocketMessageDriven' has message listener interface
> de.evelopment.messagedriven.SocketConnectionEndpoint but this MDB
> container only supports interface javax.jms.MessageListener"
>
> Which container type (or Resource Adapter Type?) do I have to set for
> a generic Message-Driven-Bean?
>
> Properties p = new Properties();
> p.put("SocketResourceAdapter", "new://Resource?type=
> ActiveMQResourceAdapter");
> p.put("SocketResourceAdapter.BrokerXmlConfig", "");
> p.put("MyOtherContainer", "new://Container?type=MESSAGE");
> p.put("MyOtherContainer.ResourceAdapter",
> "SocketResourceAdapter");
> EJBContainer.createEJBContainer(p);
>
>
> Thanks for the @Rule-tip. I already tried it but it was easier to
> leave the old abstract class, because changing everything in our
> Project doesn’t have much benefit yet.
>
> Volker Gropp
>
> -Original Message-
> From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
> Sent: Freitag, 9. September 2016 12:52
> To: users@tomee.apache.org
> Subject: Re: openejb 7 failure deploying MessageDriven (Cannot bind
> Container with id Default MDB Container)
>
> needs some testing (sorry dont have much time today) but guess it is
> cause you have 2 MDB kinds (2 listener interfaces) and you dont define
> the 2 MDB containers so openejb doesnt find a container for the socket
> MDB and tries to create a default MDB container which is the already
> created one for the JMS mdb (we have a single default MDB container).
> Solution is to define explicitely the MDB container in EJBContainer
> properties (one for each type of interface).
>
> Side note: using openejb-junit you can replace your abstract class by
> a
> rule:
>
>
> @RunWith(Parameterized.class)
>
> // @Properties to configure the container public class
> SimpleContainerTest {
>@Rule
>public final EJBContainerRule rule = new EJBContainerRule(this);
>
> //...
>
> }
>
>
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog <
> https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog <
> http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau>
> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <
> http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-
> rmannibucau.rhcloud.com>
>
> 2016-09-09 12:35 GMT+02:00 Gropp Volker :
>
> > Hi,
> >
> > to illustrade the problem I created a simple test project:
> > https://github.com/vgropp/openEjbContainer/tree/HEAD/openEjbContaine
> > r
> >
> > Please ignore the TimerService Test, it's an old test. Deploying the
> > container fails with the error when having a JMS-Message-Driven Bean
> > and a simple other Message Driven Bean. When removing the jms-Bean I
> > get another error (attached). So is it correct that only
> > JMS-MessageDriven Beans are currently supported?
RE: openejb 7 failure deploying MessageDriven (Cannot bind Container with id Default MDB Container)
Hi,
ok, setting an extra container for JMS brings back the error
"Deployment 'SocketMessageDriven' has message listener interface
de.evelopment.messagedriven.SocketConnectionEndpoint but this MDB container
only supports interface javax.jms.MessageListener"
Which container type (or Resource Adapter Type?) do I have to set for a generic
Message-Driven-Bean?
Properties p = new Properties();
p.put("SocketResourceAdapter",
"new://Resource?type=ActiveMQResourceAdapter");
p.put("SocketResourceAdapter.BrokerXmlConfig", "");
p.put("MyOtherContainer", "new://Container?type=MESSAGE");
p.put("MyOtherContainer.ResourceAdapter",
"SocketResourceAdapter");
EJBContainer.createEJBContainer(p);
Thanks for the @Rule-tip. I already tried it but it was easier to leave the old
abstract class, because changing everything in our Project doesn’t have much
benefit yet.
Volker Gropp
-Original Message-
From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Sent: Freitag, 9. September 2016 12:52
To: users@tomee.apache.org
Subject: Re: openejb 7 failure deploying MessageDriven (Cannot bind Container
with id Default MDB Container)
needs some testing (sorry dont have much time today) but guess it is cause you
have 2 MDB kinds (2 listener interfaces) and you dont define the 2 MDB
containers so openejb doesnt find a container for the socket MDB and tries to
create a default MDB container which is the already created one for the JMS mdb
(we have a single default MDB container). Solution is to define explicitely the
MDB container in EJBContainer properties (one for each type of interface).
Side note: using openejb-junit you can replace your abstract class by a
rule:
@RunWith(Parameterized.class)
// @Properties to configure the container public class SimpleContainerTest {
@Rule
public final EJBContainerRule rule = new EJBContainerRule(this);
//...
}
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-09-09 12:35 GMT+02:00 Gropp Volker :
> Hi,
>
> to illustrade the problem I created a simple test project:
> https://github.com/vgropp/openEjbContainer/tree/HEAD/openEjbContainer
>
> Please ignore the TimerService Test, it's an old test. Deploying the
> container fails with the error when having a JMS-Message-Driven Bean
> and a simple other Message Driven Bean. When removing the jms-Bean I
> get another error (attached). So is it correct that only
> JMS-MessageDriven Beans are currently supported?
>
> org.apache.openejb.OpenEjbContainer$AssembleApplicationException:
> org.apache.openejb.OpenEJBException: Creating application failed:
> C:\vgropp\openEjbContainer\openEjbContainer: Error deploying
> 'SocketMessageDriven'. Exception: class org.apache.openejb.OpenEJBException:
> Deployment 'SocketMessageDriven' has message listener interface
> de.evelopment.messagedriven.SocketConnectionEndpoint but this MDB
> container only supports interface javax.jms.MessageListener:
> Deployment 'SocketMessageDriven' has message listener interface
> de.evelopment.messagedriven.SocketConnectionEndpoint but this MDB
> container only supports interface javax.jms.MessageListener
> at org.apache.openejb.OpenEjbContainer$Provider.
> createEJBContainer(OpenEjbContainer.java:339)
> at javax.ejb.embeddable.EJBContainer.createEJBContainer(
> EJBContainer.java:56)
> at javax.ejb.embeddable.EJBContainer.createEJBContainer(
> EJBContainer.java:43)
> at de.evelopment.timer.SimpleContainerBase.startUp(
> SimpleContainerBase.java:20)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
> FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(
> ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(
> FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.RunBefores.
> evaluate(RunBefores.java:24)
> at or
RE: openejb 7 failure deploying MessageDriven (Cannot bind Container with id Default MDB Container)
jms.MessageListener: Deployment
'SocketMessageDriven' has message listener interface
de.evelopment.messagedriven.SocketConnectionEndpoint but this MDB container
only supports interface javax.jms.MessageListener
at
org.apache.openejb.assembler.classic.Assembler.startEjbs(Assembler.java:1374)
at
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:878)
... 30 more
Caused by: org.apache.openejb.OpenEJBException: Deployment
'SocketMessageDriven' has message listener interface
de.evelopment.messagedriven.SocketConnectionEndpoint but this MDB container
only supports interface javax.jms.MessageListener
at
org.apache.openejb.core.mdb.MdbContainer.deploy(MdbContainer.java:129)
at
org.apache.openejb.assembler.classic.Assembler.startEjbs(Assembler.java:1361)
... 31 more
-Original Message-
From: Gropp Volker [mailto:volker.gr...@e-velopment.de]
Sent: Freitag, 9. September 2016 12:11
To: users@tomee.apache.org
Subject: RE: openejb 7 failure deploying MessageDriven (Cannot bind Container
with id Default MDB Container)
Hi,
you are correct, we are not closing EJBContainer, but it also happens on the
first test and during first deployment. We only deploy for the first test and
are closing the EJBContainer after the last one. Maybe I'm missing some config?
Thanks for your help.
Volker Gropp
-Original Message-
From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Sent: Freitag, 9. September 2016 09:59
To: users@tomee.apache.org
Subject: Re: openejb 7 failure deploying MessageDriven (Cannot bind Container
with id Default MDB Container)
Hi
the issue is not linked to the MDB but to the fact you don't close EJBContainer
between tests I think so you leak existing containers and therefore when
restart you already have existing containers.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-09-09 9:46 GMT+02:00 Gropp Volker :
> Hi,
>
> We are using openejb 7.0.0 build: 20160517-11:19 in Junit tests of our
> JEE Application. We configure openejb via EJBContainer.
> createEJBContainer(jndi.properties). Everything is working fine,
> except deploying a simple Message Driven Bean. It is implementing an
> endpoint for a JCA Adapter. Deploying other JMS MDBeans is working fine.
>
> Is there any hint how to configure this MDBean so openejb will work?
> Actually we do not need Message Driven support in our Tests. So
> another option might be as well to completely disable ActiveMQ.
>
> ...
> 19:27.100 #INFO O.startup Thread pool size for 'Default JMS Resource
> Adapter' is (30)
> 19:27.109 #INFO O.s.service ActiveMQ5Factory creating broker
> 19:27.148 #INFO O.s.service Using ActiveMQ startup timeout of 1ms
> 19:27.148 #INFO O.s.service Starting ActiveMQ BrokerService
> 19:27.242 #INFO o.a.a.b.BrokerService Using Persistence Adapter:
> MemoryPersistenceAdapter
> 19:27.294 #INFO o.a.a.b.j.ManagementContext JMX consoles can connect
> to service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi
> 19:27.404 #INFO o.a.a.b.BrokerService Apache ActiveMQ 5.13.3
> (localhost,
> ID:LVS-01-64923-1473405567269-0:1) is starting
> 19:27.411 #INFO o.a.a.b.BrokerService Apache ActiveMQ 5.13.3
> (localhost,
> ID:LVS-01-64923-1473405567269-0:1) started
> 19:27.411 #INFO o.a.a.b.BrokerService For help or more information
> please
> see: http://activemq.apache.org
> 19:27.434 #INFO O.s.service Starting ActiveMQ checkpoint
> 19:27.435 #INFO O.s.service ActiveMQ broker started
> 19:27.435 #INFO O.s.service Creating Container(id=Default MDB
> Container)
> 19:27.440 #INFO O.s.config Configuring Service(id=SimpleJmsQueue,
> type=Resource, provider-id=Default Queue)
> 19:27.440 #INFO O.s.config Auto-creating a Resource with id
> SimpleJmsQueue of type 'javax.jms.Queue for 'SimpleJmsListenerMDB'.
> 19:27.440 #INFO O.s.service Creating Resource(id= SimpleJmsQueue)
> 19:27.445 #INFO O.s.config Configuring Service(id=Default MDB
> Container, type=Container, provider-id=Default MDB Container)
> 19:27.445 #INFO O.s.config Auto-creating a container for bean
> SocketMessageDriven: Container(type=MESSAGE, id=Default MDB Container)
> 19:27.445 #INFO O.s.service Creating Container(id=Default MDB
> Container)
> 19:27.447 #WARN O.startup configureApplication.loadFailed
> org.apache.openejb.OpenEJBException: Cannot bind Container with id
> Default MDB Container : ParsedName{path=openejb/
RE: openejb 7 failure deploying MessageDriven (Cannot bind Container with id Default MDB Container)
Hi,
you are correct, we are not closing EJBContainer, but it also happens on the
first test and during first deployment. We only deploy for the first test and
are closing the EJBContainer after the last one. Maybe I'm missing some config?
Thanks for your help.
Volker Gropp
-Original Message-
From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Sent: Freitag, 9. September 2016 09:59
To: users@tomee.apache.org
Subject: Re: openejb 7 failure deploying MessageDriven (Cannot bind Container
with id Default MDB Container)
Hi
the issue is not linked to the MDB but to the fact you don't close EJBContainer
between tests I think so you leak existing containers and therefore when
restart you already have existing containers.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-09-09 9:46 GMT+02:00 Gropp Volker :
> Hi,
>
> We are using openejb 7.0.0 build: 20160517-11:19 in Junit tests of our
> JEE Application. We configure openejb via EJBContainer.
> createEJBContainer(jndi.properties). Everything is working fine,
> except deploying a simple Message Driven Bean. It is implementing an
> endpoint for a JCA Adapter. Deploying other JMS MDBeans is working fine.
>
> Is there any hint how to configure this MDBean so openejb will work?
> Actually we do not need Message Driven support in our Tests. So
> another option might be as well to completely disable ActiveMQ.
>
> ...
> 19:27.100 #INFO O.startup Thread pool size for 'Default JMS Resource
> Adapter' is (30)
> 19:27.109 #INFO O.s.service ActiveMQ5Factory creating broker
> 19:27.148 #INFO O.s.service Using ActiveMQ startup timeout of 1ms
> 19:27.148 #INFO O.s.service Starting ActiveMQ BrokerService
> 19:27.242 #INFO o.a.a.b.BrokerService Using Persistence Adapter:
> MemoryPersistenceAdapter
> 19:27.294 #INFO o.a.a.b.j.ManagementContext JMX consoles can connect
> to service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi
> 19:27.404 #INFO o.a.a.b.BrokerService Apache ActiveMQ 5.13.3
> (localhost,
> ID:LVS-01-64923-1473405567269-0:1) is starting
> 19:27.411 #INFO o.a.a.b.BrokerService Apache ActiveMQ 5.13.3
> (localhost,
> ID:LVS-01-64923-1473405567269-0:1) started
> 19:27.411 #INFO o.a.a.b.BrokerService For help or more information
> please
> see: http://activemq.apache.org
> 19:27.434 #INFO O.s.service Starting ActiveMQ checkpoint
> 19:27.435 #INFO O.s.service ActiveMQ broker started
> 19:27.435 #INFO O.s.service Creating Container(id=Default MDB
> Container)
> 19:27.440 #INFO O.s.config Configuring Service(id=SimpleJmsQueue,
> type=Resource, provider-id=Default Queue)
> 19:27.440 #INFO O.s.config Auto-creating a Resource with id
> SimpleJmsQueue of type 'javax.jms.Queue for 'SimpleJmsListenerMDB'.
> 19:27.440 #INFO O.s.service Creating Resource(id= SimpleJmsQueue)
> 19:27.445 #INFO O.s.config Configuring Service(id=Default MDB
> Container, type=Container, provider-id=Default MDB Container)
> 19:27.445 #INFO O.s.config Auto-creating a container for bean
> SocketMessageDriven: Container(type=MESSAGE, id=Default MDB Container)
> 19:27.445 #INFO O.s.service Creating Container(id=Default MDB
> Container)
> 19:27.447 #WARN O.startup configureApplication.loadFailed
> org.apache.openejb.OpenEJBException: Cannot bind Container with id
> Default MDB Container : ParsedName{path=openejb/Container/Default MDB
> Container, component=Default MDB Container}
>at
> org.apache.openejb.assembler.classic.Assembler.bindService(Assembler.j
> ava:2682)
> ~[openejb-core-7.0.0.jar:7.0.0]
>at org.apache.openejb.assembler.classic.Assembler.
> createContainer(Assembler.java:2652) ~[openejb-core-7.0.0.jar:7.0.0]
>at
> org.apache.openejb.config.ConfigurationFactory.install(ConfigurationFa
> ctory.java:445)
> ~[openejb-core-7.0.0.jar:7.0.0]
>at
> org.apache.openejb.config.AutoConfig.createContainer(AutoConfig.java:1
> 146)
> ~[openejb-core-7.0.0.jar:7.0.0]
>at
> org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:855)
> ~[openejb-core-7.0.0.jar:7.0.0]
>at
> org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:201)
> ~[openejb-core-7.0.0.jar:7.0.0]
>at org.apache.openejb.config.ConfigurationFactory$Chain.
> deploy(ConfigurationFactory.java:417) ~[openejb-core-7.0.0.jar:7.0.0]
>at org.apache.openejb.config.ConfigurationFactory.
> configureApplica
openejb 7 failure deploying MessageDriven (Cannot bind Container with id Default MDB Container)
Hi,
We are using openejb 7.0.0 build: 20160517-11:19 in Junit tests of our JEE
Application. We configure openejb via
EJBContainer.createEJBContainer(jndi.properties). Everything is working fine,
except deploying a simple Message Driven Bean. It is implementing an endpoint
for a JCA Adapter. Deploying other JMS MDBeans is working fine.
Is there any hint how to configure this MDBean so openejb will work? Actually
we do not need Message Driven support in our Tests. So another option might be
as well to completely disable ActiveMQ.
...
19:27.100 #INFO O.startup Thread pool size for 'Default JMS Resource Adapter'
is (30)
19:27.109 #INFO O.s.service ActiveMQ5Factory creating broker
19:27.148 #INFO O.s.service Using ActiveMQ startup timeout of 1ms
19:27.148 #INFO O.s.service Starting ActiveMQ BrokerService
19:27.242 #INFO o.a.a.b.BrokerService Using Persistence Adapter:
MemoryPersistenceAdapter
19:27.294 #INFO o.a.a.b.j.ManagementContext JMX consoles can connect to
service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi
19:27.404 #INFO o.a.a.b.BrokerService Apache ActiveMQ 5.13.3 (localhost,
ID:LVS-01-64923-1473405567269-0:1) is starting
19:27.411 #INFO o.a.a.b.BrokerService Apache ActiveMQ 5.13.3 (localhost,
ID:LVS-01-64923-1473405567269-0:1) started
19:27.411 #INFO o.a.a.b.BrokerService For help or more information please see:
http://activemq.apache.org
19:27.434 #INFO O.s.service Starting ActiveMQ checkpoint
19:27.435 #INFO O.s.service ActiveMQ broker started
19:27.435 #INFO O.s.service Creating Container(id=Default MDB Container)
19:27.440 #INFO O.s.config Configuring Service(id=SimpleJmsQueue,
type=Resource, provider-id=Default Queue)
19:27.440 #INFO O.s.config Auto-creating a Resource with id SimpleJmsQueue of
type 'javax.jms.Queue for 'SimpleJmsListenerMDB'.
19:27.440 #INFO O.s.service Creating Resource(id= SimpleJmsQueue)
19:27.445 #INFO O.s.config Configuring Service(id=Default MDB Container,
type=Container, provider-id=Default MDB Container)
19:27.445 #INFO O.s.config Auto-creating a container for bean
SocketMessageDriven: Container(type=MESSAGE, id=Default MDB Container)
19:27.445 #INFO O.s.service Creating Container(id=Default MDB Container)
19:27.447 #WARN O.startup configureApplication.loadFailed
org.apache.openejb.OpenEJBException: Cannot bind Container with id Default MDB
Container : ParsedName{path=openejb/Container/Default MDB Container,
component=Default MDB Container}
at
org.apache.openejb.assembler.classic.Assembler.bindService(Assembler.java:2682)
~[openejb-core-7.0.0.jar:7.0.0]
at
org.apache.openejb.assembler.classic.Assembler.createContainer(Assembler.java:2652)
~[openejb-core-7.0.0.jar:7.0.0]
at
org.apache.openejb.config.ConfigurationFactory.install(ConfigurationFactory.java:445)
~[openejb-core-7.0.0.jar:7.0.0]
at
org.apache.openejb.config.AutoConfig.createContainer(AutoConfig.java:1146)
~[openejb-core-7.0.0.jar:7.0.0]
at org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:855)
~[openejb-core-7.0.0.jar:7.0.0]
at org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:201)
~[openejb-core-7.0.0.jar:7.0.0]
at
org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:417)
~[openejb-core-7.0.0.jar:7.0.0]
at
org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:1023)
~[openejb-core-7.0.0.jar:7.0.0]
at
org.apache.openejb.OpenEjbContainer$Provider.createEJBContainer(OpenEjbContainer.java:321)
~[openejb-core-7.0.0.jar:7.0.0]
at
javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:102)
~[javax.ejb_3.3.0-12.1.3-0-0.jar:3.3.0]
at
de.evelopment.openejb.util.EjbTestHelper.startContainer(EjbTestHelper.java:84)
~[bin/:?]
at de.evelopment.openejb.EjbTestCase.startUp(EjbTestCase.java:33)
~[bin/:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
~[?:1.8.0_92]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
~[?:1.8.0_92]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[?:1.8.0_92]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_92]
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
~[junit-4.12.jar:4.12]
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
~[junit-4.12.jar:4.12]
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
~[junit-4.12.jar:4.12]
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
~[junit-4.12.jar:4.12]
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
~[junit-4.12.jar:4.12]
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
~[junit-4.12.jar:4.12]
at org.junit.rules.RunRules.evaluat
RE: Hibernate Validator class scanning in OpenEjb 7.0.0-M1
Hi, thanks for the fast reply. I'm now using in my beans.xml, it's a lot faster. I'm also using openejb.deployments.classpath.include and openejb.deployments.classpath.exclude and I try to limit the packages by using a scan.xml (in META-INF) with only specific packages. Older Hibernate Validator Versions (5.0.0) did not help. I still see warnings about some packages like java.util.HashMap.java.util.HashMap$TreeNode, but maybe it's because those are used in beans? Is there any other trick to limit the scanning I might try? I could not find a nice documentation about how to configure such things. OpenEjb still mentions " openejb.deployments.package.exclude". Regards Volker -Original Message- From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] Sent: Mittwoch, 24. Februar 2016 18:26 To: users@tomee.apache.org Subject: Re: Hibernate Validator class scanning in OpenEjb 7.0.0-M1 Hi if you can share some jstack dump in the "slow" period it could help to tackle that. Also maybe try previous releases - know they fixed some inheritance bugs so maybe they added some overhead by side effect. Bean validation scanning should be limited to CDI during startup so same tricks as for CDI should work. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> 2016-02-24 18:11 GMT+01:00 Gropp Volker : > Hi, > > we are upgrading our openejb-based unit-tests of a fairly large > JEE-app to OpenEjb 7.0.0-M1 and I noticed a very slow startup while > scanning all classes for Bean Validation with Hibernate Validator 5 > 5.2.2.Final. Is there any way to limit classes/packages which are > scanned by Hibernate Validator or to disable it completely (in our > tests)? Maybe this is not a problem solely in 7.0.0-M1, but I noticed > it because of lot of warnings/errors while starting up the container. > > Regards, > > Volker Gropp >
Hibernate Validator class scanning in OpenEjb 7.0.0-M1
Hi, we are upgrading our openejb-based unit-tests of a fairly large JEE-app to OpenEjb 7.0.0-M1 and I noticed a very slow startup while scanning all classes for Bean Validation with Hibernate Validator 5 5.2.2.Final. Is there any way to limit classes/packages which are scanned by Hibernate Validator or to disable it completely (in our tests)? Maybe this is not a problem solely in 7.0.0-M1, but I noticed it because of lot of warnings/errors while starting up the container. Regards, Volker Gropp
