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

[JBoss Web Services Development] - Re: Dispatch and ConfigProvider

by anil.saldhana＠jboss.com

https://jira.jboss.org/jira/browse/JBWS-2744 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252332#4252332 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252332

15 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: OSGi classloader system

by thomas.diesler＠jboss.com

For my reference http://www.jboss.org/index.html?module=bb&op=viewtopic&t=107465 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252325#4252325 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252325

15 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Web beans on top of Microcontainer deployment order

by kabir.khan＠jboss.com

Reply from Pete Muir: "kabir.khan(a)jboss.com" wrote : I have committed the initial prototype for the web beans integration. It can be found here https://svn.jboss.org/repos/jbossas/projects/kernel/trunk/webbeans-int. | | MC beans that should interact with web beans are wrapped in a WebBeansKernelControllerContext as mentioned before. It contains additional controller context actions to instantiate/inject an MC bean with web beans. It also contains an additional controller context action to store mc beans that should be available for injection to web beans in a registry. It contains a web beans AfterBeanDiscovery implementation that is used to add the mc beans to the web beans bean manager. The mc beans added to web beans are done in a custom web beans Bean implementation that takes the existing instance from mc, ignoring the calls to create it. When running in AS there will be a loads and loads of MC beans, which might unintentionally conflict, so we need to find a good way to narrow down which MC beans are available for injection into web beans. Currently, I am only registering MC beans that have web beans annotations on them (ignoring producer methods), but am open for suggestions on how to improve this. | | I am unsure how this fits together in the real world though. The WebBeansKernelControllerContext needs access to a bean manager to be able to call createCreationalContext(), createInjectionTarget() and createAnnotatedType(). | | For cases when we want to inject MC->WB, the MC beans need to be deployed and 'registered' before the web beans are deployed, and the actual bean manager to be used is created during the deployment process. I have hacked around this for now, by creating a 'bootstrap' bean manager in my tests that is available before web beans are deployed. Luckily, none of the BeanManager methods needed for this process (createAnnotatedType()) do anything with the internal state of the bean manager, so they work. | This is fine, you can access the BeanManager after Bootstrap.startContainer() is called, or after Bootstrap.startInitialization(). Beans aren't deployed until Bootstrap.deployBeans(). Though assuming you are in a container lifecycle event doing @Current BeanManager beanManager; will give you the correct manager (afaik this works). "kabir.khan(a)jboss.com" wrote : | For WB->MC injection, we need access to the correct bean manager that should be used to inject the MC beans, so createCreationalContext() and createInjectionTarget() can be called. I think for this to work we need access to the 'real' BeanManager. So, how do we determine which BeanManager should be used? | You need to determine which BeanDeploymentArchive the bean you want to access belongs to. Until Ales and I write the non-flat deployment strucutre for JBoss AS, this is a moot point really, as there is only one. Then you call BeanManager manager = bootstrap.getManager(beanDeploymentArchive); Note that normally MC beans can't access stuff inside deployments tho. I would assume we will end up with a structure like this in JBoss AS: EAR Deployment EJB JAR BDA -> Server lib/ virtual BDA WAR BDA -> Server lib/ virtual BDA -> EJB JAR BDA (where -> denotes accessibility). So you would *always* put the MC beans in the Server lib/ virtual BDA. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252253#4252253 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252253

15 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Web beans on top of Microcontainer deployment order

by kabir.khan＠jboss.com

