You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hivemind.apache.org by "Drew McAuliffe (JIRA)" <hi...@jakarta.apache.org> on 2006/01/24 02:34:14 UTC
[jira] Created: (HIVEMIND-166) Hivemind does not work in
Oracle/OC4J
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/%3Ce78ffed40410231214268da168@mail.gmail.com%3E)
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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-166) Hivemind does not work in
Oracle/OC4J
Posted by "Knut Wannheden (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-166?page=comments#action_12363999 ]
Knut Wannheden commented on HIVEMIND-166:
-----------------------------------------
The problem described in the message you refer to was, as you say, fixed long ago. With that fix it seems like HiveMind can actually call openStream() on those "jndi:" URLs. That's what I meant by "some URLs work".
You also write that "The issue occurs when hivemind tries to create a sub module defined in a jar file". I am now not sure what the issue is. Could you send the error message and stack trace being printed?
I unfortunately don't have any Tapestry experience, but this page seems to document how you can control the HiveMind registry creation process: http://jakarta.apache.org/tapestry/UsersGuide/hivemind.html.
I hope we'll be able to find a satisfactory solution to your problem.
> 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/%3Ce78ffed40410231214268da168@mail.gmail.com%3E)
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-166) Hivemind does not work in
Oracle/OC4J
Posted by "Drew McAuliffe (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-166?page=comments#action_12363854 ]
Drew McAuliffe commented on HIVEMIND-166:
-----------------------------------------
Here's the code in question that should change:
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) ;
}
So the problem isn't necessarily Hivemind's fault; it's that Oracle expects jndi resources to use an unusual naming convention.
I can understand that writing a custom class to do this rather than changing the default impl would be a better move, but there doesn't seem to be an easy way to do that. If I write a custom "OracleResource" class, I don't see how I can get it to be used unless I write a custom XmlModuleDescriptorProvider and a custom RegistryBuilder. Unless there's some kind of wiring I can use that I don't know about. As of now, I can't find any reference to "URLResource" in any of the hivemodule code; it's always called directly within classes.
> 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/%3Ce78ffed40410231214268da168@mail.gmail.com%3E)
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-166) Hivemind does not work in
Oracle/OC4J
Posted by "Knut Wannheden (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-166?page=comments#action_12363798 ]
Knut Wannheden commented on HIVEMIND-166:
-----------------------------------------
I don't think I quite understand the problem here. You say the problem is the way HiveMind constructs the relative URLs. Although in the test case you give I don't understand why a URL like jndi:C:\\jdev1012\\jakarta-struts\\lib\\struts.jar/org/apache/struts/action/Action.class is valid while the relative URL jndi:C:\\jdev1012\\jakarta-struts\\lib\\struts.jar/org/apache/struts/action/test/test.class is not. How is that possible? Is the realtive URL not registered?
Aside from that I really think that it were better if you could create a custom Resource implementation (OracleResource) and then use that with the XmlModuleDescriptorProvider. Putting your suggested hack into URLResource might, as you say, break other usages of the "jndi" scheme. Further I don't quite see why you would have to subclass XmlModuleDescriptorProvider and create a custom RegistryBuilder. I think writing a OracleResource class should be enough.
> 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/%3Ce78ffed40410231214268da168@mail.gmail.com%3E)
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-166) Hivemind does not work in
Oracle/OC4J
Posted by "Drew McAuliffe (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-166?page=comments#action_12363993 ]
Drew McAuliffe commented on HIVEMIND-166:
-----------------------------------------
I think you're misunderstanding the problem. It's not that some JNDI URLs work and others don't. It's that the entire microkernel fails to start up when running under Oracle OC4J. Upon web app startup, you get a failure message (note that this is with Tapestry; I don't know how Hivemind fares on its own in OC4J).
Your solution also presumes I'm attempting to call Hivemind from my code, which isn't the case. The problem is that Tapestry can't start up because of the problem. From what I know about OC4J, it's probably related to the XML parser oracle uses. Here's another post from the mailing list that might provide more insight, and might, in fact, be a more permanent solution (without ugly "if oracle, then do this" code):
http://mail-archives.apache.org/mod_mbox/jakarta-hivemind-user/200410.mbox/%3C360173eb04102713545283d60e@mail.gmail.com%3E
> 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/%3Ce78ffed40410231214268da168@mail.gmail.com%3E)
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-166) Hivemind does not work in
Oracle/OC4J
Posted by "Sean Scott (JIRA)" <hi...@jakarta.apache.org>.
[ 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/%3Ce78ffed40410231214268da168@mail.gmail.com%3E)
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-166) Hivemind does not work in
Oracle/OC4J
Posted by "Kevin Greiner (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-166?page=comments#action_12364040 ]
Kevin Greiner commented on HIVEMIND-166:
----------------------------------------
I've been having to deal with jndi resources myself recently. The problem that Drew is having is that jndi isn't required to use a forward slash (/) as a directory separator. Most jndi providers do accept forward slashes so hivemind's solution of simply tacking on "/META-INF/hivemodule.xml" to a jndi URL usually works. Apparently, in Drew's case, it yields an invalid URL.
It would be nice if the URL constructor accepted a relative path in "standard" forward-slash syntax but again there's no requirement for that to be the case. One further issue is that the URL constructor merges the relative path with the base URL using the protocol's stream handler. In Drew's case, that would be a jndi handler provided by Oracle. So, a solution that works for most people could very well fair in the next person's environment.
On the other hand, Drew's solution of simply converting jndi URLs to jar URLs is invalid. I'm currently running hivemind in a web application. The URL to my application's hivemodule.xml file is "jndi:/META-INF/hivemodule.xml" (I'm running tomcat 5.5 for those who care). If hivemind tried to convert that URL using Drew's patch, I'd be out of business.
To navigate a relative path in the jndi namespace without knowing the valid syntax, you'll need to do something like this:
import java.net.*;
import java.naming.*;
URL url = ... ; // Some jndi URL
String path = url.getPath();
Context context = (Context) url.getContent();
path = context.composeName("META-INF", path); // Get the JNDI path to the META-INF subcontext. This is usually, but not always, the same as 'path + "/META-INF"'
context = (Context) context.lookup("META-INF"); // Get the actual META-INF context
path = context.composeName("hivemodule.xml", path); // Strangely, the path separator used here may be different from the one used two lines above.
return new URL(url, path);
> 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/%3Ce78ffed40410231214268da168@mail.gmail.com%3E)
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-166) Hivemind does not work in
Oracle/OC4J
Posted by "Knut Wannheden (JIRA)" <hi...@jakarta.apache.org>.
[ 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/%3Ce78ffed40410231214268da168@mail.gmail.com%3E)
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org