Re: [JBoss-dev] JBoss3/Jetty4 JBossSX integration...
H... I've given this a little more thought and The Servlet API should probably be part of JBoss and not the WebContainer implementation since it comprises part of the Specification of the Application Server. This prevents e.g hotswapping between e.g. 2.2 and 2.3 WebContainers, but rather enforces the fact that JBoss x.x MUST contain an implementation of Servlets y.y. Any comments ? Jasper being an implementation, should be in the jetty.sar. Javac/Tools is problematic. We can't ship it by default, since we don't own the Source/Copyright. So it must be : Either: 1. Used from $JAVA_HOME/lib (I guess this means put on the JBOSS_CLASSPATH)). Or: 2. linked/copied into the tree at JBoss install time, probably into lib/ or lib/ext - There is a dependency here as the Jetty jboss-service.xml needs to be updated to show Jetty's requirement. (What happens if you want to use a different JAVA_HOME post-install?) Or: 3. copied into the jetty.sar before sar-deployment. This avoids the need to update jetty's jboss-service.xml (I think). (What happens if you want to use a different JAVA_HOME post re-sar-ring of Jetty?). I may have missed possible problems arising from ClassLoader organisation within these three possibilities What does everyone think ? Looking at this my preference is to get it onto the JBOSS_CLASSPATH, since then Jetty gets to see the tools.jar belonging to the current $JAVA_HOME everytime. I have not experimented to see what I need in my jboss-service.xml, but this may require I enter a dependency on tools.jar - If it does, this is again problematic, since I will get a nasty exception at deployment time if we are only running on a JRE (not a JDK) and the tools.jar is not available. It is not mandatory since people may precompile their JSPs in which case Jasper does not need the compiler Any suggestions... Thanks for your input... Jules --- Julian Gosnell [EMAIL PROTECTED] wrote: David Jencks wrote: Julian, I spent a little time this weekend making jars in sars work, with Jetty as an example. If no one objects, I might check it in later tonight. I look forward to playing with it - thanks. What I've done/ found that works is: jetty-plugin.sar contains -previous contents (classes for the plugin) -org.mortbay.jetty.jar -org.mortbay.ftp.jar -org.mortbay.jetty.nbio.jar -org.mortbay.jetty.jmx.jar -org.mortbay.jetty.sasl.jar -org.mortbay.tools.jar -cryptix-sasl-jetty.jar I find that I need in lib/ext to make jasper work: tools.jar (not provided) for on-the-fly JSP compilation javax.servlet.jar The Servlet API - implemented by Jetty org.apache.jasper.jar JASPER JSP engine - consumed by Jetty Any idea why? See above. Since Servlet-API and Jasper versions vary with Jetty versions (3/2.2/1.1 or 4/2.3/1.2) I will probably roll these two jars into the same sar as well, then I can choose to drop in a version of Jetty3 or 4 (or later 5!) depending on which version of these I require. Does anyone object ? What do you think of this much repackaging? I think it's fine. Think of it like this. If I drop a Jetty sar into one node of a farm, I may want it up an running on every node - therefore it needs to contain everything that Jetty needs to run. Assuming that Jetty does not share Servlet-API Jasper components with any other JBoss module, these should probably be included as well. Does anyone feel strongly either way as to whether the tools/javac.jar should go in the jetty.sar or in lib/ext ? Does anyone else do on-the-fly compilation ? I suppose I may want to remove the jetty.sar and drop in an equivalent web-container that would - So I shall leave it in lib/ext - that makes it easier to write a script that copies it from JAVA_HOME as well. In addition, I am considering using the local-directory feature of sars to install the jetty.properties, jetty.xml, and webdefault.xml files into db/jetty-config/. Is this a good idea? I'll give this one some thought - we need to be careful not to replicate our efforts here (going into a subdirectory of db may not be the best place, but it is where the local-directory feature currently puts things) Thanks david jencks Thanks for all the help, David, Jules On 2001.11.18 20:37:20 -0500 Julian Gosnell wrote: Scott, Due to various changes in Jetty I am having to rework the Security integration. My authenticate() is not working and I'm afraid that I have a few simple questions ; 1. Is JBossSX working in RH yet, or am I wasting my time trying to get the testsuite's WebIntegrationUnitTestCase to run ? I look up the JBossSX Security Context once for each WebApp 2. I look up the securityMgr on EVERY authenticate() - could I do this ONCE on WebApp creation ? 3. I look up the realmMapping EVERY time I need
[JBoss-dev] JBoss3/Jetty4 JBossSX integration...
Scott, Due to various changes in Jetty I am having to rework the Security integration. My authenticate() is not working and I'm afraid that I have a few simple questions ; 1. Is JBossSX working in RH yet, or am I wasting my time trying to get the testsuite's WebIntegrationUnitTestCase to run ? I look up the JBossSX Security Context once for each WebApp 2. I look up the securityMgr on EVERY authenticate() - could I do this ONCE on WebApp creation ? 3. I look up the realmMapping EVERY time I need doesUserHaveRole() - ditto ? Thanks for your time, Jules _ 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
Re: [JBoss-dev] JBoss3/Jetty4 JBossSX integration...
Scott, Due to various changes in Jetty I am having to rework the Security integration. My authenticate() is not working and I'm afraid that I have a few simple questions ; 1. Is JBossSX working in RH yet, or am I wasting my time trying to get the testsuite's WebIntegrationUnitTestCase to run ? I haven't looked at anything but the basic EJB security tests and these work. The web security integration may be broken. I'll start to look at this next week. There will have to be changes to support the 2.3 servlet security model that allows a web component to assume a security role for accessing other secured components. This will be needed to completely integrate Jetty 4 and Tomcat 4. I look up the JBossSX Security Context once for each WebApp 2. I look up the securityMgr on EVERY authenticate() - could I do this ONCE on WebApp creation ? Yes, it is a thread safe instance that cannot change during the lifetime of the web app. 3. I look up the realmMapping EVERY time I need doesUserHaveRole() - ditto ? Yes, its the same object as 2. This is not true of the authenticated Subject accessible via java:comp/env/security/subject but this object should not be needed for the basic web security model. Thanks for your time, Jules ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss3/Jetty4 JBossSX integration...
Julian, I spent a little time this weekend making jars in sars work, with Jetty as an example. If no one objects, I might check it in later tonight. What I've done/ found that works is: jetty-plugin.sar contains -previous contents (classes for the plugin) -org.mortbay.jetty.jar -org.mortbay.ftp.jar -org.mortbay.jetty.nbio.jar -org.mortbay.jetty.jmx.jar -org.mortbay.jetty.sasl.jar -org.mortbay.tools.jar -cryptix-sasl-jetty.jar I find that I need in lib/ext to make jasper work: tools.jar (not provided) javax.servlet.jar org.apache.jasper.jar Any idea why? What do you think of this much repackaging? In addition, I am considering using the local-directory feature of sars to install the jetty.properties, jetty.xml, and webdefault.xml files into db/jetty-config/. Is this a good idea? (going into a subdirectory of db may not be the best place, but it is where the local-directory feature currently puts things) Thanks david jencks On 2001.11.18 20:37:20 -0500 Julian Gosnell wrote: Scott, Due to various changes in Jetty I am having to rework the Security integration. My authenticate() is not working and I'm afraid that I have a few simple questions ; 1. Is JBossSX working in RH yet, or am I wasting my time trying to get the testsuite's WebIntegrationUnitTestCase to run ? I look up the JBossSX Security Context once for each WebApp 2. I look up the securityMgr on EVERY authenticate() - could I do this ONCE on WebApp creation ? 3. I look up the realmMapping EVERY time I need doesUserHaveRole() - ditto ? Thanks for your time, Jules _ 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
Re: [JBoss-dev] JBoss3/Jetty4 JBossSX integration...
Thanks for you're prompt answer,Scott. I'll take another look at this today, Jules Scott M Stark wrote: Scott, Due to various changes in Jetty I am having to rework the Security integration. My authenticate() is not working and I'm afraid that I have a few simple questions ; 1. Is JBossSX working in RH yet, or am I wasting my time trying to get the testsuite's WebIntegrationUnitTestCase to run ? I haven't looked at anything but the basic EJB security tests and these work. The web security integration may be broken. I'll start to look at this next week. There will have to be changes to support the 2.3 servlet security model that allows a web component to assume a security role for accessing other secured components. This will be needed to completely integrate Jetty 4 and Tomcat 4. I look up the JBossSX Security Context once for each WebApp 2. I look up the securityMgr on EVERY authenticate() - could I do this ONCE on WebApp creation ? Yes, it is a thread safe instance that cannot change during the lifetime of the web app. 3. I look up the realmMapping EVERY time I need doesUserHaveRole() - ditto ? Yes, its the same object as 2. This is not true of the authenticated Subject accessible via java:comp/env/security/subject but this object should not be needed for the basic web security model. Thanks for your time, Jules ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ 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
Re: [JBoss-dev] JBoss3/Jetty4 JBossSX integration...
David Jencks wrote: Julian, I spent a little time this weekend making jars in sars work, with Jetty as an example. If no one objects, I might check it in later tonight. I look forward to playing with it - thanks. What I've done/ found that works is: jetty-plugin.sar contains -previous contents (classes for the plugin) -org.mortbay.jetty.jar -org.mortbay.ftp.jar -org.mortbay.jetty.nbio.jar -org.mortbay.jetty.jmx.jar -org.mortbay.jetty.sasl.jar -org.mortbay.tools.jar -cryptix-sasl-jetty.jar I find that I need in lib/ext to make jasper work: tools.jar (not provided) for on-the-fly JSP compilation javax.servlet.jar The Servlet API - implemented by Jetty org.apache.jasper.jar JASPER JSP engine - consumed by Jetty Any idea why? See above. Since Servlet-API and Jasper versions vary with Jetty versions (3/2.2/1.1 or 4/2.3/1.2) I will probably roll these two jars into the same sar as well, then I can choose to drop in a version of Jetty3 or 4 (or later 5!) depending on which version of these I require. Does anyone object ? What do you think of this much repackaging? I think it's fine. Think of it like this. If I drop a Jetty sar into one node of a farm, I may want it up an running on every node - therefore it needs to contain everything that Jetty needs to run. Assuming that Jetty does not share Servlet-API Jasper components with any other JBoss module, these should probably be included as well. Does anyone feel strongly either way as to whether the tools/javac.jar should go in the jetty.sar or in lib/ext ? Does anyone else do on-the-fly compilation ? I suppose I may want to remove the jetty.sar and drop in an equivalent web-container that would - So I shall leave it in lib/ext - that makes it easier to write a script that copies it from JAVA_HOME as well. In addition, I am considering using the local-directory feature of sars to install the jetty.properties, jetty.xml, and webdefault.xml files into db/jetty-config/. Is this a good idea? I'll give this one some thought - we need to be careful not to replicate our efforts here (going into a subdirectory of db may not be the best place, but it is where the local-directory feature currently puts things) Thanks david jencks Thanks for all the help, David, Jules On 2001.11.18 20:37:20 -0500 Julian Gosnell wrote: Scott, Due to various changes in Jetty I am having to rework the Security integration. My authenticate() is not working and I'm afraid that I have a few simple questions ; 1. Is JBossSX working in RH yet, or am I wasting my time trying to get the testsuite's WebIntegrationUnitTestCase to run ? I look up the JBossSX Security Context once for each WebApp 2. I look up the securityMgr on EVERY authenticate() - could I do this ONCE on WebApp creation ? 3. I look up the realmMapping EVERY time I need doesUserHaveRole() - ditto ? Thanks for your time, Jules _ 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!? 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
