[Design of JCA on JBoss] - Re: Datasources not parsing jboss.server.data.dir
by alex.loubyansky@jboss.com
"adrian(a)jboss.org" wrote : It should not be replacing properties during the parsing.
|
| The correct place to fix this is in AbstractBuilder
| when it constructs the ServiceTextValueMetaData.
I just tried it. It works for String-based properties. But not int, for example. Since unmarshalling/JAXB converts string values to the target Java types in metadata. And then the builder is called.
One way to workaround this could be to make all the properties in the metadata Strings. It seems like whatever type of the property is the value is converted to String anyway during the service building.
Also other uses of the unmarshalled metadata will have to be checked to make sure the system properties are substituted, e.g. when creating object names. Because now I got
13:47:00,957 INFO [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=${jndi.name}' to JNDI
| name 'java:SomeDS'
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4178781#4178781
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4178781
17 years, 3 months
[Design of JBoss jBPM] - Initialise thread context classloader
by camunda
Hi.
I am working on https://jira.jboss.org/jira/browse/JBPM-1448 (jBPM does not initialize thread context classloader).
First of all, why I want to do this: This enables you to put Interfaces or other stuff used in your action classes in the par, so they end up in the database. Because the ProcessClassLoader will become ContextClassLoader it is used to load everything correctly...
But this is only half the way I want to go. Image you put jbpm in your app-server (or ESB) once, but have different applications (ear, esb, ...) using it. Now I write an own small MBean, which is a registry where processes register which class loaders are responsible for "their" action classes. My own ProcessClassLoader now also looks in this registry and by doing so, it can even load action classes or other stuff correctly from the right EAR, even if a process was maybe started by the web-console, not knowing the ear... But more on this idea later.
Back to setting the ContextClassLoader. My approach to implement it is adding this code
| ClassLoader oldCl = Thread.currentThread().getContextClassLoader();
| try {
| Thread.currentThread().setContextClassLoader(
| ClassLoaderUtil.getProcessClassLoader(processDefinition));
|
| .... existing code ...
| }
| finally {
| Thread.currentThread().setContextClassLoader(oldCl);
| }
|
to the following methods:
- Action.execute
- Decision.execute
- TaskController.initializeVariables
- TaskController.submitParameters
- AssignmentHandler.performAssignmentDelegation
On all these places I have the ProcessDefinition on hand, so it is possible to do... These are all places I found where the ProcessClassLoader is used and all Delegation use cases I remembered. So it is not too much work to do and consistent overall in jBPM (not like the proposed workaround to build an own base action class where the context class loader is set).
What do you guys think?
Cheers
Bernd
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4178720#4178720
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4178720
17 years, 3 months