March 2010 - jboss-dev-forums - Jboss List Archives

[JBoss Microcontainer Development] New message: "Re: logging 2.2.0.CR1 and OnDemandDependencyUninstallTestCase"

by David Lloyd

JBoss development, A new message was posted in the thread "logging 2.2.0.CR1 and OnDemandDependencyUninstallTestCase": http://community.jboss.org/message/529966#529966 Author : David Lloyd Profile : http://community.jboss.org/people/david.lloyd@jboss.com Message: -------------------------------------------------------------- The reason the constructor is gone is to force logger creation to happen via Logger.getLogger(String), which allows the possibility of reusing logger instances. It should be fairly trivial to switch things over though. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529966#529966

16 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: Trivial vfs-3.0.x manifest access fails"

by Alessio Soldano

JBoss development, A new message was posted in the thread "Trivial vfs-3.0.x manifest access fails": http://community.jboss.org/message/529960#529960 Author : Alessio Soldano Profile : http://community.jboss.org/people/alessio.soldano@jboss.com Message: -------------------------------------------------------------- > mailto:david.lloyd@jboss.com ha scritto: > > I think it'd be better if we have a deployed MC bean which represents the mount of the archive, and then everything using that mount will have a dependency on that. +1 -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529960#529960

16 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: Trivial vfs-3.0.x manifest access fails"

by David Lloyd

JBoss development, A new message was posted in the thread "Trivial vfs-3.0.x manifest access fails": http://community.jboss.org/message/529956#529956 Author : David Lloyd Profile : http://community.jboss.org/people/david.lloyd@jboss.com Message: -------------------------------------------------------------- But, *don't* use automounter unless you have no other choice. It's not intended as a consumable API; it's only there until we can work out a good way to get mounting into the deployment lifecycle/dependency graph. In fact maybe I can convince John to deprecate it right off... I think it'd be better if we have a deployed MC bean which represents the mount of the archive, and then everything using that mount will have a dependency on that. In the standalone case (e.g. testing) you can just mount the archive and unmount it again in a finally block. Note that the normal mount API is well-documented. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529956#529956

16 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: ClassLoadingAdmin"

by Adrian Brock

JBoss development, A new message was posted in the thread "ClassLoadingAdmin": http://community.jboss.org/message/529929#529929 Author : Adrian Brock Profile : http://community.jboss.org/people/adrian@jboss.org Message: -------------------------------------------------------------- > emuckenhuber wrote: > > > > mailto:adrian@jboss.org wrote: > > > > NOTE: It is still an unimplemented feature in the profile service to be able to "dry run" an install. > > i.e. you can validate the metadata can be parsed and is complete and check all the dependencies > > without creating the actual runtime objects. > > Of course there might still be runtime errors thrown from the objects themselves, which this wouldn't catch. > You mean doing mainDeployer.change(deployment, PRE_REAL) ? No. I mean having a special copy of the kernel/deployers in the management client that doesn't do any of the callbacks for the real deployments. So it will go through the dependency resolution, but won't invoke constructors, set properties, etc. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529929#529929

16 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: ClassLoadingAdmin"

by Emanuel Muckenhuber

JBoss development, A new message was posted in the thread "ClassLoadingAdmin": http://community.jboss.org/message/529928#529928 Author : Emanuel Muckenhuber Profile : http://community.jboss.org/people/emuckenhuber Message: -------------------------------------------------------------- > mailto:adrian@jboss.org wrote: > > NOTE: It is still an unimplemented feature in the profile service to be able to "dry run" an install. > i.e. you can validate the metadata can be parsed and is complete and check all the dependencies > without creating the actual runtime objects. > Of course there might still be runtime errors thrown from the objects themselves, which this wouldn't catch. You mean doing mainDeployer.change(deployment, PRE_REAL) ? -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529928#529928

16 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: ClassLoadingAdmin"

by Adrian Brock

