[
https://issues.apache.org/jira/browse/DISCOVERY-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13433176#comment-13433176
]
Ruslan commented on DISCOVERY-13:
---------------------------------
It is unique URL for this class which should never be used.
I believe there is no such case to actually call
org.apache.commons.discovery.Resource.getResource() on
org.apache.commons.discovery.ResourceClass instances.
Maybe it is better to override getResource() and getResourceAsStream() in
ResourceClass to make them throw NotSupportedOperationException. Maybe it is
better to do only if real URL of class can`t be determined by using
ProtectionDomain#getCodeSource().
> Problem with Oracle JVM classLoader
> -----------------------------------
>
> Key: DISCOVERY-13
> URL: https://issues.apache.org/jira/browse/DISCOVERY-13
> Project: Commons Discovery
> Issue Type: Improvement
> Affects Versions: 0.5
> Environment: Oracle Java stored procedure (oracle versions 8i -> 11g)
> Any OS
> Reporter: Leo Blumencweig
> Assignee: Simone Tripodi
> Priority: Minor
> Fix For: 0.6
>
> Attachments: commons-discovery-0.5-discoverclasses-dummyurl.patch,
> commons-discovery-0.5-discoverclasses-dummyurl.patch
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> First of all, excuse my bad english (I'm an spanish speaker)
> Starting in version 8i, Oracle provides an embedded JVM inside th databases,
> in order to develop a stored procedure inJava language, later to be invoked
> via PL/SQL.
> Saddly, the JVM has some quirks, for example an somehow brain-damaged
> classLoader (oracle.aurora.rdbms.OracleClassLoader).
> This JVM stores the classes inside table objects (very reasonable).
> This leads to some problem: the resources haves some strange URL (example:
> jserver:/resource/schema/NAME_OF_THE_SCHEMA/ar.com.menhir.config.properties).
> It will be not problema at all except because it's brain damage insist in
> telling that the above URL works only with RESOURCES and not with CLASSES!!
> for example, the following example
> private static void getData ( ClassLoader cl , String str ){
> System.out.println(str +".class" + "->
> "+cl.getResource(str+".class"));
> System.out.println(str +".class" + "->
> "+ClassLoader.getSystemResource(str+".class"));
> }
> ...
> getData(Test.class.getClassLoader(),"ar.com.menhir.wstest.Test");
> ...
> gives this 2 results:
> with normal classLoader ( sun.misc.Launcher$AppClassLoader)
> ar/com/menhir/wstest/Test.class->
> file:/C:/Users/LeoB/workspace2/prueba/bin/ar/com/menhir/wstest/Test.class
> ar/com/menhir/wstest/Test.class->
> file:/C:/Users/LeoB/workspace2/prueba/bin/ar/com/menhir/wstest/Test.class
> with oracle classLoader (oracle.aurora.rdbms.OracleClassLoader)
> ar/com/menhir/wstest/Test.class-> null
> ar/com/menhir/wstest/Test.class-> null
> The problem arises in
> org.apache.commons.discovery.resource.classes.DiscoverClasses, where the line
> 60
> final String resourceName = className.replace('.','/') + ".class";
> points to a nonexistente resource.
> my workaround was to hack this class with the following:
> final String resourceName =
> ar.com.menhir.oracle.resources.Utils.getResourcePrefix(className).replace('.','/')
> + ".class";
> where getResourcePrefix gets the correct prefix for this class.
> You must note that this is a somehow brutal way of solving. I'm interested in
> contribute with the wright way, but I'm not very sure of where to start.
> Could you please help me?
> Thank you
> Leo Blumencweig
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
