[JBoss JIRA] Created: (JBPM-992) ProcessClassLoader : cannot load resource from code deployed inside a process archive
9:10 a.m.
ProcessClassLoader : cannot load resource from code deployed inside a process archive
-------------------------------------------------------------------------------------
Key: JBPM-992
URL: http://jira.jboss.com/jira/browse/JBPM-992
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM jPDL 3.2
Environment: enterprise JBPM : process archive deployed and serialized into
database
Reporter: Adrian Dimulescu
Assigned To: Tom Baeyens
Fix For: jBPM jPDL 3.2.1
A Java class deployed with a process archive may need access to a class path resource
deployed in the same process archive.
A common example is an ActionHandler implementation that calls a remote EJB and needs a
jndi.properties file containin remote appserver location. In order to load that it calls
:
this.getClass().getClassLoader().getResourceAsStream("jndi.properties")
This call generates a java.lang.NullPointerException which I think justifies the
classification of this issue as a bug.
Looking inside the ProcessClassLoader class, I see that in order to load a class, a
"classes/" prefix. Indeed, the "par" format wants that all compiled
classes be locates underneath the "classes/" directory. The JBPM_BYTEARRAY.NAME_
field in the database table confirms this : the NAME_ of the jndi.properties resource is :
"classes/jndi.properties".
Still the ProcessClassLoader.getResourceAsStream method does not use the classes prefix.
The fix look thus simple, i.e. adding that prefix.
Second problem : if the resource is not found, a delegation should be made to the parent
classloader.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:36 a.m.
New subject: [JBoss JIRA] Updated: (JBPM-992) ProcessClassLoader : cannot load resource from code deployed inside a process archive
[ http://jira.jboss.com/jira/browse/JBPM-992?page=all ]
Adrian Dimulescu updated JBPM-992:
----------------------------------
Attachment: jbpm-patch-classloading-resource.patch
attached patch that prefixes resource names with "classes/" before looking them
up in the database.
It does not fix the delegation problem.
ProcessClassLoader : cannot load resource from code deployed inside a
process archive
-------------------------------------------------------------------------------------
Key: JBPM-992
URL: http://jira.jboss.com/jira/browse/JBPM-992
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM jPDL 3.2
Environment: enterprise JBPM : process archive deployed and serialized into
database
Reporter: Adrian Dimulescu
Assigned To: Tom Baeyens
Fix For: jBPM jPDL 3.2.1
Attachments: jbpm-patch-classloading-resource.patch
A Java class deployed with a process archive may need access to a class path resource
deployed in the same process archive.
A common example is an ActionHandler implementation that calls a remote EJB and needs a
jndi.properties file containin remote appserver location. In order to load that it calls
:
this.getClass().getClassLoader().getResourceAsStream("jndi.properties")
This call generates a java.lang.NullPointerException which I think justifies the
classification of this issue as a bug.
Looking inside the ProcessClassLoader class, I see that in order to load a class, a
"classes/" prefix. Indeed, the "par" format wants that all compiled
classes be locates underneath the "classes/" directory. The JBPM_BYTEARRAY.NAME_
field in the database table confirms this : the NAME_ of the jndi.properties resource is :
"classes/jndi.properties".
Still the ProcessClassLoader.getResourceAsStream method does not use the classes prefix.
The fix look thus simple, i.e. adding that prefix.
Second problem : if the resource is not found, a delegation should be made to the parent
classloader.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:45 a.m.
New subject: [JBoss JIRA] Updated: (JBPM-992) ProcessClassLoader : cannot load resource from code deployed inside a process archive
[ http://jira.jboss.com/jira/browse/JBPM-992?page=all ]
Tom Baeyens updated JBPM-992:
-----------------------------
Fix Version/s: jBPM jPDL 3.2.2
(was: jBPM jPDL 3.2.1)
ProcessClassLoader : cannot load resource from code deployed inside a
process archive
-------------------------------------------------------------------------------------
Key: JBPM-992
URL: http://jira.jboss.com/jira/browse/JBPM-992
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM jPDL 3.2
Environment: enterprise JBPM : process archive deployed and serialized into
database
Reporter: Adrian Dimulescu
Assigned To: Tom Baeyens
Fix For: jBPM jPDL 3.2.2
Attachments: jbpm-patch-classloading-resource.patch
A Java class deployed with a process archive may need access to a class path resource
deployed in the same process archive.
A common example is an ActionHandler implementation that calls a remote EJB and needs a
jndi.properties file containin remote appserver location. In order to load that it calls
:
this.getClass().getClassLoader().getResourceAsStream("jndi.properties")
This call generates a java.lang.NullPointerException which I think justifies the
classification of this issue as a bug.
Looking inside the ProcessClassLoader class, I see that in order to load a class, a
"classes/" prefix. Indeed, the "par" format wants that all compiled
classes be locates underneath the "classes/" directory. The JBPM_BYTEARRAY.NAME_
field in the database table confirms this : the NAME_ of the jndi.properties resource is :
"classes/jndi.properties".
Still the ProcessClassLoader.getResourceAsStream method does not use the classes prefix.
The fix look thus simple, i.e. adding that prefix.
Second problem : if the resource is not found, a delegation should be made to the parent
classloader.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:44 a.m.
New subject: [JBoss JIRA] Closed: (JBPM-992) ProcessClassLoader : cannot load resource from code deployed inside a process archive
[ http://jira.jboss.com/jira/browse/JBPM-992?page=all ]
Tom Baeyens closed JBPM-992.
----------------------------
Resolution: Done
Loading process archive resources changed. Loading classes remained the same, but now if
you load a resource with the process classloader, it will look into the /classes directory
in the process archive.
From the docs:
"
Delegation classes are loaded with the process class loader of their respective process
definition. The process class loader is a class loader that has the jBPM classloader as
a parent. The process class loader adds all the classes of one particular process
definition.
You can add classes to a process definition by putting them in the /classes folder in the
process archive. Note that this is only useful when you want to version the classes that
you add to the process definition. If versioning is not necessary, it is much more
efficient
to make the classes available to the jBPM class loader.
If the resource name doesn't start with a slash, resources are also loaded from the
/classes
directory in the process archive. If you want to load resources outside of the classes
directory, start with a double slash ( // ). For example to load resource
data.xml wich is located next to the processdefinition.xml on the root of the process
archive
file, you can do clazz.getResource("//data.xml") or
classLoader.getResourceAsStream("//data.xml") or any of those getResource*
variants.
"
Please USE this feature extensively ! I included it because i thought it was going to be
a 15 minute
job. Let me tell you: testing this was not simple. It took me almost a day to test this
properly.
So use it as much as you can so that that time was not in vain :-)
ProcessClassLoader : cannot load resource from code deployed inside a
process archive
-------------------------------------------------------------------------------------
Key: JBPM-992
URL: http://jira.jboss.com/jira/browse/JBPM-992
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM jPDL 3.2
Environment: enterprise JBPM : process archive deployed and serialized into
database
Reporter: Adrian Dimulescu
Assigned To: Tom Baeyens
Fix For: jBPM jPDL 3.2.2
Attachments: jbpm-patch-classloading-resource.patch
A Java class deployed with a process archive may need access to a class path resource
deployed in the same process archive.
A common example is an ActionHandler implementation that calls a remote EJB and needs a
jndi.properties file containin remote appserver location. In order to load that it calls
:
this.getClass().getClassLoader().getResourceAsStream("jndi.properties")
This call generates a java.lang.NullPointerException which I think justifies the
classification of this issue as a bug.
Looking inside the ProcessClassLoader class, I see that in order to load a class, a
"classes/" prefix. Indeed, the "par" format wants that all compiled
classes be locates underneath the "classes/" directory. The JBPM_BYTEARRAY.NAME_
field in the database table confirms this : the NAME_ of the jndi.properties resource is :
"classes/jndi.properties".
Still the ProcessClassLoader.getResourceAsStream method does not use the classes prefix.
The fix look thus simple, i.e. adding that prefix.
Second problem : if the resource is not found, a delegation should be made to the parent
classloader.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6894
days inactive
6977
days old
3 comments
2 participants
participants (2)
-
Adrian Dimulescu (JIRA) -
Tom Baeyens (JIRA)