August 2008 - jboss-dev-forums - Jboss List Archives

[Design of JCA on JBoss] - Re: messagingType optional issue

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : We are seeing problems with some of the tck tests not supplying a message-destination-type (it is optional in javaee5) and the activation layer complaining about this: | | | | 23:38:41,162 INFO [EJBContainer] STARTED EJB: com.sun.ts.tests.ejb30.bb.mdb.dest.common.DestBean ejbName: DestBean | | 23:38:41,225 ERROR [AbstractKernelController] Error installing to Start: name=jboss.j2ee:ear=mdb_dest_optional.ear,jar=mdb_dest_optional_ejb.jar,name=DestBean,service=EJB3 state=Create | | org.jboss.deployers.spi.DeploymentException: Required config property RequiredConfigPropertyMetaData@350bd2[name=destinationType descriptions=[DescriptionMetaData@c234ef[language=en]]] for messagingType 'javax.jms.MessageListener' not found in activation config [ActivationConfigProperty(password=j2ee), ActivationConfigProperty(user=j2ee), ActivationConfigProperty(destination=MDB_QUEUE), ActivationConfigProperty(subscriptionDurability=false)] ra=jboss.jca:service=RARDeployment,name='jms-ra.rar' | | at org.jboss.resource.deployment.ActivationSpecFactory.createActivationSpec(ActivationSpecFactory.java:95) | | at org.jboss.resource.deployers.RARDeployment.createActivationSpec(RARDeployment.java:313) | | at org.jboss.resource.deployers.RARDeployment.internalInvoke(RARDeployment.java:277) | | at org.jboss.system.ServiceDynamicMBeanSupport.invoke(ServiceDynamicMBeanSupport.java:156 | | | | Do we need to fill this info in | Yes you do. The jms parameters are non-normative in the spec so this can't be a compliance issue. JavaEE connectors 1.5 appendix B What that section does say is that the destinationType should be required if it is not in the legacy mdb descriptor: B-2.1.2 anonymous wrote : | This property requires a value to be specified. The endpoint deployer must provide | a value for this property (if it is not already present in the endpoint deployment | descriptor). | It is also documentated as mandatory here: http://wiki.jboss.org/wiki/ConfigJMSMessageListener We do copy it from the legacy mdb descriptor when it is not in the activation spec and the jms inflow is configured See org.jboss.ejb.plugins.JBossJMSMessageEndpointFactory. So quick fix: Just add the destinationType activation config property to jboss.xml anonymous wrote : | or should this be getting defaulted? | We could try to default it by looking at the interfaces of the destination. Nice for ease of use, but bad for people writing portable applications, i.e. works on JBoss but fails on others because of missing mandatory configuration. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168688#4168688 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168688

17 years, 4 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: messagingType optional issue

by jesper.pedersen

The JMS resource adaptor creates a connection to either a queue or a topic based on this information. The other mandatory property is destination. There is no way of knowing if the destination is a queue or a topic based only on the name of the destination. Therefore we can't set a correct default value if the destinationType property isn't filled in. I guess that you are on page 109 of the JavaEE 5 spec in regards to injected resources - which states that the message-destination-type defaults to the injected target if not specified. I think that the best solution would be to take the information from the injected target and fill in the information behind the scenes and leave the requirement of the JMS resource adaptor. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168677#4168677 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168677

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Pushing correct aspect manager for a deployment

by alesj

"adrian(a)jboss.org" wrote : | Let me do the StructureContext stuff today. | | I'm going to do it in a backwards compatible way initially and deprecate | the old api. | | That way we do a 2 phase change. i.e. add the new api in the beta | and remove the old one in CR1 of deployers. | OK, I'll wait for it. And then I'll try to do my part depending on your today's work: - https://jira.jboss.org/jira/browse/JBDEPLOY-67 Once I'm done, I'll start the release process. First doing Reflect and MDR CR1, and then betas of all the rest. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168670#4168670 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168670

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Pushing correct aspect manager for a deployment

by adrian＠jboss.org

"alesj" wrote : "adrian(a)jboss.org" wrote : You should be able to try this when Ales does the betas this week. | So, we're fine to do the last round of betas? | Let me do the StructureContext stuff today. I'm going to do it in a backwards compatible way initially and deprecate the old api. That way we do a 2 phase change. i.e. add the new api in the beta and remove the old one in CR1 of deploiyers. anonymous wrote : | Or can I even do CR1 of Reflect and MDR? | If yes, I'll do it first thing tomorrow morning. | I don't have a problem with doing CRs for reflect and mdr. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168668#4168668 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168668

17 years, 4 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: Problem with JBoss Profiler 2 Beta install.

by jesper.pedersen

Strange - as you can 'jar tf' the file. Could you try and build the agent yourself from the source ? The SVN is located at http://anonsvn.jboss.org/repos/jbossprofiler/branches/JBossProfiler2 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168653#4168653 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168653

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Pushing correct aspect manager for a deployment

by alesj

"adrian(a)jboss.org" wrote : You should be able to try this when Ales does the betas this week. So, we're fine to do the last round of betas? Or can I even do CR1 of Reflect and MDR? If yes, I'll do it first thing tomorrow morning. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168649#4168649 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168649

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Pushing correct aspect manager for a deployment

by adrian＠jboss.org

You should be able to try this when Ales does the betas this week. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168646#4168646 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168646

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Pushing correct aspect manager for a deployment

by adrian＠jboss.org

Jira: [URL]https://jira.jboss.org/jira/browse/JBDEPLOY-69[/url] View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168644#4168644 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168644

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Pushing correct aspect manager for a deployment

by adrian＠jboss.org

"kabir.khan(a)jboss.com" wrote : I have attempted to add the correct manager to the metadata for the deployment in my deployer | | | unit.getMutableMetaData().addMetaData(scopedManager, AspectManager.class); | | | | This gets added to a MemoryMetaDataLoader with | | | ScopeKey=[APPLICATION=vfszip:/Users/kabir/sourcecontrol/jboss-head/testsuite/output/lib/aop-scopeddependency-scoped.sar] | | | | However, the bean's MetaData does not contain that, it only contains MetaDataRetrievals for the following levels: | | | WORK=10814978] | | [INSTANCE=ScopedManager_6_vfszip:/Users/kabir/sourcecontrol/jboss-head/testsuite/output/lib/aop-scopeddependency-scoped.sar] | | [CLASS=class org.jboss.test.aop.scopeddependency.ScopedTester] | | [JVM=THIS] | | | Is this a bug, or have I completely misunderstood? | | It's not implemented. The ScopeInfo used by the KernelControllerContext that it passes to the metadata repository is not populated from the scope created for the Deployment component by the ScopeBuilder. To make this work, you'd need something like the following (untested): | Index: src/main/org/jboss/deployers/vfs/deployer/kernel/BeanMetaDataDeployer.java | =================================================================== | --- src/main/org/jboss/deployers/vfs/deployer/kernel/BeanMetaDataDeployer.java (revision 76634) | +++ src/main/org/jboss/deployers/vfs/deployer/kernel/BeanMetaDataDeployer.java (working copy) | @@ -27,12 +27,14 @@ | import org.jboss.beans.metadata.spi.ClassLoaderMetaData; | import org.jboss.beans.metadata.spi.ValueMetaData; | import org.jboss.dependency.spi.Controller; | +import org.jboss.dependency.spi.ScopeInfo; | import org.jboss.deployers.spi.DeploymentException; | import org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer; | import org.jboss.deployers.structure.spi.DeploymentUnit; | import org.jboss.kernel.Kernel; | import org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext; | import org.jboss.kernel.spi.dependency.KernelControllerContext; | +import org.jboss.metadata.spi.scope.ScopeKey; | | /** | * BeanMetaDataDeployer.<p> | @@ -108,6 +110,9 @@ | } | } | KernelControllerContext context = new AbstractKernelControllerContext(null, deployment, null); | + ScopeInfo scopeInfo = context.getScopeInfo(); | + scopeInfo.setScope(unit.getScope()); | + scopeInfo.setMutableScope(unit.getMutableScope()); | try | { | controller.install(context); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168631#4168631 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168631

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Pushing correct aspect manager for a deployment

by alesj

"kabir.khan(a)jboss.com" wrote : | Is this a bug, or have I completely misunderstood? | Misunderstood. :-) I really don't see exactly what you're trying to do, so I'll try to guess as I don't understand how scoped aspect domains work. ;-) Probably this is not an issue with scoped beans, since we've gone over that - proper @annotation + PreInstallAction do all the tricks. Or is it, since I see you've got something called scopedManager: | unit.getMutableMetaData().addMetaData(scopedManager, AspectManager.class); | Perhaps what you're missing here, is what I've added to scoped kernels impl - the @Search notion. Meaning you can localize your loookup - in this case just the same scope, not doing any parent lookup. Hence dependency doesn't depend on the order global and scoped aspect manager are deployed. But this is currently only annotation based, no xml. As for DeploymentUnit and its MetaData, I don't think this is currently used. But that should be how we eventually do scoped kernels - initial control/creation from the deployment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168626#4168626 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168626

17 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums August 2008