November 2009 - jboss-dev-forums - Jboss List Archives

[JBoss Microcontainer Development] - Re: Dependency on non-existant bean when trying to create

by alesj

Yes, this is somehow expected. PropertyMD --> ValueMD --> BeanMD --> inner bean --> dependency AbstractValueMD::getChildren doesn't distinguish between plain properly value and metadata value. Normally MC metadata should be hidden for POJOs, so I wouldn't put too much effort into this --> would go with a wrapper. Perhaps you can add this to BMDBuilder: | <T> T wrap(T impl, Class<T> clazz) | { | return new MetaDataWrapper<T>(impl, clazz); | } | | public class MetaDataWrapper<T> | { | T impl; | Class<T> clazz; | | public MetaDataWrapper(T impl, Class<T> clazz) { ... } | | public T unwrap() { return impl; } | } | which hides the actual metadata in generic way. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4263812#4263812 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4263812

14 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: AS weld-int

by kabir.khan＠jboss.com

"alesj" wrote : Yeah, something in this "delegate" direction. | | I would simply install a new temp bean, | which gets BeanManager injected at a proper state. | I've had some success with this. The main stumbling block at the moment is that each of my tests run in isolation is fine, but if I try to run them all I get an error on next test setup: | java.lang.IllegalStateException: Incompletely deployed: | | DEPLOYMENTS MISSING DEPENDENCIES: | Deployment "vfs://top-level.ear/BootstrapBeanInstaller=SimpleBean" is missing the following dependencies: | Dependency "vfs://top-level.ear/_JBossDeployment" (should be in state "Installed", but is actually not found) | Dependency "vfs://top-level.ear/_WeldBootstrapBean" (should be in state "Create", but is actually not found) | | at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.internalValidate(AbstractKernelDeployer.java:278) | at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.validate(AbstractKernelDeployer.java:174) | at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.validate(MicrocontainerTestDelegate.java:262) | at org.jboss.test.kernel.junit.MicrocontainerTest.afterSetUp(MicrocontainerTest.java:117) | at org.jboss.test.kernel.junit.MicrocontainerTest.setUp(MicrocontainerTest.java:91) | at org.jboss.test.deployers.BootstrapDeployersTest.setUp(BootstrapDeployersTest.java:350) | at org.jboss.test.deployers.test.AbstractWeldTest.setUp(AbstractWeldTest.java:59) | 'vfs://top-level.ear/BootstrapBeanInstaller=SimpleBean' is the "intermediate" bean that installs SimpleBean once BootstrapBean is installed. How to make sure it gets uninstalled along with the deployment? I tried adding it as an attachment in the WeldKernelControllerContextCreator (used by BeanMetaDataDeployer) which creates this bean but it is not uninstalled. To summarize, I have a bean called SimpleBean. BMDDeployer + WeldKernelControllerContextCreator install 'vfs://top-level.ear/BootstrapBeanInstaller=SimpleBean' instead, and this in turn installs SimpleBean in its start() method. On uninstall BMDDeployer.undeploy() gets called with SimpleBean, but not with 'vfs://top-level.ear/BootstrapBeanInstaller=SimpleBean'. I will see if I can make 'vfs://top-level.ear/BootstrapBeanInstaller=SimpleBean' uninstall itself, but it feels a bit strange to do that from its start() method. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4263811#4263811 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4263811

14 years, 5 months

1
0
0 / 0

[Embedded JBoss Development] - Re: ShrinkWrap Logo Design

by ALRubinger

Colors are in. http://www.jboss.org/files/jbosslabs/design/shrinkwrap/logo/images/shrink... Input welcome: http://doodle.com/qtqhf7z6we6sp3qx S, ALR View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4263810#4263810 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4263810

14 years, 5 months

1
0
0 / 0

[JBoss Web Services Development] - Access SOAP message content

by oechevarria

