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

[Design the new POJO MicroContainer] - Re: Using the new classloader in the bootstrap

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | but it also requires change the module abstraction to not depend upon | the deployment layer: | http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/microcontaine... | i.e. make it an interface that can implemented from POJO or Deployment layer metadata | when asking for the "ClassLoaderMetaData". | We can also promote some of this to spi, for the use case where others want to create "modules" without having to use the deployment layer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122248#4122248 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122248

18 years, 2 months

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - Re: some enhancements to jboss-test

by akostadinov

Sorry for delay. Not much time. Please see patch below. I change build.log location as now it doesn't work when target "test" is called because the same file is used with another recorder within the build simultaneously (see init target). So either I've had to change how "maybejars" target gets called in which case the recorder log level would have been changed from what it was by default to error, or introduce a log file for the test target only. I preferred the second approach as it logs at info level. So allows for more assurance that we're processing the right log. As well it will allow later to implement a check to compare tests executed with test results produced (remember tests overwriting). Should I disable the build.log generation? I don't believe it ever worked when test target is called (it does for any other targets though)? Or should I move it to output dir as well? Or should I leave it as is? Index: testsuite/build.xml | =================================================================== | --- testsuite/build.xml (revision 68976) | +++ testsuite/build.xml (working copy) | @@ -873,7 +873,7 @@ | --> | <target name="tests" description="Execute all non-benchmark tests." | depends="maybejars"> | - <record name="${basedir}/build.log" append="no" action="start" loglevel="${buildlog.level}"/> | + <record name="output/tests.log" append="no" action="start" loglevel="${buildlog.level}"/> | <property name="nojars" value="true"/> | <antcall target="jboss-minimal-tests" /> | <antcall target="jboss-all-config-tests"/> | @@ -897,7 +897,20 @@ | <antcall target="tests-aop-scoped"/> | <antcall target="tests-classloader-leak"/> | <antcall target="tests-report"/> | - <record name="${basedir}/build.log" action="stop"/> | + <record name="output/tests.log" action="stop"/> | + <condition property="servers.shutdown.failed"> | + <and> | + <not><isset property="servers.shutdown.nocheck"/></not> | + <isfileselected file="output/tests.log"> | + <or> | + <contains text="Unable to shutdown server properly"/> | + <not><contains text="[server:stop]"/></not> | + </or> | + </isfileselected> | + </and> | + </condition> | + <fail message="Some servers failed to shutdown cleanly." | + if="servers.shutdown.failed"/> | </target> | | <target name="tests-stress" description="Execute all stress tests." View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122247#4122247 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122247

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Remaing classLoader changes

by adrian＠jboss.org

Setting the context classloader in the Microcontainer http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122221#4122221 Setting the deployer context classloader http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122224#4122224 Bootstrap and module style classloader outside deployment layer http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122233#4122233 Finishing the OSGI style classloader rules - META-INF/jboss-classloader.xml http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122245#4122245 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122246#4122246 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122246

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Finishing the OSGi classloading rules

by adrian＠jboss.org

Well not actually finishing, but at least completing the infrastructure so that our OSGi facade can plugin its requirements. Currently the module classloading system is in the deployment layer which as described in a related thread needs making independent of this. Inside the deployers, the module needs to be defined using a ClassLoaderMetaData (from the hypothetical META-INF/jboss-classloader.xml - not to be confused with the class of the same name in the MC). The only current ways to create a ClassLoaderMetaData to use the old LoaderRepositoryConfig for which we have a hack that maps to the new metadata or to create it programmatically. What needs doing is creating a parsing deployer for a META-INF/jboss-classloader.xml where you can define it more explicitly. Additionally the classloader metadata needs enhancing to make sure we have all the rules we need. Most of them are defined as Requirements (e.g. imports) or Capabilities (e.g. exports). This works fine for simple cases, but for OSGi cases like "uses" there needs to be additional consistency checks that makes sure that classloaders that can "see each other" are loading the same versions of classes that they pass between each other. Of course OSGi has additional fine grained rules like dependending on attributes of a deployment rather than a name/version, but that isn't very difficult and can be done in the OSGi facade. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122245#4122245 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122245

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Using the new classloader in the bootstrap

by alesj

"adrian(a)jboss.org" wrote : | I believe Ales is working on changes in this currently to remove the | dependency on OSGi dependency of the Version implementation. | Already done. See http://jira.jboss.com/jira/browse/JBMICROCONT-226. And the tests: http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/depl... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122237#4122237 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122237

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Using the new classloader in the bootstrap

by adrian＠jboss.org