I have committed the initial prototype for the web beans integration. It can be found here https://svn.jboss.org/repos/jbossas/projects/kernel/trunk/webbeans-int. MC beans that should interact with web beans are wrapped in a WebBeansKernelControllerContext as mentioned before. It contains additional controller context actions to instantiate/inject an MC bean with web beans. It also contains an additional controller context action to store mc beans that should be available for injection to web beans in a registry. It contains a web beans AfterBeanDiscovery implementation that is used to add the mc beans to the web beans bean manager. The mc beans added to web beans are done in a custom web beans Bean implementation that takes the existing instance from mc, ignoring the calls to create it. When running in AS there will be a loads and loads of MC beans, which might unintentionally conflict, so we need to find a good way to narrow down which MC beans are available for injection into web beans. Currently, I am only registering MC beans that have web beans annotations on them (ignoring producer methods), but am open for suggestions on how to improve this. I am unsure how this fits together in the real world though. The WebBeansKernelControllerContext needs access to a bean manager to be able to call createCreationalContext(), createInjectionTarget() and createAnnotatedType(). For cases when we want to inject MC->WB, the MC beans need to be deployed and 'registered' before the web beans are deployed, and the actual bean manager to be used is created during the deployment process. I have hacked around this for now, by creating a 'bootstrap' bean manager in my tests that is available before web beans are deployed. Luckily, none of the BeanManager methods needed for this process (createAnnotatedType()) do anything with the internal state of the bean manager, so they work. For WB->MC injection, we need access to the correct bean manager that should be used to inject the MC beans, so createCreationalContext() and createInjectionTarget() can be called. I think for this to work we need access to the 'real' BeanManager. So, how do we determine which BeanManager should be used? The registry mentioned currently stores the context names and web beans Bean implementations, but we probably need to take scoped controllers into account there. So how do we determine which controller should be used for a particular bean manager? For MC->WB injection, the MC beans need to be deployed first so that they are registered with the bean manager. For WB->MC injection, the WB beans need to be deployed first since the MC WebBeansKernelControllerContext gets initialised with the bean manager on creation. I think the MC beans needing to be deployed first is pretty definite, but it would be good if the bean manager to be used for WB->MC could be determined somehow at a later stage. I am currently ignoring the fact that there are other Bean implementations than SimpleBean, and also not handling WebBeansKernelControllerContexts for bean factories View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252251#4252251 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252251

15 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Fundamental class space issue

by thomas.diesler＠jboss.com

mvn -Dframework=equinox -Dtest=OSGI142TestCase test | java.lang.ClassNotFoundException: org.jboss.test.osgi.jbosgi142.bundleB.BeanB | at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:489) | at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:405) | at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:393) | at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:105) | at java.lang.ClassLoader.loadClass(ClassLoader.java:252) | at org.eclipse.osgi.internal.loader.BundleLoader.loadClass(BundleLoader.java:321) | at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:231) | at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1193) | at org.jboss.test.osgi.jbosgi142.OSGI142TestCase.bundleLoadClass(OSGI142TestCase.java:93) | at org.jboss.test.osgi.jbosgi142.OSGI142TestCase.testLoadClass(OSGI142TestCase.java:79) | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252248#4252248 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252248

15 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Fundamental class space issue

by thomas.diesler＠jboss.com

