[ http://issues.apache.org/jira/browse/HIVEMIND-166?page=comments#action_12372699 ]
Sean Scott commented on HIVEMIND-166: ------------------------------------- I dont have a solution to offer on this issue, however, I would like to see it fixed. We use Oracle Portal and was hoping to use T4 portlet support. I too fired up my tapestry portlet in OC4J to only be met by this issue. > 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]
