[Design of PVM (Process Virtual Machine)] - undeploying and deleting deployments
by tom.baeyens@jboss.com
the new repository service manages a set of deployments. you can create new deployments with the repository service and deploy those.
long deploymentDbid = repositoryService.createDeployment()
| .addResourceFromClasspath("org/jbpm/examples/services/process.jpdl.xml")
| .deploy();
|
business archive deployer that is part of the jboss integration will make sure that .bar files get deployed like this.
now i want to make a distinction between undeploying and deleting deployments.
undeploying will mark the deployment as undeployed. it will still exist in the db, but it will not show up in the api and new processes instances cannot be started for process definitions in undeployed deployments.
deleting the deployment will remove the deployment from the db. optionally this cascades to active executions and history information. if not cascading and still active executions, then an exception will be thrown.
does this distinction between undeployment and deletion of deployments make sense to you as well ?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222769#4222769
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222769
15 years, 8 months
[Design of Management Features on JBoss] - Re: JBAS-6689 add support for activation policy metadata on
by scott.stark@jboss.org
"charles.crouch(a)jboss.com" wrote :
| So starting off I'm not sure adding support for activation policy to the JBAS layer and the console is not practical in the current timeframe (Scott/Emanuel can you comment on the JBAS side?).
|
Its a simple matter to add an actionvation config value on the property, but tieing it into the lifecycle of the runtime component as a pending config change that is to be applied if the component is restarted is not.
Looking at the troublesome properties...
"charles.crouch(a)jboss.com" wrote :
| From the above its clear that JNDI name and ObjectName should be readonly from the console perspective.
|
I think these are warnings coming from updates post template creation of the destination. They can't be read-only as in ignored because the template uses the same properties. These should have a activation config value of SERVER_RESTART or DEPLOYMENT_RESTART (which is another level of activation we should have).
"charles.crouch(a)jboss.com" wrote :
| That leaves PageSize, FullSize and DownCacheSize properties which require the destination to be stopped in order for the change to be successfully applied. I don't think the current situation is tenable, i.e. a user tries to change the PageSize property when the queue is running and the profile service responds back with success and when the console queries the ManagedComponent its gets the new value, which does *not* reflect what is actually running in the JBAS instance.
|
| I think the least that can be done here is to have the profile service return back failure from the update if the values we supplied it didn't actually get applied (Is it possible for the profile service to query the underlying component to check that the suggested updates have been applied?).
|
We don't know if the component has failed to apply the change without an exception being thrown here. This does not seem to be the case as the change is ignored and the log message the only indication of failure.
"charles.crouch(a)jboss.com" wrote :
| Further if I'm not changing PageSize, FullSize and DownCacheSize properties, but one of the properties which can be updated fine while the destination is running, then I should clearly not get any sort of warning or failure.
|
There is too much of a disconnect between the component and its management object at this point to be able to ensure this behavior. If the properties are updated to be *_RESTART, then we can avoid dispatching the change to the runtime component at the profileservice level and avoid the warning it emits.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222768#4222768
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222768
15 years, 8 months
[Design the new POJO MicroContainer] - Re: Multiple ClassFileTransformers/Translators
by alesj
"alesj" wrote :
| "adrian(a)jboss.org" wrote :
| | If you want to add classloader specific ClassFileTransformers to the
| | BaseClassLoaderPolicy api that's ok with me.
| |
| Already done.
| But I'm still using our Translator + adding ClassFileTransformer2Translator bridge.
|
What should be the order of transformation?
1) domain
2) policy
Having more "exact" transformation after more "general".
| protected byte[] transform(String className, byte[] byteCode, ProtectionDomain protectionDomain) throws Exception
| {
| byte[] result = byteCode;
|
| BaseClassLoaderDomain domain = getClassLoaderDomain();
| if (domain != null)
| result = domain.transform(getClassLoader(), className, result, protectionDomain);
|
| ClassLoader classLoader = getClassLoaderUnchecked();
| if (classLoader != null)
| result = TranslatorUtils.applyTranslatorsOnTransform(translators, classLoader, className, result, protectionDomain);
|
| return result;
| }
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222702#4222702
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222702
15 years, 8 months