[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
[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
[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