Hello, I have an implementation of a web service using the @WebServiceProvider annotation. This web service receives a SOAP message (via the public SOAPMessage invoke(SOAPMessage soapMessage) API). I am trying to get the contents of the message using the standard API calls such as SOAPPart soapPart = message.getSOAPPart(); Source source = soapPart.getContent(); However getSOAPPart() gives me what appears to be a partial message, i.e the contents of the body are empty even though the envelope and the header are good. Further, if I 'print' the message using an output stream I am able to see the entire message contents. Can anyone provide any clues as to what may be happening? I am using JBoss AS 5.1.0 and JBoss WS native 3.2.0 on Windows. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4263807#4263807 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4263807

14 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development] - Dependency on non-existant bean when trying to create

by kabir.khan＠jboss.com

What's wrong with this? Attempting to add the intermediate bean mentioned in http://www.jboss.org/index.html?module=bb&op=viewtopic&t=162791. I found that adding BeanMetaData as a property to a bean seems to cause an unresolved dependency: | public class ThrowawayTestCase extends MicrocontainerTest | { | | public ThrowawayTestCase(String name) | { | super(name); | } | | | public void testIndirectBean() throws Throwable | { | BeanMetaDataBuilder builder = BeanMetaDataBuilder.createBuilder("Bean", MyBean.class.getName()); | BeanMetaData bmd = builder.getBeanMetaData(); | | builder = BeanMetaDataBuilder.createBuilder("BeanInstaller", MyBeanInstaller.class.getName()); | // builder.addPropertyMetaData("context", builder.createFromContextInject(FromContext.CONTEXT)); //1 | builder.addPropertyMetaData("beanMetaData", builder.createValue(bmd)); //2 | KernelControllerContext ctx = deploy(builder.getBeanMetaData()); | try | { | System.out.println("----------> " + ctx.getDependencyInfo().getIDependOn(null)); | MyBeanInstaller myBeanInstaller = assertBean("BeanInstaller", MyBeanInstaller.class); | | // MyBean myBean = assertBean("MyBean", MyBean.class); | // assertNotNull(myBean); | } | finally | { | undeploy(ctx); | } | } | | public static class MyBeanInstaller | { | KernelControllerContext context; | | BeanMetaData beanMetaData; | | boolean started; | | public BeanMetaData getBeanMetaData() | { | return beanMetaData; | } | | public void setBeanMetaData(BeanMetaData beanMetaData) | { | this.beanMetaData = beanMetaData; | } | | public KernelControllerContext getContext() | { | return context; | } | | public void setContext(KernelControllerContext context) | { | this.context = context; | } | | public boolean isStarted() | { | return started; | } | | public void start() throws Exception | { | //Use context.getController() and beanmetadata to install indirect bean | } | } | | public static class MyBean | { | } | } | The output dependency info is shown as: | ----------> [AbstractDependencyItem@5f49d886{name=BeanInstaller dependsOn=Bean whenRequired=Configured dependentState=Installed resolved=false}] | Looking at the stack trace of AbstractDependencyItem's constructor it looks like the property value gets visited as well? | Thread [main] (Suspended (breakpoint at line 78 in AbstractDependencyItem)) | AbstractDependencyItem.<init>(Object, Object, ControllerState, ControllerState) line: 78 | AbstractBeanMetaData.initialVisit(MetaDataVisitor) line: 669 | PreprocessMetaDataVisitor(AbstractMetaDataVisitor).internalInitialVisit(MetaDataVisitorNode) line: 111 | PreprocessMetaDataVisitor(AbstractMetaDataVisitor).initialVisit(MetaDataVisitorNode) line: 74 | AbstractValueMetaData.initialVisit(MetaDataVisitor) line: 116 | PreprocessMetaDataVisitor(AbstractMetaDataVisitor).internalInitialVisit(MetaDataVisitorNode) line: 111 | PreprocessMetaDataVisitor(AbstractMetaDataVisitor).initialVisit(MetaDataVisitorNode) line: 74 | AbstractPropertyMetaData(AbstractFeatureMetaData).initialVisit(MetaDataVisitor) line: 101 | AbstractPropertyMetaData.initialVisit(MetaDataVisitor) line: 287 | PreprocessMetaDataVisitor(AbstractMetaDataVisitor).internalInitialVisit(MetaDataVisitorNode) line: 111 | PreprocessMetaDataVisitor(AbstractMetaDataVisitor).initialVisit(MetaDataVisitorNode) line: 74 | AbstractBeanMetaData(AbstractFeatureMetaData).initialVisit(MetaDataVisitor) line: 101 | AbstractBeanMetaData.initialVisit(MetaDataVisitor) line: 680 | PreprocessMetaDataVisitor.run() line: 53 | AccessController.doPrivileged(PrivilegedAction<T>) line: not available [native method] | AbstractKernelControllerContext.preprocessMetaData() line: 232 | AbstractKernelControllerContext.setController(Controller) line: 198 | AbstractKernelController(AbstractController).install(ControllerContext, boolean) line: 778 | AbstractKernelController(AbstractController).install(ControllerContext) line: 564 | AbstractKernelController.install(BeanMetaData, Object) line: 107 | AbstractKernelController.install(BeanMetaData) line: 101 | MicrocontainerTestDelegate.deploy(BeanMetaData) line: 329 | ThrowawayTestCase(MicrocontainerTest).deploy(BeanMetaData) line: 358 | ThrowawayTestCase.testIndirectBean() line: 54 | I'm not sure this is something we should fix, without a better understanding of how the value metadata is visited. I can work around it by creating an intermediate class | public static class BeanMetaDataWrapper | { | private final BeanMetaData beanMetaData; | | public BeanMetaDataWrapper(BeanMetaData beanMetaData) | { | this.beanMetaData = beanMetaData; | } | | public BeanMetaData getBeanMetaData() | { | return beanMetaData; | } | } | and to set that instead when creating BeanInstaller | builder.addPropertyMetaData("beanMetaDataWrapper", builder.createValue(wrapper)); | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4263782#4263782 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4263782