As discussed previously, the bootstrap really needs to be modularised. Currently it does multiple tasks using two different bootstrap files conf/bootstrap-beans.xml and conf/jboss-service.xml The base classloader is "hardwired" | <bean name="BootstrapClassLoader" class="org.jboss.system.NoAnnotationURLClassLoader"> | | <classloader><null/></classloader> | | <constructor factoryClass="org.jboss.system.NoAnnotationURLClassLoader" factoryMethod="createClassLoader"> | | <parameter> | | <array elementClass="java.net.URL"> | |  | | <value>${jboss.lib.url}/jboss-vfs.jar</value> | |  | | <value>${jboss.lib.url}/jboss-classloading-spi.jar</value> | | <value>${jboss.lib.url}/jboss-classloader.jar</value> | | <value>${jboss.lib.url}/osgi.core.jar</value> | |  | | <value>${jboss.lib.url}/jboss-metatype.jar</value> | | <value>${jboss.lib.url}/jboss-managed.jar</value> | | <value>${jboss.lib.url}/jboss-deployers-core-spi.jar</value> | | <value>${jboss.lib.url}/jboss-deployers-core.jar</value> | | <value>${jboss.lib.url}/jboss-deployers-client-spi.jar</value> | | <value>${jboss.lib.url}/jboss-deployers-client.jar</value> | | <value>${jboss.lib.url}/jboss-deployers-structure-spi.jar</value> | | <value>${jboss.lib.url}/jboss-deployers-spi.jar</value> | | <value>${jboss.lib.url}/jboss-deployers-impl.jar</value> | | <value>${jboss.lib.url}/jboss-deployers-vfs-spi.jar</value> | | <value>${jboss.lib.url}/jboss-deployers-vfs.jar</value> | |  | | <value>${jboss.lib.url}/jboss-system.jar</value> | etc. | | The proposal is to split the bootstrap into multiple files such that it is easier to confgure, understand and replace part of the implementation. i.e. make it more modular One example would be able to swap out the profile service implementation by just replacing one file, instead of having to copy and maintain all the other configuration that is largely orthogonal. This would use the new classloader with something like (using the use case xml to make it look like the proposed META-INF/jboss-classloader.xml - see related thread): | <deployment xmlns="urn:jboss:bean-deployer:2.0"> | | | <classloader xmlns="urn:jboss:classloader:1.0" | name="jmx-kernel" | version="5.0.0.GA" | > |  | <export-all/> | <import-all/> | |  | <export package="org.jboss.mx"/> | <export package="org.jboss.mx.server"/> | |  | <import module="log4j" version="[1.2.3,2.0.0)"/> | <import package="org.jboss.system"/> | | <classpath>${jboss.lib.url}/jboss-system-jmx.jar</classpath> | <classpath> ${jboss.lib.url}/jboss-jmx.jar</classpath> | <etc./> | </classloader> | | This requires the implementation of this task: http://jira.jboss.com/jira/browse/JBOSGI-15 but it also requires change the module abstraction to not depend upon the deployment layer: http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/microcontaine... i.e. make it an interface that can implemented from POJO or Deployment layer metadata when asking for the "ClassLoaderMetaData". I believe Ales is working on changes in this currently to remove the dependency on OSGi dependency of the Version implementation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122233#4122233 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122233

18 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Another potential enhancement to jbpm

by tom.baeyens＠jboss.com

afaik, the job executor threads first try to write their name in a job before they execute it. that update should be guarded with optimistic locking. if multiple threads try to do this at the same time, all but one should get an exception and they have to rollback. i think this requires READ_COMMITTED as hibernate optimistic locking requires isolation level READ_COMMITTED on the jdbc connections. so please be more specific to the problem in the current code and what changes you want to apply and why. the LockMode.UPGRADE_NOWAIT is not preferred as not all databases support LockMode.UPGRADE. that is why we opted for optimistic locking instead. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122229#4122229 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122229

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Moving out of the UnifiedClassloaders

by anil.saldhana＠jboss.com

"adrian(a)jboss.org" wrote : "anil.saldhana(a)jboss.com" wrote : Ales, do not want to obscure your last discussion post with Adrian. | | | | I just want to tell you that adding a jboss-structure.xml to the AS security test deployment, got the particular tests to pass. I will need to add the structure to other deployments with the same resource(properties files) detection issue. | | Fix it properly by placing the resources somewhere that IS in the classpath. | The root of an ear should NOT be in classpath. | | I really am fed up with all this "I'll add a workaround for a workaround for a bug" | that leads to stupid code and irrelevant features rather than doing a proper job. | | Fix the original bug then you don't need any of the workarounds! :-) I had spoken too soon. Adding the jboss-structure.xml did not help. I will fix the tests to put the resources in the classpath. I inherited those tests in question. :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122226#4122226 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122226

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Context ClassLoader - Deployers

by adrian＠jboss.org

This one is a bit more tricky as discussed before. Currently, we don't set the context classloader when calling out to the deployers un/deploy. The question is, what should the context classloader be? There are two possible answers: 1) The deployment's classloader. i.e. DeploymentUnit.getClassLoader() 2) The deployer's classloader. i.e. the classloader of whoever registered the deployer The osgi style classloading rules will likely make the deployer classes invisible from the application classloader, unless it explicitly imports them or uses the old importAll rules (which is still the default). Also the deployment's classloader isn't available until the CLASSLOADER stage. So I'd propose that (2) is the correct context classloader. The deployer can itself set the context classloader to the deployment classloader when required. e.g. The EJB deployer does this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122224#4122224 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122224

18 years, 2 months

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - Re: some enhancements to jboss-test

by akostadinov

Sorry for delay. Not much time. Please see patch below. I change build.log location as now it doesn't work when target "test" is called because the same file is used with another recorder within the build simultaneously (see init target). So either I've had to change how "maybejars" target gets called in which case the recorder log level would have been changed from what it was by default to error, or introduce a log file for the test target only. I preferred the second approach as it logs at info level. So allows for more assurance that we're processing the right log. As well it will allow later to implement a check to compare tests executed with test results produced (remember tests overwriting). Should I disable the build.log generation? I don't believe it ever worked when test target is called (it does for any other targets though)? Or should I move it to output dir as well? Or should I leave it as is? Index: testsuite/build.xml =================================================================== --- testsuite/build.xml (revision 68976) +++ testsuite/build.xml (working copy) @@ -873,7 +873,7 @@ --> - + @@ -897,7 +897,20 @@ - + + + + + + + + + + + + + <fail message="Some servers failed to shutdown cleanly." + if="servers.shutdown.failed"/> <target name="tests-stress" description="Execute all stress tests." View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122223#4122223 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122223

18 years, 2 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 January 2008