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

[Design of EJB 3.0] - Re: Classloading problem in proxy factories

by bstansberry＠jboss.com

Re: closing EJBTHREE-1471: I think there's still something to be understood here. For sure to get this to work you had to catch LinkageError, and that tells us there's two different classloaders in place. The concern I have is if the TCL is longer-lasting than the EJB CL, the business interface class it loads leaks. Ah, of course the classloader leak tests pass -- they test for the EJB CL leaking, not the business interface class loaded via a different CL. In this case the classloader associated with the remoting connector. OK, I think I'm clear on this now. :) EJBTHREE-1471 doesn't leak to EJB CL. It does pollute the proxy cache associated with the remoting connector's CL with a proxy associated with version A of the business interface. If you redeploy the EJB, the remoting CL's proxy cache is now corrupt. Your LinkageError catch makes the proxy creation usable, but you've still got a corrupt proxy cache. Maybe that's acceptable, but if something like the the check I suggested a few posts back can be added, it would be cleaner. May be a bit slower (or a bit faster) before a redeploy, but faster after, since it avoids trying to create a proxy that's just going to fail w/ LinkageError. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173110#4173110 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173110

17 years, 3 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: TransactionManager and AS' ServiceBindingManager

by jhalliday

Right, thanks. I'm basically looking for some way to make clear in the bindings file that the IP will be ignored. Right now I use the localhost address but have a comment warning it's irrelevant. Using null plus the comment seems even better, I think I'll go with that. Users will only get a surprise if they change null to something else AND fail to read the comment. But at least that means it's an issue only for the really top notch idiots out there :-) One other problem: I have two ports that don't need particular numbers. Right now we use a default of '0', which means pick the first free port you come across. If I put '0' in the bindings file though, it only works for the default port set. For others it gets offset e.g. 0->100, which results in different semantics. I guess the best option is to pick fixed ports to use in the bindings file. Any preferences? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173104#4173104 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173104

17 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Classloading problem in proxy factories

by bstansberry＠jboss.com

Re: transient failures, before failing, the test calls System.gc() several times mixed in with two attempts to fill the heap with garbage in order to force out SoftReferences. (This is why the tests run in the their own target against their own AS instances). I can add a 5 sec sleep in there somewhere, if you think it will be helpful. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173102#4173102 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173102

17 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Delegating all invocations to ejb3-interceptors Abstract

by wolfc

I've made something that meets the middle ground. In ejb3-interceptors there is an interface InjectionInvocation which is implemented by the InjectionInvocation in ejb3-core which as a target invokes the actual injector. The alternative was to rewrite all injectors to use another sort of reflection API (on top of AbstractContainer) to allow for setting values via AbstractContainer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173100#4173100 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173100

17 years, 3 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: TransactionManager and AS' ServiceBindingManager

by bstansberry＠jboss.com

Yes and no. There is an overloaded constructor with 4 params; the third is the host name and accepts null: | <constructor> | <parameter>TransactionManager</parameter> | <parameter>socketProcessId</parameter> | <parameter><null/></parameter> | <parameter>10001</parameter> | </constructor> | ServiceBinding actually exposes two getters related to the hostname passed to the constructor: String getHostName() -- simple getter InetAddress getBindAddress() -- derived from hostname The first is a simple getter of what's passed in; the second is derived from hostname: this.bindAddress = InetAddress.getByName(hostName); InetAddress.getByName() will return the loopback address if passed null; so in your case calling getBindAddress() will return the loopback address, not null. That could probably be changed to return null; I didn't think about it much when I rewrote SBM; just left in place the existing behavior. Of course, what getBindAddress() returns only matters if someone invokes on SBM asking for it, which I imagine JBossTS won't be doing. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173097#4173097 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173097

17 years, 3 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: WebAppClassLoader getURLs() override

by remy.maucherat＠jboss.com

* Works for me. I'll commit it to test it. * This used to be the useJBossWebLoader option, but it seems it has been removed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173096#4173096 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173096

17 years, 3 months

1
0
0 / 0

[Design of JBoss Build System] - org.codehaus.woodstox:wstx-lgpl missing from jboss repositor

by pferraro

jbossas/component-matrix/pom.xml contains the following artifact that does not exist in the jboss repository: | <dependency> | <groupId>org.codehaus.woodstox</groupId> | <artifactId>wstx-lgpl</artifactId> | <version>3.2.6</version> | </dependency> | My maven setup has the maven central repo masked by a mirror as recommended in this forum. To be able to build, I need to re-enable the central repo atm. Shouldn't hudson also be setup this way to catch missing artifacts like this one? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173084#4173084 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173084

17 years, 3 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: WebAppClassLoader getURLs() override

by adrian＠jboss.org

The issue here is WebappClassLoader.toURLs() returning a lot of data that gets added to the RMI streams as "annotations". We don't want this, so this either needs to be fixed by * returning | @Override | public URL[] getURLs() | { | return new URL[0]; // Optimize away the Memory Allocation | } | in JBoss's subclass org.jboss.web.tomcat.service.WebAppClassLoader * Making Tomcat use JBoss's classloader directly, i.e. no Tomcat WebappClassLoader at all View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173082#4173082 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173082

17 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Annotation processing without top-level annotation

by wolfc

I don't see how this could be done differently. Make it so. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173081#4173081 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173081

17 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Annotation processing without top-level annotation

by emuckenhuber

It seems that we are missing one use case of annotation processing. e.g. if you specify a stateful bean in the ejb-jar.xml and have a bean without a top-level annotation like: | public class RemoveBean | { | @Remove | public void remove() | { | } | } | As it is now the Stateful annotation processor requires a top-level @Stateful annotation to be able to create the metadata. Therefore the annotation deployer only looks for those top-level annotations - which makes sense, as this annotation is required to create the correct metaData with ejbName and ejbClass. To work around this problem we would need to skip this top-level processing and create the metaData based on the xml metaData. So in more detail what needs to be added to the JBoss50Creator is something like: | public JBoss50MetaData create(Collection<Class<?>> classes) | { | // Create meta data | JBoss50MetaData metaData = create(); | | for(EnterpriseBeanMetaData bean : ejbJarMetaData.getEnterpriseBeans()) | { | Class<?> ejbClass = classLoader.loadClass(bean.getEjbClass()); | if(! classes.contains(ejbClass)) | { | if(bean.isSession()) | { | SessionBeanMetaData sb = (SessionBeanMetaData) bean; | JBossSessionBeanMetaData sessionBean = new JBossSessionBeanMetaData(); | sessionBean.setEjbName(sb.getEjbName()); | sessionBean.setEjbClass(sb.getEjbClass()); | if(sb.isStateful()) | { | StatefulProcessor processor = new StatefulProcessor(finder); | sessionBean.setSessionType(SessionType.Stateful); | processor.process(sessionBean, ejbClass); | metaData.getEnterpriseBeans().add(sessionBean); | } | else | { | sessionBean.setSessionType(SessionType.Stateless); | // ... | } | } | else if(bean.isMessageDriven()) | { | // ... | } | } | } | | processMetaData(classes, metaData); | return metaData; | } | This (not compiled prototype) basically processes every class defined in the xml if not already picked up by the annotationDeployer. I think this should be handled differently in future, but i would consider that as last minute workaround :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173076#4173076 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173076

17 years, 3 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