September 2008 - jboss-dev-forums

[Design of POJO Server] - Re: Modularising the appserver bootstrap

by adrian＠jboss.org

I moved the aop issue to here: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=142379 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176527#4176527 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176527

17 years, 6 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Modularising the appserver bootstrap

by adrian＠jboss.org

I think there's also a dependency with the AspectManager bean expecting ServiceMBeanSupport to be available. But JMX deployment should come after AOP. The eventual idea is to make JMX optional. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176522#4176522 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176522

17 years, 6 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Modularising the appserver bootstrap

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | The fix would to refactor the VFSClassLoaderScopingPolicy | such that the deployment logic is in the deployers which just invoke the | registerClassLoader() | | i.e. remove its dependency on the deployment layer | Additionally, I think the logic in this code is a bit dated? With the new classloader, it is not just wars that can have their own isolated classloaders. Any subdeployment with its own classloading metadata can create a sub-module in its own classloader domain. And even wars don't necessarily have an isolated classloader, this is just a default rule, i.e. we add a classloading metadata to all wars that don't have an explicit one to put them in their own classloader domain. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176520#4176520 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176520

17 years, 6 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Modularising the appserver bootstrap

by adrian＠jboss.org

WRT: https://jira.jboss.org/jira/browse/JBAS-5535 I never really followed up on this, but the reason why this issue has stalled is because AOP is introducing a ciruclar dependency in the bootstrap. AspectManager -> scoping policy -> deployment unit -> main deployer -> jmx -> aop (via @JMX) This means we can't properly setup the bootstrap classloaders to be modular, see the FIXMEs in conf/classloader.xml | <classloader name="bootstrap-classloader" xmlns="urn:jboss:classloader:1.0" export-all="NON_EMPTY" import-all="true"> |  | <root>${jboss.lib.url}/jboss-deployers-core-spi.jar</root> | <root>${jboss.lib.url}/jboss-deployers-core.jar</root> | <root>${jboss.lib.url}/jboss-deployers-client-spi.jar</root> | <root>${jboss.lib.url}/jboss-deployers-client.jar</root> | <root>${jboss.lib.url}/jboss-deployers-structure-spi.jar</root> | <root>${jboss.lib.url}/jboss-deployers-spi.jar</root> | <root>${jboss.lib.url}/jboss-deployers-impl.jar</root> | <root>${jboss.lib.url}/jboss-deployers-vfs-spi.jar</root> | <root>${jboss.lib.url}/jboss-deployers-vfs.jar</root> |  | <root>${jboss.lib.url}/jboss-system.jar</root> |  | <root>${jboss.lib.url}/jboss-j2se.jar</root> | <root>${jboss.lib.url}/jboss-mbeans.jar</root> | <root>${jboss.lib.url}/jboss-jmx.jar</root> | <root>${jboss.lib.url}/jboss-system-jmx.jar</root> | <root>${jboss.lib.url}/dom4j.jar</root> |  | <root>${jboss.lib.url}/jaxb-impl.jar</root> |  | <root>${jboss.lib.url}/wstx.jar</root> | </classloader> | The fix would to refactor the VFSClassLoaderScopingPolicy such that the deployment logic is in the deployers which just invoke the registerClassLoader() i.e. remove its dependency on the deployment layer That way we can bootstrap the AspectManager before the deployers and JMX are even loaded and it becomes independent of this implementation detail. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176518#4176518 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176518

17 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-5895; Processing too many classes

by alesj

Yes, the 'fix' is obvious. :-) "adrian(a)jboss.org" wrote : | So why don't we just turn it off? | | But since it is not portable behaviour, it would be better for them to fix the packaging anyway. I can already see our testsuite going bazooka if we turned this off. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176516#4176516 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176516

17 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-5895; Processing too many classes

by adrian＠jboss.org

Ok. so the solutions seems obvious to me. I don't see the point of trying to fix a hack with another hack. The original problem comes about because the old UCL added the root of the ear to the classpath. This was a mistake, and was only done for debugging purposes, i.e. to print the ear url in the toString() of the classloader. We still do it for backwards compatiblity purposes, but now it is causing problems for the annotation scanning. So why don't we just turn it off? If somebody really wants the old behaviour they can enable it. But since it is not portable behaviour, it would be better for them to fix the packaging anyway. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176509#4176509 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176509

17 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Major refactoring of the jbpm3 core test suite

by thomas.diesler＠jboss.com

Folks, https://jira.jboss.org/jira/browse/JBPM-1733 I the search for a solution to the "schemaCreate() on setUp()" it became apparent that dropping/creating the schema on setup for every test (i.e. 300 times) during the testrun is not a valid option. It is only slightly better, if not equally bad, to clear the schema on setup. This is because the code for clearing the schema currently does this is a very "unintelligent" way by dropping/recreating foreign key constraints before deleting table content in an arbitrary order. This approach is invalid because it requires the jbpmtest user to have alter table privileges and also executes a very large number of DLL statements. Rather the opposite should be tested, which is that an "ordinary" jbpm user does not have the privileges to alter jbpm tables. JUnit works on the premises that a test sets up its own fixture and tears it down after ward. Generally, it is incorrect to delegate the cleanup of test N to setup of test N+1. Only test N can know what records have been created and should be removed afterwards. I refactored the testsuite according to the above, with the result that neither createSchema() nor clearSchema() is called during setUp or tearDown. As a result, the execution time of mysql tests drops from 25min to 8min http://jbws.dyndns.org:8280/hudson/job/jBPM-Matrix/container=jboss422,dat... and the execution time of postgresql tests drops from 5h to 20min, which allows them to run at all. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176501#4176501 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176501

17 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM maven group ids

by thomas.diesler＠jboss.com

We conclude this issue to use * org.jbpm.jbpm3 * org.jbpm.jbpm4 I've modified the groupid accordingly View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176494#4176494 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176494

17 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-5895; Processing too many classes

by alesj

"adrian(a)jboss.org" wrote : | The VFSResourceVisitor should already exclude other roots | if they are nested within another root. | It does. It's an issue when lib is not part of classpath / roots, e.g. explicitly excluded with library-directory application.xml element. Then VRVisitor still visits lib directory, picking up annotated classes, although when we declared ear's root as classpath entry, we probably only wanted to do that to pick some .properties / .xml resources, not excluded lib's jars. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176485#4176485 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176485

17 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-5895; Processing too many classes

by adrian＠jboss.org

I'm not understanding this issue. The VFSResourceVisitor should already exclude other roots if they are nested within another root. See VFSResourceVisitor.accepts() | // This is our current root | if (file.equals(root)) | return true; | | // Some other root, it will be handled later | for (VirtualFile other : roots) | { | if (file.equals(other)) | return false; | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176483#4176483 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176483

17 years, 6 months

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 September 2008