[ 
http://issues.apache.org/jira/browse/HIVEMIND-166?page=comments#action_12363930 
] 

Knut Wannheden commented on HIVEMIND-166:
-----------------------------------------

I still don't understand why some jndi: URLs work fine while others don't.

You shouldn't have to write a custom ModuleDescriptorProvider implementation or 
a custom RegistryBuilder. Although, depending on what constructors and methods 
you use, you might have to duplicate some logic outside.

URLResource objects are only explicitly created by URLResource itself and by 
XmlModuleDescriptorProvider. And in the latter case only if you use one of the 
constructors XmlModuleDescriptorProvider(ClassResolver, String) or 
XmlModuleDescriptorProvider(ClassResolver).

Thus you should be able to use the constructor 
XmlModuleDescriptorProvider(ClassResolver resolver, List resources). You can 
then pass in a List of OracleResource objects, which is a little extra work. 
The RegistryBuilder also has a public constructor RegistryBuilder() and the 
public methods addModuleDescriptorProvider(ModuleDescriptorProvider) and 
addDefaultModuleDescriptorProvider().

Will the described approach work for you?

> Hivemind does not work in Oracle/OC4J
> -------------------------------------
>
>          Key: HIVEMIND-166
>          URL: http://issues.apache.org/jira/browse/HIVEMIND-166
>      Project: HiveMind
>         Type: Bug
>   Components: framework
>     Versions: 1.1
>  Environment: Oracle oc4j, from 9.x through 10.1.1
>     Reporter: Drew McAuliffe

>
> Hivemind has problems working in Oracle's OC4J container. The problem is 
> related to how Oracle handles URLs and is probably more Oracle's fault than 
> Hivemind's, but can still be pretty easily fixed. The following is from the 
> Hivemind mailing list and explains the situation fully, and also offers a 
> working code snippet.
> Last October I posted a message about a problem I had getting hivemind
> to work with OC4J 9.0.4.  and a simple code change to fix it.
> (http://mail-archives.apache.org/mod_mbox/jakarta-hivemind-user/200410.mbox/[EMAIL
>  PROTECTED])
> That issue was fixed long ago and everything I did with hivemind has
> worked great, however when I fired up Tapestry 4.0 on OC4J last week I
> discovered a similar problem that does not have as nice of a solution.
> The issue occurs when hivemind tries to create a sub module defined in
> a jar file (like Tapestry 4 does.)   To create the sub module,
> hivemind creates a resource relative to the parent module to retrieve
> the module descriptor.  In the URLResource class this is done by
> converting the internal URL object to a string, removing the parent
> file name, appending the relative resource path, and creating a new
> URL object with the new path.  This is exactly the same kind of issue
> that my original post talked about.  Except this time I can't come up
> with a "nice" solution.  URL objects don't have a method to create
> relative URLs, so converting to a string is the only real option.
> The two not nice solutions I can come up with are:
> 1)      Don't support OC4J 10.1.2 and below.  I have tried hivemind 1.1
> with the latest developer preview of OC4J and the jndi urls go away
> and everything works great as is. So sub modules will work on OC4J
> after its next major release.
> 2)      Put a hack in URLResource to explicitly check for "jndi" urls in
> URLResource.newResource.  The path can transformed to a "jar" url with
> a minimal amount of code.  The only real problem with this is that it
> muddies the code up a bit with an OC4J specific fix, but it shouldn't
> affect any other containers (unless something else also uses a "jndi"
> prefix.)
> I have actually implemented option 2(along with a couple of unit
> tests) just to see if anything else would break on OC4J 10.1.2.
> Everything appears to work once this chunk of code is added, however I
> haven't tried it on anything other than Windows with Sun's JDK.
> I'm attaching that patch to this post, but I'm really hoping someone
> can come up with a better solution.
> Index: 
> C:/workspace/jakarta-hivemind/framework/src/test/org/apache/hivemind/util/TestURLResource.java
> ===================================================================
> --- 
> C:/workspace/jakarta-hivemind/framework/src/test/org/apache/hivemind/util/TestURLResource.java
>       (revision
> 0)
> +++ 
> C:/workspace/jakarta-hivemind/framework/src/test/org/apache/hivemind/util/TestURLResource.java
>       (revision
> 0)
> @@ -0,0 +1,23 @@
> +package org.apache.hivemind.util;
> +
> +import org.apache.hivemind.Resource;
> +import org.apache.hivemind.util.URLResource;
> +
> +import hivemind.test.FrameworkTestCase;
> +
> +public class TestURLResource extends FrameworkTestCase {
> +       public void testOC4JHack()
> +    {
> +        Resource l1 = new
> URLResource("jndi:C:\\jdev1012\\jakarta-struts\\lib\\struts.jar/org/apache/struts/action/Action.class");
> +        Resource l2 = l1.getRelativeResource("test/test.class");
> +
> +        assertEquals("Error generating OC4J safe resource URL",
> "jar:file:///C:\\jdev1012\\jakarta-struts\\lib\\struts.jar!/org/apache/struts/action/test/test.class"
> ,l2.getPath());
> +    }
> +
> +       public void testNormalUrl() {
> +               Resource l1 = new URLResource("http://jakarta.apache.org/";);
> +        Resource l2 = l1.getRelativeResource("hivemind");
> +
> +        assertEquals("Incorrect relative URL generated",
> "http://jakarta.apache.org/hivemind";, l2.getPath());
> +       }
> +}
> Index: 
> C:/workspace/jakarta-hivemind/framework/src/java/org/apache/hivemind/util/URLResource.java
> ===================================================================
> --- 
> C:/workspace/jakarta-hivemind/framework/src/java/org/apache/hivemind/util/URLResource.java
>   (revision
> 209772)
> +++ 
> C:/workspace/jakarta-hivemind/framework/src/java/org/apache/hivemind/util/URLResource.java
>   (working
> copy)
> @@ -50,6 +50,19 @@
>     protected Resource newResource( String path )
>     {
> +       //begin hack to work with OC4J <= 10.1.2
> +       //change jndi:PATH_TO_ARCHIVE/PATH_IN_ARCHIVE to
> jar:file:///PATH_TO_ARCHIVE!/PATH_IN_ARCHIVE
> +       if(path.startsWith("jndi:")) {
> +               //change prefix
> +               path = "jar:file:///" + path.substring(5);
> +
> +               int endOfJar = path.indexOf(".jar") + 4;
> +
> +               //insert "!" between jar file and path to resource
> +               path = path.substring(0, endOfJar) + "!" + 
> path.substring(endOfJar) ;
> +       }
> +       //end hack
> +
>         return new URLResource( path );
>     }
> The following was a response (also on the mailing list), which might offer a 
> hint towards a better solution:
> Hi,
> I had the same problem and fixed it with almost exactly the same code
> but in a slightly different way - by writing my own, very slightly
> modified, version of BuilderFactory (can't subclass because it is final)
> and of XmlModuleDescriptorProvider, and getting them to generate an
> OracleResource (which contains the jndi --> jar code) when the prefix is
> jndi.
> The advantage of this for me is that I don't have to hack the hivemind
> sources every time I update.
> Irritating, like much Oracle stuff, unfortunately.
> Best wishes
> John

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to