Re: JSP classpath (Was: Re: [JBoss-dev] Re: What's going ON??)
Hi David, The problem I found is in MBeanProxy, I didn't have time to look at it over the weekend. Maybe JBossMX's MBeanProxy should be used? It doesn't have this problem. But I haven't looked too closely at either implementation. I can fix it if you like. I've still got to check the entire source tree for use of invoke() instead of get/set. So far I've only corrected those pointed to by the boot sequence and the testsuite :-) Regards, Adrian On 2002.03.10 13:02:25 -0500 Adrian Brock wrote: Just to put my 2 cents in. The JSP compilation works when you run JBoss with JBossMX. This has something to do with JBossMX remembering the ContextClassLoader when an MBean is created and using it for future invokes. Unfortunately, I can't demonstrate this to you because the latest changes to the service controller means JBoss is now using invoke() to get attributes which is against the JMX spec and is not supported by JBossMX. Can you point to where this is being done (I don't see it and haven't tried runnning on jbossmx yet)? Are you fixing it? david jencks Regards, Adrian I wrote the file: stuff before the introduction of njar: - I shall try to find time to look at this tonight. The Jasper/packed problem has been around in various guises as long as Jasper. I think, ultimately, someone should take a proper look at Jasper and figure out a way of LAZILY unpacking any resource (jars and java sources) to which Jasper might make reference. As you have said, even if all the Jetty stuff ships unpacked (which it should do anyway), there will still be other packed resources which the compilation may make reference to. Not to mention the packed webapp which contains the JSPs in the first place. What we really need is a wrapper around the compiler which uses getResource() and streams for all it's resources instead of files. JSP 1.2 should have done this anyway, since it ships with Servlet 2.3 in which this is the preferred modus operandi. I figure that any other approach is a hack and ultimately probably wasted effort. Perhaps we can interest someone who is into JSPs sufficiently to fix this properly for all WebContainers. In conclusion, I see it as a Jasper, not a Jetty/JBoss issue and as such it should be fixed there, rather than making our own stuff leap through a load of hoops and still ending up with something which never works 100% anyway. Thoughts ? Jules --- David Jencks [EMAIL PROTECTED] wrote: What exactly do[es] the compiler[s] expect/accept? david jencks On 2002.03.10 09:24:08 -0500 Jan Bartel wrote: The njar:file:jetty-plugin.sar^/org.mortbay.jetty.jar is going to be a problem for the JSP classpath. Either: (1) jars inside sars need to be extracted by the JBoss deployer (2) we forget sar format for Jetty and put all mortbay jars into jboss.homelib I assume that since JBoss is working hard not to have to extract anything that option (1) won't be popular. I guess option (2) means that we separate out the jetty jboss-service.xml file to drop into the deploy directory and put all our jars (including jetty-ejb.jar?) into jboss.home/lib, which chimes better with the JBoss deployment philosophy. Jules, amongst your refactoring, are you making option (2) possible? *However* there still seems to me to be a problem with JSPs in general: ie, any JSP that has to be compiled that refers to a class (such as an ejb) that is found by an njar:file:^/blah.jar URL won't be able to be compiled?! Jan Jules, the Jetty JSP classpath stuff appears to be broken, for several reasons: * to form the path, file: is stripped off the front of all URLs returned from the AbstractWebContainer getCompileClasspath(). On windows, you could wind up with the incorrect path /c:/blah. * to do the stripping, it is acuatally file:.length() chars which get stripped from the front of each URL. That won't work when the url is njar:file:/blah/blah/blah, as is unfortunately the case with njar:file:..jetty-plugin.sar^/org.mortbay.jetty.ja I am surmising that this problem has cropped up because Jetty now gets handed a URLClassloader instead of an MBeanClassloader. In any case, is this one of the things that you are currently fixing, or do you want me to go ahead and fix it before you commit your changes, as I'm hanging out to commit the new Jetty version? Jan
RE: JSP classpath (Was: Re: [JBoss-dev] Re: What's going ON??)
Similar issue with applications like Velocity. These apps depend (somewhat misguidedly) on an unpacked deployment of web apps. This is because they need to read web pages in order to parse them for tag substitution. AFAIK, they do not delegate a class to do the reading for them. jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jan Bartel Sent: Sunday, March 10, 2002 9:24 AM To: Jules Gosnell; Jboss-Development ([EMAIL PROTECTED]) Subject: JSP classpath (Was: Re: [JBoss-dev] Re: What's going ON??) The njar:file:jetty-plugin.sar^/org.mortbay.jetty.jar is going to be a problem for the JSP classpath. Either: (1) jars inside sars need to be extracted by the JBoss deployer (2) we forget sar format for Jetty and put all mortbay jars into jboss.homelib I assume that since JBoss is working hard not to have to extract anything that option (1) won't be popular. I guess option (2) means that we separate out the jetty jboss-service.xml file to drop into the deploy directory and put all our jars (including jetty-ejb.jar?) into jboss.home/lib, which chimes better with the JBoss deployment philosophy. Jules, amongst your refactoring, are you making option (2) possible? *However* there still seems to me to be a problem with JSPs in general: ie, any JSP that has to be compiled that refers to a class (such as an ejb) that is found by an njar:file:^/blah.jar URL won't be able to be compiled?! Jan Jules, the Jetty JSP classpath stuff appears to be broken, for several reasons: * to form the path, file: is stripped off the front of all URLs returned from the AbstractWebContainer getCompileClasspath(). On windows, you could wind up with the incorrect path /c:/blah. * to do the stripping, it is acuatally file:.length() chars which get stripped from the front of each URL. That won't work when the url is njar:file:/blah/blah/blah, as is unfortunately the case with njar:file:..jetty-plugin.sar^/org.mortbay.jetty.jar I am surmising that this problem has cropped up because Jetty now gets handed a URLClassloader instead of an MBeanClassloader. In any case, is this one of the things that you are currently fixing, or do you want me to go ahead and fix it before you commit your changes, as I'm hanging out to commit the new Jetty version? Jan Hi Jules, I'm trying to update the version of Jetty, but everything seems broken with JBoss/Jetty. I can't run the web integration tests nor deploy a simple war file with a JSP in it. I see from the list that you said you are working on the integration stuff, so can you please tell me what you're working on, so I know what to concentrate on to get this update in???! ta, Jan _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: JSP classpath (Was: Re: [JBoss-dev] Re: What's going ON??)
What exactly do[es] the compiler[s] expect/accept? david jencks On 2002.03.10 09:24:08 -0500 Jan Bartel wrote: The njar:file:jetty-plugin.sar^/org.mortbay.jetty.jar is going to be a problem for the JSP classpath. Either: (1) jars inside sars need to be extracted by the JBoss deployer (2) we forget sar format for Jetty and put all mortbay jars into jboss.homelib I assume that since JBoss is working hard not to have to extract anything that option (1) won't be popular. I guess option (2) means that we separate out the jetty jboss-service.xml file to drop into the deploy directory and put all our jars (including jetty-ejb.jar?) into jboss.home/lib, which chimes better with the JBoss deployment philosophy. Jules, amongst your refactoring, are you making option (2) possible? *However* there still seems to me to be a problem with JSPs in general: ie, any JSP that has to be compiled that refers to a class (such as an ejb) that is found by an njar:file:^/blah.jar URL won't be able to be compiled?! Jan Jules, the Jetty JSP classpath stuff appears to be broken, for several reasons: * to form the path, file: is stripped off the front of all URLs returned from the AbstractWebContainer getCompileClasspath(). On windows, you could wind up with the incorrect path /c:/blah. * to do the stripping, it is acuatally file:.length() chars which get stripped from the front of each URL. That won't work when the url is njar:file:/blah/blah/blah, as is unfortunately the case with njar:file:..jetty-plugin.sar^/org.mortbay.jetty.jar I am surmising that this problem has cropped up because Jetty now gets handed a URLClassloader instead of an MBeanClassloader. In any case, is this one of the things that you are currently fixing, or do you want me to go ahead and fix it before you commit your changes, as I'm hanging out to commit the new Jetty version? Jan Hi Jules, I'm trying to update the version of Jetty, but everything seems broken with JBoss/Jetty. I can't run the web integration tests nor deploy a simple war file with a JSP in it. I see from the list that you said you are working on the integration stuff, so can you please tell me what you're working on, so I know what to concentrate on to get this update in???! ta, Jan _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: JSP classpath (Was: Re: [JBoss-dev] Re: What's going ON??)
I wrote the file: stuff before the introduction of njar: - I shall try to find time to look at this tonight. The Jasper/packed problem has been around in various guises as long as Jasper. I think, ultimately, someone should take a proper look at Jasper and figure out a way of LAZILY unpacking any resource (jars and java sources) to which Jasper might make reference. As you have said, even if all the Jetty stuff ships unpacked (which it should do anyway), there will still be other packed resources which the compilation may make reference to. Not to mention the packed webapp which contains the JSPs in the first place. What we really need is a wrapper around the compiler which uses getResource() and streams for all it's resources instead of files. JSP 1.2 should have done this anyway, since it ships with Servlet 2.3 in which this is the preferred modus operandi. I figure that any other approach is a hack and ultimately probably wasted effort. Perhaps we can interest someone who is into JSPs sufficiently to fix this properly for all WebContainers. In conclusion, I see it as a Jasper, not a Jetty/JBoss issue and as such it should be fixed there, rather than making our own stuff leap through a load of hoops and still ending up with something which never works 100% anyway. Thoughts ? Jules --- David Jencks [EMAIL PROTECTED] wrote: What exactly do[es] the compiler[s] expect/accept? david jencks On 2002.03.10 09:24:08 -0500 Jan Bartel wrote: The njar:file:jetty-plugin.sar^/org.mortbay.jetty.jar is going to be a problem for the JSP classpath. Either: (1) jars inside sars need to be extracted by the JBoss deployer (2) we forget sar format for Jetty and put all mortbay jars into jboss.homelib I assume that since JBoss is working hard not to have to extract anything that option (1) won't be popular. I guess option (2) means that we separate out the jetty jboss-service.xml file to drop into the deploy directory and put all our jars (including jetty-ejb.jar?) into jboss.home/lib, which chimes better with the JBoss deployment philosophy. Jules, amongst your refactoring, are you making option (2) possible? *However* there still seems to me to be a problem with JSPs in general: ie, any JSP that has to be compiled that refers to a class (such as an ejb) that is found by an njar:file:^/blah.jar URL won't be able to be compiled?! Jan Jules, the Jetty JSP classpath stuff appears to be broken, for several reasons: * to form the path, file: is stripped off the front of all URLs returned from the AbstractWebContainer getCompileClasspath(). On windows, you could wind up with the incorrect path /c:/blah. * to do the stripping, it is acuatally file:.length() chars which get stripped from the front of each URL. That won't work when the url is njar:file:/blah/blah/blah, as is unfortunately the case with njar:file:..jetty-plugin.sar^/org.mortbay.jetty.jar I am surmising that this problem has cropped up because Jetty now gets handed a URLClassloader instead of an MBeanClassloader. In any case, is this one of the things that you are currently fixing, or do you want me to go ahead and fix it before you commit your changes, as I'm hanging out to commit the new Jetty version? Jan Hi Jules, I'm trying to update the version of Jetty, but everything seems broken with JBoss/Jetty. I can't run the web integration tests nor deploy a simple war file with a JSP in it. I see from the list that you said you are working on the integration stuff, so can you please tell me what you're working on, so I know what to concentrate on to get this update in???! ta, Jan _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: JSP classpath (Was: Re: [JBoss-dev] Re: What's going ON??)
Just to put my 2 cents in. The JSP compilation works when you run JBoss with JBossMX. This has something to do with JBossMX remembering the ContextClassLoader when an MBean is created and using it for future invokes. Unfortunately, I can't demonstrate this to you because the latest changes to the service controller means JBoss is now using invoke() to get attributes which is against the JMX spec and is not supported by JBossMX. Regards, Adrian I wrote the file: stuff before the introduction of njar: - I shall try to find time to look at this tonight. The Jasper/packed problem has been around in various guises as long as Jasper. I think, ultimately, someone should take a proper look at Jasper and figure out a way of LAZILY unpacking any resource (jars and java sources) to which Jasper might make reference. As you have said, even if all the Jetty stuff ships unpacked (which it should do anyway), there will still be other packed resources which the compilation may make reference to. Not to mention the packed webapp which contains the JSPs in the first place. What we really need is a wrapper around the compiler which uses getResource() and streams for all it's resources instead of files. JSP 1.2 should have done this anyway, since it ships with Servlet 2.3 in which this is the preferred modus operandi. I figure that any other approach is a hack and ultimately probably wasted effort. Perhaps we can interest someone who is into JSPs sufficiently to fix this properly for all WebContainers. In conclusion, I see it as a Jasper, not a Jetty/JBoss issue and as such it should be fixed there, rather than making our own stuff leap through a load of hoops and still ending up with something which never works 100% anyway. Thoughts ? Jules --- David Jencks [EMAIL PROTECTED] wrote: What exactly do[es] the compiler[s] expect/accept? david jencks On 2002.03.10 09:24:08 -0500 Jan Bartel wrote: The njar:file:jetty-plugin.sar^/org.mortbay.jetty.jar is going to be a problem for the JSP classpath. Either: (1) jars inside sars need to be extracted by the JBoss deployer (2) we forget sar format for Jetty and put all mortbay jars into jboss.homelib I assume that since JBoss is working hard not to have to extract anything that option (1) won't be popular. I guess option (2) means that we separate out the jetty jboss-service.xml file to drop into the deploy directory and put all our jars (including jetty-ejb.jar?) into jboss.home/lib, which chimes better with the JBoss deployment philosophy. Jules, amongst your refactoring, are you making option (2) possible? *However* there still seems to me to be a problem with JSPs in general: ie, any JSP that has to be compiled that refers to a class (such as an ejb) that is found by an njar:file:^/blah.jar URL won't be able to be compiled?! Jan Jules, the Jetty JSP classpath stuff appears to be broken, for several reasons: * to form the path, file: is stripped off the front of all URLs returned from the AbstractWebContainer getCompileClasspath(). On windows, you could wind up with the incorrect path /c:/blah. * to do the stripping, it is acuatally file:.length() chars which get stripped from the front of each URL. That won't work when the url is njar:file:/blah/blah/blah, as is unfortunately the case with njar:file:..jetty-plugin.sar^/org.mortbay.jetty.ja I am surmising that this problem has cropped up because Jetty now gets handed a URLClassloader instead of an MBeanClassloader. In any case, is this one of the things that you are currently fixing, or do you want me to go ahead and fix it before you commit your changes, as I'm hanging out to commit the new Jetty version? Jan Hi Jules, I'm trying to update the version of Jetty, but everything seems broken with JBoss/Jetty. I can't run the web integration tests nor deploy a simple war file with a JSP in it. I see from the list that you said you are working on the integration stuff, so can you please tell me what you're working on, so I know what to concentrate on to get this update in???! ta, Jan __ __ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-dev lopment ___ Jboss-development mailing list [EMAIL PROTECTED]
Re: JSP classpath (Was: Re: [JBoss-dev] Re: What's going ON??)
On 2002.03.10 13:02:25 -0500 Adrian Brock wrote: Just to put my 2 cents in. The JSP compilation works when you run JBoss with JBossMX. This has something to do with JBossMX remembering the ContextClassLoader when an MBean is created and using it for future invokes. Unfortunately, I can't demonstrate this to you because the latest changes to the service controller means JBoss is now using invoke() to get attributes which is against the JMX spec and is not supported by JBossMX. Can you point to where this is being done (I don't see it and haven't tried runnning on jbossmx yet)? Are you fixing it? david jencks Regards, Adrian I wrote the file: stuff before the introduction of njar: - I shall try to find time to look at this tonight. The Jasper/packed problem has been around in various guises as long as Jasper. I think, ultimately, someone should take a proper look at Jasper and figure out a way of LAZILY unpacking any resource (jars and java sources) to which Jasper might make reference. As you have said, even if all the Jetty stuff ships unpacked (which it should do anyway), there will still be other packed resources which the compilation may make reference to. Not to mention the packed webapp which contains the JSPs in the first place. What we really need is a wrapper around the compiler which uses getResource() and streams for all it's resources instead of files. JSP 1.2 should have done this anyway, since it ships with Servlet 2.3 in which this is the preferred modus operandi. I figure that any other approach is a hack and ultimately probably wasted effort. Perhaps we can interest someone who is into JSPs sufficiently to fix this properly for all WebContainers. In conclusion, I see it as a Jasper, not a Jetty/JBoss issue and as such it should be fixed there, rather than making our own stuff leap through a load of hoops and still ending up with something which never works 100% anyway. Thoughts ? Jules --- David Jencks [EMAIL PROTECTED] wrote: What exactly do[es] the compiler[s] expect/accept? david jencks On 2002.03.10 09:24:08 -0500 Jan Bartel wrote: The njar:file:jetty-plugin.sar^/org.mortbay.jetty.jar is going to be a problem for the JSP classpath. Either: (1) jars inside sars need to be extracted by the JBoss deployer (2) we forget sar format for Jetty and put all mortbay jars into jboss.homelib I assume that since JBoss is working hard not to have to extract anything that option (1) won't be popular. I guess option (2) means that we separate out the jetty jboss-service.xml file to drop into the deploy directory and put all our jars (including jetty-ejb.jar?) into jboss.home/lib, which chimes better with the JBoss deployment philosophy. Jules, amongst your refactoring, are you making option (2) possible? *However* there still seems to me to be a problem with JSPs in general: ie, any JSP that has to be compiled that refers to a class (such as an ejb) that is found by an njar:file:^/blah.jar URL won't be able to be compiled?! Jan Jules, the Jetty JSP classpath stuff appears to be broken, for several reasons: * to form the path, file: is stripped off the front of all URLs returned from the AbstractWebContainer getCompileClasspath(). On windows, you could wind up with the incorrect path /c:/blah. * to do the stripping, it is acuatally file:.length() chars which get stripped from the front of each URL. That won't work when the url is njar:file:/blah/blah/blah, as is unfortunately the case with njar:file:..jetty-plugin.sar^/org.mortbay.jetty.ja I am surmising that this problem has cropped up because Jetty now gets handed a URLClassloader instead of an MBeanClassloader. In any case, is this one of the things that you are currently fixing, or do you want me to go ahead and fix it before you commit your changes, as I'm hanging out to commit the new Jetty version? Jan Hi Jules, I'm trying to update the version of Jetty, but everything seems broken with JBoss/Jetty. I can't run the web integration tests nor deploy a simple war file with a JSP in it. I see from the list that you said you are working on the integration stuff, so can you please tell me what you're working on, so I know what to concentrate on to get this update in???! ta, Jan __ __ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