bundleA and bundleB do not seem to share the same class space. | java.lang.ClassNotFoundException: org.jboss.test.osgi.jbosgi142.bundleB.BeanB from OSGiBundleClassLoader@bfd66a{VFSClassLoaderPolicy@95f290{name=vfszip:/home/tdiesler/svn/jboss-osgi/trunk/testsuite/functional/target/test-libs/jbosgi142-bundleA.jar/ domain=ClassLoaderDomain@cef6f1{name=DefaultDomain parentPolicy=(before=[javax.imageio, javax.imageio.stream, javax.management, javax.management.remote, javax.naming, javax.naming.event, javax.naming.spi, javax.net, javax.net.ssl, javax.xml.datatype, javax.xml.namespace, javax.xml.parsers, javax.xml.transform, javax.xml.transform.dom, javax.xml.transform.sax, javax.xml.transform.stream, javax.xml.validation, org.jboss.logging, org.jboss.osgi.spi.capability, org.jboss.osgi.spi.logging, org.jboss.osgi.spi.management, org.jboss.osgi.spi.service, org.jboss.osgi.spi.testing, org.jboss.osgi.spi.util, org.osgi.framework, org.osgi.service.packageadmin, org.osgi.service.startlevel, org.osgi.util.tracker, org.w3c.dom, org.w3c.dom.events, org.w3c.dom.ls, org.w3c.dom.ranges, org.w3c.dom.traversal, org.w3c.dom.views, org.xml.sax, org.xml.sax.ext, org.xml.sax.helpers] <INCLUDE_JAVA> after=<NOTHING>) parent=sun.misc.Launcher$AppClassLoader@93dee9} roots=[DelegatingHandler@6815360[path= context=file:/home/tdiesler/svn/jboss-osgi/trunk/testsuite/functional/target/test-libs/jbosgi142-bundleA.jar real=vfszip:/home/tdiesler/svn/jboss-osgi/trunk/testsuite/functional/target/test-libs/jbosgi142-bundleA.jar]] delegates=[DelegateLoader@175b7f9{delegate=VFSClassLoaderPolicy@95f290{vfszip:/home/tdiesler/svn/jboss-osgi/trunk/testsuite/functional/target/test-libs/jbosgi142-bundleA.jar/}}, FilteredDelegateLoader@ffeef1{delegate=VFSClassLoaderPolicy@1f42731{vfszip:/home/tdiesler/svn/jboss-osgi/trunk/testsuite/functional/target/test-libs/jbosgi142-bundleX.jar/}}] exported=[org.jboss.test.osgi.jbosgi142.bundleA]}} | at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:448) | at java.lang.ClassLoader.loadClass(ClassLoader.java:252) | at org.jboss.osgi.plugins.facade.bundle.OSGiBundleState.loadClass(OSGiBundleState.java:217) | at org.jboss.osgi.plugins.facade.bundle.OSGiBundleWrapper.loadClass(OSGiBundleWrapper.java:171) | at org.jboss.test.osgi.jbosgi142.OSGI142TestCase.bundleLoadClass(OSGI142TestCase.java:93) | at org.jboss.test.osgi.jbosgi142.OSGI142TestCase.testLoadClass(OSGI142TestCase.java:79) | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252237#4252237 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252237

15 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Fundamental class space issue

by thomas.diesler＠jboss.com

Please consider this A imports X B imports X Can X load a class from A or B? Can A load a class from B and vice versa? I believe both is true. https://jira.jboss.org/jira/browse/JBOSGI-142 This works with Felix, but fails with the MC Framework. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252234#4252234 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252234

15 years, 4 months

1
0
0 / 0

[jBPM Development] - Re: DeploymentAdaptor: duplicated process deployment since c

by kukeltje

Marko, Explicit versioning of the jpdl.xml files should prevent multiple deployments as I mentioned in my initial reply. Could very well be that that is not in place yet (and that Bernd has some ideas in this direction) btw, *anything* not in the user guid but in the dev guide is still under development. So you could run into other issues as well as you use these View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252217#4252217 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252217

15 years, 4 months

1
0
0 / 0

[jBPM Development] - Re: DeploymentAdaptor: duplicated process deployment since c

by SNy

Heh, OK, I know it's still being worked on but wanted to bring this specific point up. I first thought about filing a jira issue, but then decided against it and posted here instead. FWIW, I worked around it in my local version by adding a flag to the addResourcesFromZipInputStream() method to tell it to NOT add any .jpdl.xml files. Then I included both calls in the deploy() sequence so it now adds all resources except the process descriptors and then adds the one process descriptor it has been invoked for. Regards, Marko View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252212#4252212 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252212

15 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Adding vargargs parameters to getXXXDeclaredXXX methods

by alesj

"flavia.rainone(a)jboss.com" wrote : | Would it be all right if I added a third method to MutableClassInfo (see below), so I can get rid of the problem? | If this fixes your problem, sure. "flavia.rainone(a)jboss.com" wrote : | My main concern is whether there could be other classes outside of JBoss Reflection project implementing MutableClassInfo interface. | I doubt they do, as this was never properly finished. (only a mad man would do this :-) And even if they do, we're changing the version to indicate that there were api changes, hence users can either change their code or stick with the old one. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252199#4252199 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252199

15 years, 4 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 August 2009