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

[Design of AOP on JBoss (Aspects/JBoss)] - VFSClassLoaderScopingPolicy needs updating

by adrian＠jboss.org

I'm trying to figure out how to fix the VFSClassLoaderScopingPolicy with the new rules for WAR classloading deployments. The way it works now is that when a war gets deployed, there's a seperate deployer that decides whether WARs (subdeployments) should be scoped. They are by default. If this is the case, then the war subdeployment will have its own Module and its own Domain. You shouldn't need any hacks anymore for "isWar" or "isWebCL" or looking at the top level classloader. All you need to know is whether Module.determineDomain() is not the default domain (therefore it is scoped) and Module.determineParentDomain() to know what it is scoped against. Of course most subdeployments other than wars will use the top level classloader of the whole deployment. I was trying to figure out what needs changing, but I got lost. :-) OFF TOPIC One thing I did find is this code in JBoss5ClassPoolFactory | //It is scoped | ClassLoaderSystem sys = ClassLoaderSystem.getInstance(); | | ClassLoaderDomain domain = sys.getDomain(module.getDeterminedDomainName()); | boolean parentFirst = module.isJ2seClassLoadingCompliance(); | That isn't necessarily correct. It's configurable in bootstrap-beans.xml what the ClassLoaderSystem is. It look's like the only reason you do this is to get the domain, because you're still doing that horrible code that tries to determine scoping rules based on whether the resource visibile to the domain is the same as the resource from the classloader. Like I said before, this isn't going to work if the classloader doesn't export the class. Probably what you really want is something like the new JMX operation on the domain findClassLoaderForClass() except starting from the classloader you're handling rather than the domain? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138806#4138806 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138806

18 years

1
0
0 / 0

[Design of POJO Server] - Re: AnnotatedClassFilter is wrong + AOP

by alesj

"adrian(a)jboss.org" wrote : | Ales already has an open issue to create a generic annotation parsing deployer | http://jira.jboss.com/jira/browse/JBDEPLOY-13 OK, I'll start this work in Classloading module and provide proper hooks in the deployers. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138805#4138805 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138805

18 years

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Deployment ClassPath and AOP

by adrian＠jboss.org

While looking at something else, this occurred to me. In the updated version of the classloading spi the creation of the in memory vfs url is now in a deployer so it can be customised http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/jboss-deploye... But it adds the virtual file to the end of the classpath. I think this should really be at the beginning of the classpath otherwise it is going to see the unweaved classes before the weaved classes? Also I don't understand why the deployers are passing you the root url and then you have to add "classes" onto it. Surely it should just be a case that the "classes" url is what gets passed to you? You don't care that the classes go in a directory called classes, it could be called something else? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138803#4138803 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138803

18 years

1
0
0 / 0

[Design of POJO Server] - Re: AnnotatedClassFilter is wrong + AOP

by kabir.khan＠jboss.com

"adrian(a)jboss.org" wrote : | 2) With AOP there is also an in memory virtual file to store classes | that AOP has weaved. I think this is going to lead to the classes getting | processed twice? Once using the non-weaved version then using the | weaved version? | | Which brings up another unrelated issue in that at the moment, | I believe the in memory virtual file is after the unweaved virtual file in the classpath? | AFAICR only new classes that did not exist before are added to the memory virtual file. Existing classes are not, so they should just be processed once. I'll take a better look if you want me to View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138802#4138802 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138802

18 years

1
0
0 / 0

[Design of POJO Server] - Re: AnnotatedClassFilter is wrong + AOP

by adrian＠jboss.org

I think the best way to fix this is to provide some generic class scanning from the classloading module. Only it has all the information about what is really in the classloader e.g. it isn't necessarily everything reachable from the vfs roots, especially when there is "subdeployment" within one of those roots. Also there should be a way for other annotation parsers to plugin to the process such that it is only done once rather repeating the task of parsing annotations multiple times. e.g. ejb3, servlet, webservices, aop, pojo, (jmx in future?), etc. and creating the metadata such that some other deployer can potentially override it Ales already has an open issue to create a generic annotation parsing deployer http://jira.jboss.com/jira/browse/JBDEPLOY-13 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138801#4138801 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138801

18 years

1
0
0 / 0

[Design of JMX on JBoss (JBoss/JMX)] - XMBean NotSerializationExceptions issue

by yichong_yang_jboss

I noticed it's said that a fix (ASPATCH-317) for the JMX XMBean NotSerializationException issue in 4.0.5GA version was provided when using Java 1.5 to get some MBean attributes from JBoss App server, e.g., using twiddle utility. Does anyone know where to obtain the fix? I also tried 4.2.0 GA, 4.2.0 CR2 and 4.2.2 GA, none of them seems to resolve this problem. Did I miss anything? In the jmx-invoke-service.xml, there's an entry as follows: interceptor code="org.jboss.jmx.connector.invoker.SerializableInterceptor" policyClass="StripModelMBeanInfoPolicy" which I guess should do the trick. However, it doesn't. Anyone know why and how to resolve this issue? Thanks a lot in advance! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138799#4138799 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138799

