[Design of the JBoss EJB Container] - Problem with several Seam based jars during startup
by yure
Hi,
I have spited my application to 2 separated projects (to reuse in future).
After splitting I built 2 jars. Every parts has own configuration in META-INF folder:
components.xml
ejb-jar.xml
jboss-beans.xml
persistence.xml
to access differnet databases and have different entities.
Now I'm trying to start my application. During startup I see in logs that first part is deployed without problems. But for second one I get such error:
2008-02-17 23:43:42,060 [Thread-1] INFO - starting up: ejbTEST2
2008-02-17 23:43:42,060 [Thread-1] INFO - starting the embedded EJB container
2008-02-17 23:43:42,091 [Thread-1] ERROR - Error installing to Start: name=TransactionManagerInitializer state=Create
javax.naming.NameAlreadyBoundException
at org.jnp.server.NamingServer.bind(NamingServer.java:144)
I used in components.xml such lines to init first part:
<core:init debug="true" jndi-pattern="#{ejbName}/local"/>
<core:ejb name="ejbTEST" installed="true"/>
For second I used only one this line:
<core:ejb name="ejbTEST2" installed="true"/>
Please, help me to resolve this issue.
Thanks!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130038#4130038
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130038
18 years, 1 month
[Design of OSGi Integration] - BundleActivatorDeployer Questions
by johnbailey
Currently there is a deployer for the MetaData and BundleActivator. I am not sure the BundleActivator deployer makes sense. I understand how it is working, but looking through the API for OSGI it seems pretty clear the BundleActivator should be started/stopped during the start and stop invocations on the Bundle itself (http://www.osgi.org/javadoc/r4/org/osgi/framework/Bundle.html#start(int) - see step 8).
In the BundleActivatorDeploymentVisitor a BundleContext is created, which will lazily create the Bundle. BeanMeteData for the BundleActivator is then installed into the controller with start and stop parameters of the BundleContext.
| public void deploy(DeploymentUnit unit, OSGiMetaData deployment) throws DeploymentException
| {
| String bundleActivator = deployment.getBundleActivator();
| if (bundleActivator != null)
| {
| String name = createBundleActivatorBeanName(deployment);
| // todo - get deployment context in non-depricated way
| BundleContext bundleContext = new BundleContextImpl(unit);
| BeanMetaDataBuilder builder =
| BeanMetaDataBuilderFactory.createBuilder(name, bundleActivator)
| .addStartParameter(BundleContext.class.getName(), bundleContext)
| .addStopParameter(BundleContext.class.getName(), bundleContext);
| BeanMetaData beanMetaData = builder.getBeanMetaData();
| try
| {
| controller.install(beanMetaData);
| }
| catch (Throwable throwable)
| {
| throw DeploymentException.rethrowAsDeploymentException("Unable to install BundleActivator.", throwable);
| }
| }
| }
|
Would it make sense to use the Deployer to instead create BeanMetaData for the Bundle itself and install it with the start and stop applied to the Bundle, which will internally call the BundleActivator when the Bundle is started? It also seems like the BundleActivator BundleContext should only live within the context of the Bundle and should not be available to any other Bundle or Kernel service.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4129931#4129931
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4129931
18 years, 1 month
[Design of the JBoss EJB Container] - Re: jndi lookup during restart
by bstansberry＠jboss.com
OK, sounds like you probably have 4.2.0.GA_CP01; don't know why the jar was named "CR1". CR sounds for "Candidate for Release", i.e. a release soon before the GA; that's not something one should use after the GA comes out. CP stands for "Cumulative Patch"; that's a bug-fix release made after GA and provided to subscription customers.
CP releases don't include fixes for every issue found after a GA comes out; we find many customers prefer that changes in CPs are minimal and that fixes are limited to those requested by customers or critical issues like security patches. Based on that, the JBAS-4622 hasn't been ported to the EAP 4.2 CP branch yet. If you're a customer and want to see that fixed in the next EAP 4.2 CP release, I suggest you raise an issue on the Customer Support Portal.
All that said, you're actually interested in JBREM-906 anyway. :-) I don't know enough about the remoting code to know if the same basic problem is there, but from looking at the stack trace, it seems pretty likely. Basically, any RMI-based transport is vulnerable to the problem of a client holding onto an RMI stub that no longer matches the server. Do you need to use an RMI connector?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4129849#4129849
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4129849
18 years, 1 month