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