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

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

by adrian＠jboss.org

You can see examples of how to make this kind stuff work properly in: org.jboss.classloader.test.support.MockClassLoaderPolicy The ClassLoaderMetaData will have similar features when it is complete. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123289#4123289 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123289

18 years, 2 months

1
0
0 / 0

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

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : Another feature I need is the ability to specify the packages that should be excluded in the package visitation scan. For a war, everything under WEB-INF/classes, WEB-INF/lib/*.jar should be visible, unless they are java.* or javax.servlet.* classes. I'm working on this for the war class loader changes. | | http://jira.jboss.org/jira/browse/JBMICROCONT-228 | I don't think your excluded packages is doing what you think it is doing. ;-) Or if it is, it should be called setExcludedExportPackages() which I guess would only be useful with exportAll? What you've done is remove the packages from the exports. They will still be used on local classloading requests. A real excluded packages would need to filter out those requests that ask for resources/streams in that package. Also, wouldn't it more efficient to filter out the exlcuded packages when it does the getPackages() callback | public Set<String> getPackages() | { | if (excluedPackages != null) | packages.removeAll(excludedPackages); | return packages; | } | rather than looping through every exluded package on every visited package? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123288#4123288 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123288

18 years, 2 months

1
0
0 / 0

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

by adrian＠jboss.org

Just to make it clear with this change and http://jira.jboss.com/jira/browse/JBMICROCONT-230 What will happen now by default is that a my-deployer-beans.xml will get its own classloader (it's a deployment). The deployer in that xml will install into the MainDeployer which will remember the classloader (its the context classloader) for invoking un/deploy() of the deployer. This is more intuitive than using the bootstrap classloader or some random context classloader of an RMI/HTTP thread when invoking deployers. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123285#4123285 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123285

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Context ClassLoader - POJO

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : "scott.stark(a)jboss.org" wrote : Who is going to have to configure the aspect, the bean deployment, or would this be setup by the deployer in the absence an override config? (not sure you can detect that other than a flag saying not to install the aspect). | | | | There is no aspect. The classloader will set automatically from the configured classloader. | For beans created from the deployment layer, it will be the classloader of the deployment | unless there is a specific one in the xml. We should probably raise a feature request for such an aspect for runtime invocations? i.e. write an aspect that introduces a KernelControllerContextAware onto the POJO and steals the classloader from it during deployment. Then it sets the context classloader to that classloader during invocations on the object. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123283#4123283 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123283

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Maven build broken again - Microcontainer

by adrian＠jboss.org

I managed to hack the pom to remove the jdocbook requirement locally. This let me build the project. I need to figure out how to build it properly. I also fixed the eclipse classpaths since it looks like we don't need oswego concurrent anymore (thanks to Alex fixing JBossXB) but it broke all the .classpath files when Maven didn't download it :-) I'm also still seeing these spurious NPEs. This error actually represents a ClassNotFoundException in a testcase, but its not very informative unless you do a clean build when it shows the real the error in the compilation stage. Where's the maven equivalent of the up-to-date task that ant has to remove obsolete/stale classes? | [INFO] ------------------------------------------------------------------------ | [ERROR] FATAL ERROR | [INFO] ------------------------------------------------------------------------ | [INFO] null | [INFO] ------------------------------------------------------------------------ | [DEBUG] Trace | java.lang.NullPointerException | at org.apache.maven.plugin.surefire.SurefirePlugin.constructSurefireBooter(SurefirePlugin.java:594) | at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:391) | at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123282#4123282 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123282

18 years, 2 months

1
0
0 / 0

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

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : Jira Issue http://jira.jboss.com/jira/browse/JBMICROCONT-231 This has been done. The only issue is whether we should clone the BeanMetaData before modifying it's ClassLoaderMetaData. For now I've chosen not to do that (Ales, did you test the cloning works properly?) instead, the modified metadata is removed at undeployment to avoid memory leaks on the classloader. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123278#4123278 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123278

18 years, 2 months

1
0
0 / 0

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

by adrian＠jboss.org

Jira Issue http://jira.jboss.com/jira/browse/JBMICROCONT-231 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123276#4123276 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123276

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Context ClassLoader - POJO

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : JIRA issue: http://jira.jboss.com/jira/browse/JBMICROCONT-230 I've done this. There are two issues remaining. I wasn't really sure how the Callbacks hang together so I've done the setting of the context classloader in a very fine grained way. i.e. setting the classloader before doing any callbacks rather than on a per callback basis. The other issue is that there are somethings not tested (and may not work :-) e.g. the KernelContextAware callbacks and I'm not entirely sure what class attribute callbacks are, so I don't know how to test them :-) Ales, can you see what other callbacks onto the bean that you've added might also need this processing and add tests? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123275#4123275 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123275

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - InstallAction not unwinding properly when there is an error

by adrian＠jboss.org

I found out while doing the classloader changes that the install action was not unwinding properly if one of the <install/> operations failed. This left the bean in the **ERROR** state but it was still installed in the registry. This was easy to fix. What is not so easy to fix is determining what uninstall operations need to be run to reverse what is already done. The install/uninstall aren't necessarily symmetic. For now, I've done a belt and braces job. I run all the unintalls and ignore any errors. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123273#4123273 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123273

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Context ClassLoader - POJO

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : Who is going to have to configure the aspect, the bean deployment, or would this be setup by the deployer in the absence an override config? (not sure you can detect that other than a flag saying not to install the aspect). | There is no aspect. The classloader will set automatically from the configured classloader. For beans created from the deployment layer, it will be the classloader of the deployment unless there is a specific one in the xml. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123272#4123272 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123272

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