18 years

1
0
0 / 0

[Design of POJO Server] - AnnotatedClassFilter is wrong + AOP

by adrian＠jboss.org

The AnnotatedClassFilter has a number of problems. 1) It doesn't understand about "subdeployments" or in this particular case that WEB-INF and WEB-INF/classes are in the classpath e.g. | 2008-03-25 18:17:10,505 DEBUG [org.jboss.classloader.spi.base.BaseClassLoader] (RMI TCP Connection(16)-127.0.0.1) Created BaseClassLoader@1e3b325{vfsfile:/home/ejort/j | boss-head/testsuite/output/lib/aop-scopedear1.ear/aop-scopedear1.war} with policy | ... | JarEntryContents(a)27626654[path=aop-scopedear1.war/WEB-INF/classes JarEntryContents(a)28507864[path=aop-scopedear1.war/WEB-INF | ... | It tries to load each class twice | 2008-03-25 18:17:10,594 ERROR [STDERR] (RMI TCP Connection(16)-127.0.0.1) [error] Error converting class .. Do verbose mode if you want full stack trace. | 2008-03-25 18:17:10,595 DEBUG [org.jboss.deployment.AnnotatedClassFilter] (RMI TCP Connection(16)-127.0.0.1) Incomplete class: classes.org.jboss.test.aop.scoped.ear.se | rvlet.EarExampleServlet, NCDFE: java.lang.NoClassDefFoundError: classes/org/jboss/test/aop/scoped/ear/servlet/EarExampleServlet (wrong name: org/jboss/test/aop/scoped/ | ear/servlet/EarExampleServlet) | Also, I don't think it understands how AOP is done? 2) With AOP there is also an in memory virtual file to store classes that AOP has weaved. I think this is going to lead to the classes getting processed twice? Once using the non-weaved version then using the weaved version? Which brings up another unrelated issue in that at the moment, I believe the in memory virtual file is after the unweaved virtual file in the classpath? 3) The current way of scanning classes for annotations is not scalable (or even extensible). It loads a collection of all classes found then runs each class through the processors. This should be a true visitor pattern otherwise a deployment with thousands of classes is possibly going to run out memory? 4) It doesn't take into account the classloading policy in that some parts of the classpath could be excluded by filters. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138798#4138798 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138798

18 years

1
0
0 / 0

[QA of JBoss Portal] - Wiki PortletLogin

by snon

Hi, I'm having a few problem with the portletlogin chapter in jboss portal wiki. 1) Why do we have 2 servlets ? (savelogin and autologin servlet) Can't we do both actions in one servlet ? 2) How is done the connection between the autologin and savelogin servlet done ? String autologinURL = req.getContextPath() + "/auth/"; resp.sendRedirect(resp.encodeRedirectURL(autologinURL)); There is no reference to autologin servlet... 3) In the autologin servlet : where do we put the code ? In which method ? Thanks for the answers. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138786#4138786 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138786

18 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Channel.AUTO_RECONNECT

by bstansberry＠jboss.com

Some more comments on this: The current default for for JG 2.6.3 and the proposed default for JG 2.4.3 is auto_reconnect=true and auto_getstate=false. If you have channel that uses state transfer and accepts those defaults, if the channel gets shunned and reconnects, a state transfer will not happen after the reconnect. As a result, the app's state on that node will be out of sync with the rest of the cluster. Probably not a good thing. Recommend JBM never just accept the defaults. Always specifically configure what you want via channel.setOpt(...). If you guys are doing a CP release for EAP 4.3 CP01 and can add that in, then you are set no matter what the defaults are in a particular JGroups release. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138779#4138779 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138779

18 years

1
0
0 / 0

[Design of EJB 3.0] - Re: @SecurityDomain changes from AS42 to AS5

by alessio.soldano＠jboss.com

"wolfc" wrote : "alessio.soldano(a)jboss.com" wrote : Do you mean that the 4.2 package (org.jboss.annotation.security.SecurityDomain) was theoretically not good too? | Yes, the package name should reflect the defining artifact or domain. Thus we can make sure there is no class name overlap. | "anil.saldhana(a)jboss.com" wrote : I did not create the annotation. I also did not refactor them or move them. I have just taken the task of cleaning up the ejb3 security integration for AS5. Given this, I feel for AS5, the annotation should be in the security spi project. | As long as this doesn't create a dependency loop that would be perfect. | OK, thanks, if/when the annotation is actually moved to the security spi project, could you please link this to a jira issue and post it here? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138778#4138778 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138778

18 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2008