JBoss development, A new message was posted in the thread "ClassLoadingAdmin": http://community.jboss.org/message/529924#529924 Author : Adrian Brock Profile : http://community.jboss.org/people/adrian@jboss.org Message: -------------------------------------------------------------- > mailto:thomas.diesler@jboss.com wrote: > > The use case is: > > From a gui select the application located at some repository to download/install into the framework. > An application consists of potentially very many bundles. > Try run the resolver using the application metadata. > Only when the application can be resolved in the running framework, do the install. > > The worst case, which must be avoided is a partial install that fails and leaves the framework in a state where random bits are installed/resolved that cannot easily been uninstalled. Essentially, the resolve step for a set of bundles must be atomic. You can already do that. deploy/change(deploymentNames); try { checkComplete(deploymentNames); } catch (IncompleteDeploymentException e) { undeploy/change[back](deploymentNames); } One of the features I added (different to what happens in 4.2.x) is that if a subdeployment ends up in the error state then so does the rest of the application (i.e. top level deployment, subdeployments and components). NOTE: It is still an unimplemented feature in the profile service to be able to "dry run" an install. i.e. you can validate the metadata can be parsed and is complete and check all the dependencies without creating the actual runtime objects. Of course there might still be runtime errors thrown from the objects themselves, which this wouldn't catch. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529924#529924

16 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: ClassLoadingAdmin"

by Adrian Brock

JBoss development, A new message was posted in the thread "ClassLoadingAdmin": http://community.jboss.org/message/529921#529921 Author : Adrian Brock Profile : http://community.jboss.org/people/adrian@jboss.org Message: -------------------------------------------------------------- > alesj wrote: > btw, I find it a bit strange to see lifeCycles*[0]*.resolve(lifeCycles). :-) That's what gives it the chance to do width first resolution. If you look at the DeploymentLifecycle implementation, it will fallback to doing it one at a time if the lifecycles have mixed implementations since it can't handle that case width first. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529921#529921

16 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: Structure deployer cannot access manifest"

by Thomas Diesler

JBoss development, A new message was posted in the thread "Structure deployer cannot access manifest": http://community.jboss.org/message/529916#529916 Author : Thomas Diesler Profile : http://community.jboss.org/people/thomas.diesler@jboss.com Message: -------------------------------------------------------------- I found this http://community.jboss.org/thread/148707 > The fix is making the DeclaredStructure > extend AbstractVFSArchiveStructureDeployer to ensure the archive is > mounted prior to the execution of the determineStructure method. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529916#529916

16 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: ClassLoadingAdmin"

by Ales Justin

JBoss development, A new message was posted in the thread "ClassLoadingAdmin": http://community.jboss.org/message/529915#529915 Author : Ales Justin Profile : http://community.jboss.org/people/alesj Message: -------------------------------------------------------------- > From a gui select the application located at some repository to download/install into the framework. > An application consists of potentially very many bundles. > Try run the resolver using the application metadata. > Only when the application can be resolved in the running framework, do the install. > > The worst case, which must be avoided is a partial install that fails and leaves the framework in a state where random bits are installed/resolved that cannot easily been uninstalled. Essentially, the resolve step for a set of bundles must be atomic. This sounds more like a job for ProfileService. As it's the only one that knows which deployments/repositories exist that could potentially resolve this -- aka dry resolve. MC's mechanism should only know to say true or false if a particular set of ControllerContexts can be resolved. Although I don't see how we could do dry resolve atm != deploy+undeploy if not complete. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529915#529915

16 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: Structure deployer cannot access manifest"

by Ales Justin

JBoss development, A new message was posted in the thread "Structure deployer cannot access manifest": http://community.jboss.org/message/529914#529914 Author : Ales Justin Profile : http://community.jboss.org/people/alesj Message: -------------------------------------------------------------- > Is this a bug, perhaps related to the root not beeing mounted? Most likely -- see HERE. public static Manifest getManifest(VirtualFile archive) throws IOException { if (archive == null) throw new IllegalArgumentException("Null archive"); VirtualFile manifest = archive.getChild(JarFile.MANIFEST_NAME); if (manifest == null || !manifest.exists()) { // HERE -- manifest.exists() == false if (log.isTraceEnabled()) log.trace("Can't find manifest for " + archive.getPathName()); return null; } return readManifest(manifest); } You need an explicit mount -- like explained eariler: http://community.jboss.org/message/529846#529846 It will a bit tricker here, since you wanna use your VFS abstraction. Meaning your abstraction will have to know wheather it needs to mount or not. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529914#529914

16 years, 1 month

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 March 2010