14 years, 5 months

1
0
0 / 0

[JBoss Web Services Development] - Re: jms transport support in jbossws-cxf

by alessio.soldano＠jboss.com

Jim, Richard suggestion (add a DA to set the JMSEndpointAddress) is good. Thanks Richard. I'd just suggest few additional things that might be useful too: - consider taking a look at the CXF JMSTransportFactory, perhaps there's an easy hook for getting/setting the address. We currently overwrite the SoapTransportFactory in the bus in CXFServletExt.loadBus(..) in order to implement our own soap address rewriting rules for http endpoints. Perhaps a similar approach might be useful here (extending the jms transport factory, etc.) for the jms case. - we might think about something (an annotation?) to mark a jms endpoint when doing java-first, assuming there's not an equivalent way in CXF yet. That could be looked for in the DA to properly write the jbossws-cxf that is generated on the fly when not provided by the user. - is the CXF JMSFeature (http://cxf.apache.org/docs/using-the-jmsconfigfeature.html) configuration of any use to us? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4263779#4263779 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4263779

14 years, 5 months

1
0
0 / 0

[jBPM Development] - Re: Multiple instances with synchronization

by kukeltje

E.g. by migrating the wiki example for jBPM 3 to jBPM 4 initially. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4263750#4263750 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4263750

14 years, 5 months

1
0
0 / 0

[jBPM Development] - Re: Issue #JBPM-2537

by kukeltje

if (deleted == cancelled && relevantHistoryData.present() == true) { | ronald.setHappy(true); | ronald.whineMode(off); | } View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4263749#4263749 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4263749

14 years, 5 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Change in manifest parser breaks symbolic name

by adrian＠jboss.org

This has been done, but I've still got https://jira.jboss.org/jira/browse/JBOSGI-200 TODO View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4263738#4263738 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4263738

14 years, 5 months

1
0
0 / 0

[EJB 3.0 Development] - Multiple remote interfaces

by pio1k

Is there in JBoss 4.2.3 a possibility to have multiple remote interfaces for the same session bean (EJB 3.0)? I've found similar problem: http://www.mailinglistarchive.com/jboss-user@lists.jboss.org/msg131545.html without any answer. I want to have two remote interfaces (both are deployed on server). One of them is vissible in client appliction and second one isn't. When I'm making lookup to visible interface I get this exception: javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: <name of invisible interface> (no security manager: RMI class loader disabled)] Maybe someone could help me? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4263725#4263725 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4263725

14 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2009