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

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

by adrian＠jboss.org

JIRA issue: http://jira.jboss.com/jira/browse/JBMICROCONT-230 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123271#4123271 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123271

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Default ordering of AbstractTopLevelClassLoaderDeployer

by adrian＠jboss.org

I don't understand what problem you are trying to solve? Are you talking about the bit that overrides the ClassLoaderFactory or something else? In practice, we should be able to use the new ClassLoader for web-apps. What's missing is a generic way to say that a subdeployment (e.g. a war in an ear) wants its own classloader (based on the top level classloader) so the classes in its "classpath" are not visible to other parts of the deployment. This should be a choice in the StructureMetaData that is used to build the DeploymentContext. We can then have a "SubDeploymentClassloaderDeployer" that overrides the specific unit classloader with the classloader described above. I imagine this is related to what Ales is seeing with Seam, in that the the classpath of the war is being built into both the top level and WAR classloader? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123259#4123259 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123259

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagedDeployment.removeComponent might not be working

by bytor99999

I think the removeComponent is ok, I guess I assumed that that would remove a Datasource. Anyway, the ProfileServiceUnitTestCase should be testing the remove from the ManagementView and not check the removeComponent method. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123221#4123221 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123221

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Default ordering of AbstractTopLevelClassLoaderDeployer vs A

by scott.stark＠jboss.org

I had to specify the ordering of the WarClassLoaderDeployer to come ahead of the VFSTopLevelClassLoaderSystemDeployer in order for it to have a chance to set the unit class loader. Maybe there should only be one class loader deployer driven by the metadata and class loader factory. We are not generating ClassLoaderMetaData currently as noted elsewhere. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123220#4123220 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123220

18 years, 2 months

1
0
0 / 0

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

by adrian＠jboss.org

"pgier" wrote : Add the jboss repositories to your maven settings.xml. | http://wiki.jboss.org/wiki/Wiki.jsp?page=MavenSettings | | I have removed the repositories from the poms so that if we ever decide to change the url of the repository, there won't be a problem building old releases. Yes there will, because the repository is no longer versioned in svn we've go no idea which repository to use to recreate a build! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123207#4123207 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123207

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - ManagedDeployment.removeComponent might not be working

by bytor99999

removeComponent doesn't seem to be working for me, I get no exceptions or anything, but the backing xml file hasn't changed in anyway. OK, it is possible that the ProfileServiceUnitTestCase is reporting a false positive, because it just calls removeComponent but does no assertions or try to check to make sure that the component is truly gone. No exceptions are occuring, but I am noticing that the component's xml file still exists. OK, so looking at the ManagedDeploymentImpl class the removeComponent method just removes the ManagedComponent from the Map. How does this remove get filtered down to the actual deployment file? Am I missing some other api that actually will remove the resource? Thanks Mark Spritzler View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123201#4123201 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123201

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBossMC-2.0.0.Beta10

by pgier

Ok, makes sense. I'll see if I can get maven to automate generating this layout for next time, so the shell script isn't needed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123194#4123194 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123194

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBossMC-2.0.0.Beta10

by scott.stark＠jboss.org

No because the jars are loaded at different levels during the server bootstrap process. Classes would be unnecessarily pushed to a parent class loader if only one jar existed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123192#4123192 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123192

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBossMC-2.0.0.Beta10

by pgier

I created this wiki entry with some notes from the release. http://wiki.jboss.org/wiki/Wiki.jsp?page=MavenReleaseProcess_Microcontainer The process had a couple bumps, but it should be fine for the next release. The things left to work on is fixing the pom in the docs directory (I will do that today), and automating the process for putting together the jars for the buildmagic repo. For the buildmagic artifact, would it make sense to have a single large combined jar like we have for javaee? That way component-info.xml is small and simple, and I can set it up to be automated pretty easily. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123191#4123191 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123191

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBossMC-2.0.0.Beta10

by scott.stark＠jboss.org

Its manual as just a subset of the artifacts go into the jboss repo. Here is a sh script I have used to copy the artifacts from the maven repo into the jboss repo microcontainer/lib directory for a release. | [starksm@succubus jbossmc]$ cat ../install.sh | #!/bin/sh | | VER=2.0.0.Beta10 | M2=/home/svn/repository.jboss.com/maven2/org/jboss/microcontainer | JBOSS=/home/svn/repository.jboss.com/jboss/microcontainer | JARS="jboss-aop-mc-int jboss-classloader jboss-container jboss-container-metadata jboss-container-metadata-spi jboss-dependency jboss-deployers-client jboss-deployers-client-spi jboss-deployers-core jboss-deployers-core-spi jboss-deployers-impl jboss-deployers-spi jboss-deployers-structure-spi jboss-deployers-vfs jboss-deployers-vfs-spi jboss-kernel jboss-managed jboss-metatype" | | mkdir $JBOSS/$VER | mkdir $JBOSS/$VER/lib | for j in $JARS | do | jar=`find $M2 -name $j-${VER}.jar` | if [ -n $jar ] | then | cp $jar $JBOSS/$VER/lib/$j.jar | fi | sjar=`find $M2 -name $j-${VER}-sources.jar` | if [ -n $sjar ] | then | cp $sjar $JBOSS/$VER/lib/${j}-sources.jar | fi | done | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123190#4123190 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123190

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