[JBoss-dev] Developing with JBoss
Hey Developing with JBoss used to be very good due to hot deploy features. Now that our app is growing rapidly (mostly LOADS of JSP's) we're seeing that it's not so nice, because we have to package the app as an EAR file before deployment. If JBoss could work from a directory, that would cut down the dev cycle by a lot. Looking at the J2EE deployer it seems as though it can take a directory as input. However, if that is the case, then it gets packaged into a JAR anyway! Thus, the overhead we skipped by not packaging it into an EAR file in the first place is added anyway. Is this really necessary, and would it be possible to change it? As it is, we have a redeploy cycle of about a minute, which is not nice... /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
Guys, The latest in my efforts to pass the web integration test suite. I was getting nasty errors when trying to make optimised calls from the web to the ejb container. It seems that while JBoss is aware that both client and server objects exist within the same vm, it was upset that the call was being serialised, instead of just simply made natively, and wanted to tell me about it. So I investigated Along the path that an invocation must make from web to ejb container a test (Class.isAssignableFrom()) is made to establish whether the call can be made between two ClassLoaders without serialisation. This test was failing. I looked closer. Jetty has 2 modes in which it can run the ClassLoader used for WebApps. 1. Java 2 compliant - all requests for classes are delegated first to it's parent. Using this strategy you may get bitten if your webapp uses e.g. different versions of the same infrastructure than it's container - since the container's copies will be used in preference. Problems also occur with abstract APIs (e.g. JAXP), loaded by the container, looking for implementations which the webapp contains, but the container does not ship with. 2. Non-compliant - only requests for system classes are passed upwards. This strategy resolves the problems listed against (1) but causes the isAssignableFrom() test mentioned above to fail. What appears to happen is that JBoss passes ClassLoader A to the EJB container which loads class X then on to Jetty which creates it's WebApp ClassLoader, B, as a child of A, then asks B to load class X. B does not delegate to A, but loads class A for a second time. So I am caught in a bit of a quandarry - I want to have my cake and eat it ! I could go off into a corner and try to write an even cleverer ClassLoader for Jetty WebApps, which tried to second-guess what was going on in JBoss or I can ask you two guys to put your heads together and find a way to coordinate the ClassLoader boundaries of the two containers to my satisfaction! Scott, If you could explain a little about the architecture of ClassLoaders in JBoss3, Greg and I may be in a better position to figure out how to get this going. Greg, I guess we are looking at pluggable ContextLoader strategies - stand-alone, jboss etc... WebSphere seems to have a highly configurable ClassLoader system, and I think it is unlikely that there is a one-size-fits-all solution here. Sorry to complicate your mornings guys, Jules __ 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: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
Julian Gosnell wrote: 2. Non-compliant - only requests for system classes are passed upwards. FWIW, Tomcat4 does the same thing, which means that you have to bundle in jaxp.jar in your webapp, or you're going to get strange class-cast exceptions and class-not-found exceptions. The solution is to bundle all libraries with your app. This strategy resolves the problems listed against (1) but causes the isAssignableFrom() test mentioned above to fail. What appears to happen is that JBoss passes ClassLoader A to the EJB container which loads class X then on to Jetty which creates it's WebApp ClassLoader, B, as a child of A, then asks B to load class X. B does not delegate to A, but loads class A for a second time. So you need to put all classes in the EAR scope instead of in the webapp scope to make things work. Right? /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] remove me
Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
Your just putting the onus on the Application programmer to work around shortcomings in the Server - I think. Perhaps someone will make a pronouncement on HOW JBoss/Jetty SHOULD behave here. Then we can figure out how to achieve this behaviour. --- Rickard Öberg [EMAIL PROTECTED] wrote: Julian Gosnell wrote: 2. Non-compliant - only requests for system classes are passed upwards. FWIW, Tomcat4 does the same thing, which means that you have to bundle in jaxp.jar in your webapp, or you're going to get strange class-cast exceptions and class-not-found exceptions. The solution is to bundle all libraries with your app. If you do that with Jetty in stand-alone, compliant mode - you will simply find you are using the JAXP that Jetty loaded to parse it's own XML configuration files. If you do it with Jetty in embedded, non-compliant mode - you will find isAssignableFrom() fails. So Jetty, at the very leat, needs to know whether it is embedded or not, and it may be more complex than that - I thought I would bring in the big guns at this point ! Jules Jetty This strategy resolves the problems listed against (1) but causes the isAssignableFrom() test mentioned above to fail. What appears to happen is that JBoss passes ClassLoader A to the EJB container which loads class X then on to Jetty which creates it's WebApp ClassLoader, B, as a child of A, then asks B to load class X. B does not delegate to A, but loads class A for a second time. So you need to put all classes in the EAR scope instead of in the webapp scope to make things work. Right? /Rickard -- Rickard Öberg __ 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: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
So, Are you saying that we should simply support both - but not a third strategy which somehow supports sandboxing AND optimised intra-container calls ? 1. Serialised. intra-vm calls should cause a suitable WARNING - not an ERROR. 2. I believe that we need a third strategy. This is not the 'ex-cathedra' pronouncement that I was hoping someone else would make, I haven't given it enough thought - but it might be a start. I think, after a good 5 mins deep consideration, that the App server should provide the following classes to a SANDBOXED application. 1. J2SE x.x 2. J2EE y.y 3. Common local infrastructure Since the app is sandboxed, it should be able to override these with it's own version. I guess if you want your own version of JAXP then you should probably have to include your own implementation as well. Should the app-server not try, even in this situation, to optimise intra-container calls ? Jules --- Rickard Öberg [EMAIL PROTECTED] wrote: Julian Gosnell wrote: Your just putting the onus on the Application programmer to work around shortcomings in the Server - I think. Yes, the app programmer needs to know about classloading. Bug.. feature.. bug... feature.. which'll it be? :-) On the one hand, having straight-forward classloading makes it easy to develop a web-app. On the other hand, having sandboxed classloading makes the web-app more self-contained and portable, since they don't rely on the surrounding server to provide any of its classes. If you do that with Jetty in stand-alone, compliant mode - you will simply find you are using the JAXP that Jetty loaded to parse it's own XML configuration files. Yes, the straight-forward mode. If you do it with Jetty in embedded, non-compliant mode - you will find isAssignableFrom() fails. Yup, the more complex and portable case. /Rickard -- Rickard Öberg __ 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: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
Julian Gosnell wrote: Your just putting the onus on the Application programmer to work around shortcomings in the Server - I think. But that is exactly the problem with the non-compliant class loader as specified by the 2.3 servlet spec. Because it advocates a application developer knows better approach, then the application developer get's total control over non-system classes - so they have to set it up right, else it does not work. If they want to share class instances between the servlet container and the EJB container, then they MUST prevent the servlet context from seeing those classes, else it will load it's own copy of them. There is absolutely no programatic way to distinguish between a webapp that has included a class on purpose to override an old version in the container, or due to an unknowing programmer being overzealous with their classpath. Perhaps someone will make a pronouncement on HOW JBoss/Jetty SHOULD behave here. Then we can figure out how to achieve this behaviour. Unfortunatley the default behaviour should be what the specification says and the 2.3 servlet spec definitely requires the non java2 compliant class loader. Somebody should check the full J2EE specification to see exactly what it specifies, as there is no guarantee that the specs are compatible in this regards. I'm in two minds about providing the compliant loader options - while I think it is the simple and correct way to go, it may just complicate things to propogate a non standard mode. Maybe EJB developers are just going to have to be a lot more careful with their classpaths now??? And this includes the developers of the JBoss web integration test suite. Their should not be classes in the webapp context that are also available via the EJB container or system class loader. Regards -- Greg Wilkins[EMAIL PROTECTED] GB Phone: +44-(0)7092063462 Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 http://www.mortbay.com AU Phone: +61-(0)2 98107029 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
--- Julian Gosnell [EMAIL PROTECTED] wrote: So, Are you saying that we should simply support both - but not a third strategy which somehow supports sandboxing AND optimised intra-container calls ? 1. Serialised. intra-vm calls should cause a suitable WARNING - not an ERROR. 2. I believe that we need a third strategy. This is not the 'ex-cathedra' pronouncement that I was hoping someone else would make, I haven't given it enough thought - but it might be a start. I think, after a good 5 mins deep consideration, that the App server should provide the following classes to a SANDBOXED application. 1. J2SE x.x 2. J2EE y.y 3. Common local infrastructure Since the app is sandboxed, it should be able to override these with it's own version. I guess if you want your own version of JAXP then you should probably have to include your own implementation as well. Oops - this should read: I guess if you want your own implementation of JAXP, then you should probably have to reinclude the JAXP api itself Should the app-server not try, even in this situation, to optimise intra-container calls ? Jules --- Rickard Öberg [EMAIL PROTECTED] wrote: Julian Gosnell wrote: Your just putting the onus on the Application programmer to work around shortcomings in the Server - I think. Yes, the app programmer needs to know about classloading. Bug.. feature.. bug... feature.. which'll it be? :-) On the one hand, having straight-forward classloading makes it easy to develop a web-app. On the other hand, having sandboxed classloading makes the web-app more self-contained and portable, since they don't rely on the surrounding server to provide any of its classes. If you do that with Jetty in stand-alone, compliant mode - you will simply find you are using the JAXP that Jetty loaded to parse it's own XML configuration files. Yes, the straight-forward mode. If you do it with Jetty in embedded, non-compliant mode - you will find isAssignableFrom() fails. Yup, the more complex and portable case. /Rickard -- Rickard Öberg __ 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 Yahoo! Groups Sponsor -~-- Universal Inkjet Refill Kit $29.95 Refill any ink cartridge for less! Includes black and color ink. http://us.click.yahoo.com/1_Y1qC/MkNDAA/ySSFAA/CefplB/TM -~- For the latest information about Jetty, please see http://jetty.mortbay. Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ __ 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: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
Julian Gosnell wrote: So, Are you saying that we should simply support both - but not a third strategy which somehow supports sandboxing AND optimised intra-container calls ? Well, I believe the real fix is to make the EJB-loader use the non Java2 class-loading style as well, i.e. force people to bundle in JAR's that the app is going to use. That is the ultimate way to get things portable, and to be able to allow different running apps use different versions of, say, JAXP. I think, after a good 5 mins deep consideration, that the App server should provide the following classes to a SANDBOXED application. 1. J2SE x.x 2. J2EE y.y 3. Common local infrastructure What goes into 3? 1 and 2, yes. That must be available from the classloader. Since the app is sandboxed, it should be able to override these with it's own version. I guess if you want your own version of JAXP then you should probably have to include your own implementation as well. Absolutely. And that is indeed the case, or you'll get funky classcast exceptions (we had those a couple of days ago and had muchos fun trying to figure out what happened). Should the app-server not try, even in this situation, to optimise intra-container calls ? Well, what is the need to optimize them anymore, really? I mean, use local interfaces and that's it. The proxies don't have to do the check, since it will be implied from what type of proxies that are used. Hey, it's portable too. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
--- Rickard Öberg [EMAIL PROTECTED] wrote: Julian Gosnell wrote: So, Are you saying that we should simply support both - but not a third strategy which somehow supports sandboxing AND optimised intra-container calls ? Well, I believe the real fix is to make the EJB-loader use the non Java2 class-loading style as well, i.e. force people to bundle in JAR's that the app is going to use. That is the ultimate way to get things portable, and to be able to allow different running apps use different versions of, say, JAXP. I think, after a good 5 mins deep consideration, that the App server should provide the following classes to a SANDBOXED application. 1. J2SE x.x 2. J2EE y.y 3. Common local infrastructure What goes into 3? Your site's e.g. Logging classes etc.. which every app uses. You figure it's cheaper to load them once into the apps parent CL, than many times, into every app. 1 and 2, yes. That must be available from the classloader. Since the app is sandboxed, it should be able to override these with it's own version. I guess if you want your own version of JAXP then you should probably have to include your own implementation as well. Absolutely. And that is indeed the case, or you'll get funky classcast exceptions (we had those a couple of days ago and had muchos fun trying to figure out what happened). Should the app-server not try, even in this situation, to optimise intra-container calls ? I'm with you up to here. Well, what is the need to optimize them anymore, really? I mean, use local interfaces and that's it. The proxies don't have to do the check, since it will be implied from what type of proxies that are used. Hey, it's portable too. If they are not optimised, RH currently throws an exception and the test fails. So this needs fixing. I have heard of, but know nothing about, local interfaces. I would have thought though, that they must still be constrained by the basic laws of Class assignability - i.e. if the way the ClassLoaders is arranged means that instances of a Class cannot be passed directly from one ClassLoader to the other, without serialisation, then your call is going to be slower than if they were. Wether you are using local interfaces or not. Am I wrong ? Anyway, JBoss attempts to implement optimised intra-container calls through the standard interface. Are you suggesting we should throw all this code away now? It would save me a lot of effort. Otherwise this brings us straight back to the same problem. ClassLoader architecture which is what I need to coordinate between JBoss and Jetty in order to pass the testsuite. Jules /Rickard -- Rickard Öberg __ 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: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
Julian Gosnell wrote: What goes into 3? Your site's e.g. Logging classes etc.. which every app uses. You figure it's cheaper to load them once into the apps parent CL, than many times, into every app. Ok, good point. I believe Tomcat handles this by using a common directory that contains libraries that should be available to webapps and server alike. If they are not optimised, RH currently throws an exception and the test fails. So this needs fixing. Ah. Point taken. I have heard of, but know nothing about, local interfaces. I would have thought though, that they must still be constrained by the basic laws of Class assignability - i.e. if the way the ClassLoaders is arranged means that instances of a Class cannot be passed directly from one ClassLoader to the other, without serialisation, then your call is going to be slower than if they were. Wether you are using local interfaces or not. Am I wrong ? Well, if you want to use local interfaces, then yes, you have to be careful with how you package classes. They need to be in the EAR. Anyway, JBoss attempts to implement optimised intra-container calls through the standard interface. Are you suggesting we should throw all this code away now? It would save me a lot of effort. I'm torn. The optimization was introduced because there was no standard way to do it, but now that it does... well.. what's the point? Backward compatibility with people who have written apps that takes advantage of it, yes, but that should be it. All new apps should use local interfaces if you want local behaviour. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
That is correct. The packaging required to run under a 2.2 servlet container is inconsistent with that required to run under a 2.3 container due to the change in the web container class loader behavior. I see this with Tomcat 3.2.3 vs Tomcat 4.0. Really, the only time this shows up is for JSP pages trying to access EJBs. Due to a problem/feature of the 2.2 version of jasper this required duplicate classes to be placed into the war. This is no longer required in the 2.3 spec version, and in fact now causes a problem. The whole optimized call thing is going to change along with the class loader architecture. It is also unnecessary due to the introduction of local interfaces. - Original Message - From: Greg Wilkins [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Rickard Öberg [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 21, 2001 2:58 AM Subject: Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders Julian Gosnell wrote: Your just putting the onus on the Application programmer to work around shortcomings in the Server - I think. But that is exactly the problem with the non-compliant class loader as specified by the 2.3 servlet spec. Because it advocates a application developer knows better approach, then the application developer get's total control over non-system classes - so they have to set it up right, else it does not work. If they want to share class instances between the servlet container and the EJB container, then they MUST prevent the servlet context from seeing those classes, else it will load it's own copy of them. There is absolutely no programatic way to distinguish between a webapp that has included a class on purpose to override an old version in the container, or due to an unknowing programmer being overzealous with their classpath. Perhaps someone will make a pronouncement on HOW JBoss/Jetty SHOULD behave here. Then we can figure out how to achieve this behaviour. Unfortunatley the default behaviour should be what the specification says and the 2.3 servlet spec definitely requires the non java2 compliant class loader. Somebody should check the full J2EE specification to see exactly what it specifies, as there is no guarantee that the specs are compatible in this regards. I'm in two minds about providing the compliant loader options - while I think it is the simple and correct way to go, it may just complicate things to propogate a non standard mode. Maybe EJB developers are just going to have to be a lot more careful with their classpaths now??? And this includes the developers of the JBoss web integration test suite. Their should not be classes in the webapp context that are also available via the EJB container or system class loader. Regards ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
Rickard Öberg wrote: Julian Gosnell wrote: Are you saying that we should simply support both - but not a third strategy which somehow supports sandboxing AND optimised intra-container calls ? Well, I believe the real fix is to make the EJB-loader use the non Java2 class-loading style as well, i.e. force people to bundle in JAR's that the app is going to use. That is the ultimate way to get things portable, and to be able to allow different running apps use different versions of, say, JAXP. I have to say that I reluctantly agree. Now that the non-compliant loader cat is out of the bag, we have no choice but to force users to be disciplined about their bundling of jars. For consistency this should apply the the EJB container as well as teh servlet container (again assuming the J2EE spec does agree with the 2.3 servlet spec). However, I would like to suggest a change in the language. We should try to force the users to NOT include jars that they can reasonably expect the container will provide. JAXP is a key example, as I think it was the driver for the change in the specification. Users wanted richer XML parsing for their web applications than was provided by their containers. Hence they now have the ability to write an application that is dependant on a specific JAXP version and/or provider by bundling the jars for them. But now almost all container provide recent versions of JAXP with good parser implementations, so applications that include jaxp.jar and xerces.jar are probably fixing a problem that no longer exists! So our language should encourage users to NOT include their own versions of jars unless absolutely necessary for a particular deployment. Somewhere is should be clearly stated that the BYO implementation approach is bad because: + Firstly and foremost, it is just bad OO design. You should be dependant on the interfaces not the implementations. Sure it allows you to get around short term deployment issues, but it is a much better approach to try to get your container to provide the APIs and implementations that you need. + Including your own jars does create confusion and problems in calling local interfaces that actually cross classloader boundaries. The new priority inversion of classloader increases the chances of cross loader calls being made. + There is a significant cost in terms of memory and serialization. + Applications that provide their own implementations of common libraries cannot receive the benefits of updating the container. If new versions are deployed by a container that fix bugs or improve performance, these are not used by applications that have included their own jars. + The logical extension of shipping your own jaxp.jar in order to be portable is to ship your own swing, your own jboss and eventually your own JVM, OS and hardware :-) Thus I think the documentation should not be written so that developers think I better include jaxp.jar xerces.jar as it is better to be safe than sorry. Rather they should be encouraged to not include these jars, in the knowledge that IF a problem does occur with a particular container AND they can't update that container, only then should they can fix that deployment by including specific versions of the jars they need. Finally users should be given the confidence that their containers of choice are open and being actively maintained, thus new APIs and implementations should rapidly become available in the containers. regards -- Greg Wilkins[EMAIL PROTECTED] GB Phone: +44-(0)7092063462 Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 http://www.mortbay.com AU Phone: +61-(0)2 98107029 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
Scott M Stark wrote: That is correct. The packaging required to run under a 2.2 servlet container is inconsistent with that required to run under a 2.3 container due to the change in the web container class loader behavior. I see this with Tomcat 3.2.3 vs Tomcat 4.0. Really, the only time this shows up is for JSP pages trying to access EJBs. Well, *all* access from the web container to EJB's (i.e. servlets too) need to be aware of these changes. We ran into this the other day, and the fix was to bundle crimson.jar into our app too (i.e. not rely on it being available). Now, because of all this bundling going on, the EAR quickly grows HUGE, which means that for development you want hot-deploy on exploded EAR files. Unfortunately JBoss does not currently support that, so the cycling time becomes somewhat excessive. :-( /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
--- Scott M Stark [EMAIL PROTECTED] wrote: That is correct. The packaging required to run under a 2.2 servlet container is inconsistent with that required to run under a 2.3 container due to the change in the web container class loader behavior. I see this with Tomcat 3.2.3 vs Tomcat 4.0. Really, the only time this shows up is for JSP pages trying to access EJBs. Due to a problem/feature of the 2.2 version of jasper this required duplicate classes to be placed into the war. This is no longer required in the 2.3 spec version, and in fact now causes a problem. The whole optimized call thing is going to change along with the class loader architecture. It is also unnecessary due to the introduction of local interfaces. OK - So I will go with Jetty's non-compliant ClassLoader strategy. Calls will only be delegated upwards if they cannot be satisfied locally. Trouble is, this fails the isAssignableFrom() check in JRMPContainerInvoker.invoke() and blows up. So, I shall check my code in (hopefully tonight) and hope that some kind soul removes all the optimise/serialise code soon. I guess that wraps it all up. Greg, mate, you got away this time ! Cheers, all, Jules P.S. Still mystified about how local interfaces solve all this magically - I shall have to read up on it - Original Message - From: Greg Wilkins [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Rickard Öberg [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 21, 2001 2:58 AM Subject: Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders Julian Gosnell wrote: Your just putting the onus on the Application programmer to work around shortcomings in the Server - I think. But that is exactly the problem with the non-compliant class loader as specified by the 2.3 servlet spec. Because it advocates a application developer knows better approach, then the application developer get's total control over non-system classes - so they have to set it up right, else it does not work. If they want to share class instances between the servlet container and the EJB container, then they MUST prevent the servlet context from seeing those classes, else it will load it's own copy of them. There is absolutely no programatic way to distinguish between a webapp that has included a class on purpose to override an old version in the container, or due to an unknowing programmer being overzealous with their classpath. Perhaps someone will make a pronouncement on HOW JBoss/Jetty SHOULD behave here. Then we can figure out how to achieve this behaviour. Unfortunatley the default behaviour should be what the specification says and the 2.3 servlet spec definitely requires the non java2 compliant class loader. Somebody should check the full J2EE specification to see exactly what it specifies, as there is no guarantee that the specs are compatible in this regards. I'm in two minds about providing the compliant loader options - while I think it is the simple and correct way to go, it may just complicate things to propogate a non standard mode. Maybe EJB developers are just going to have to be a lot more careful with their classpaths now??? And this includes the developers of the JBoss web integration test suite. Their should not be classes in the webapp context that are also available via the EJB container or system class loader. Regards Yahoo! Groups Sponsor -~-- Universal Inkjet Refill Kit $29.95 Refill any ink cartridge for less! Includes black and color ink. http://us.click.yahoo.com/bAmslD/MkNDAA/ySSFAA/CefplB/TM -~- For the latest information about Jetty, please see http://jetty.mortbay. Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ __ 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: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
Really, what was the package structure that caused the exception? I thought I had tested a number of variations and hadn't seen any issues with normalized ears. Regardless, I'm going to work on the deployment layer to clean it up and add support unarchived ears. - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 21, 2001 3:30 AM Subject: Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders Scott M Stark wrote: That is correct. The packaging required to run under a 2.2 servlet container is inconsistent with that required to run under a 2.3 container due to the change in the web container class loader behavior. I see this with Tomcat 3.2.3 vs Tomcat 4.0. Really, the only time this shows up is for JSP pages trying to access EJBs. Well, *all* access from the web container to EJB's (i.e. servlets too) need to be aware of these changes. We ran into this the other day, and the fix was to bundle crimson.jar into our app too (i.e. not rely on it being available). Now, because of all this bundling going on, the EAR quickly grows HUGE, which means that for development you want hot-deploy on exploded EAR files. Unfortunately JBoss does not currently support that, so the cycling time becomes somewhat excessive. :-( /Rickard -- Rickard Öberg ___ 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-dev] JBoss 2.4.3 classloading problems
I'm using the bundled JBoss-2.4.3_Tomcat-4.0 package, and trying to use Castor from one of my session beans to turn an entity bean's data into an XML string (no JDO-thang, just plain marshalling to xml). I get a Castor exception about not finding my own beans' data, and after a few hours of web-searching, I've found a few references mentioning this as a classloader problem. According to the web sources, Castor (laying in jboss/lib/ext) is loaded by a different classloader, which is being used for my EJBs; therefore Castor is unable to see/use my beans, so I'm unable to use Castor. Is there any workaround or solution for the problem? Thanks, Christopher -- .Digital.Yearning.for.Networked.Assassination.and.Xenocide ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
Julian Gosnell wrote: OK - So I will go with Jetty's non-compliant ClassLoader strategy. Calls will only be delegated upwards if they cannot be satisfied locally. Please don't call it Jetty's non-compliant strategy! We are just relunctanly following the servlet spec!-) Trouble is, this fails the isAssignableFrom() check in JRMPContainerInvoker.invoke() and blows up. What class does it fail for? Can't you remove that class/jar from the webapplication, so that it can only be loaded from the EJB classloader? cheers -- Greg Wilkins[EMAIL PROTECTED] GB Phone: +44-(0)7092063462 Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 http://www.mortbay.com AU Phone: +61-(0)2 98107029 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/iiop/src/main/org/jboss/ejb/plugins/iiop/server IIOPContainerInvoker.java
User: reverbel
Date: 01/11/21 04:24:22
Modified:iiop/src/main/org/jboss/ejb/plugins/iiop/server
IIOPContainerInvoker.java
Log:
Added special treatment for EJBObject methods getHandle() and getPrimaryKey().
Added special treatment for EJBHome method getHomeHandle().
Bug fix: the creation of CORBA object reference for entity beans now deals
with the CacheKey issue.
Inserted alternative (and currently commented out) implementations for the
methods toByteArray() and toObject().
Revision ChangesPath
1.9 +109 -43
contrib/iiop/src/main/org/jboss/ejb/plugins/iiop/server/IIOPContainerInvoker.java
Index: IIOPContainerInvoker.java
===
RCS file:
/cvsroot/jboss/contrib/iiop/src/main/org/jboss/ejb/plugins/iiop/server/IIOPContainerInvoker.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- IIOPContainerInvoker.java 2001/10/31 21:33:09 1.8
+++ IIOPContainerInvoker.java 2001/11/21 12:24:22 1.9
@@ -65,6 +65,7 @@
import org.omg.CosNaming.NamingContextPackage.NotFound;
import org.omg.CosNaming.NameComponent;
+import org.jboss.ejb.CacheKey;
import org.jboss.ejb.Container;
import org.jboss.ejb.ContainerInvokerContainer;
import org.jboss.ejb.ContainerInvoker;
@@ -72,14 +73,15 @@
import org.jboss.ejb.MethodInvocation;
import org.jboss.ejb.plugins.iiop.client.StubStrategy;
import org.jboss.ejb.plugins.iiop.EJBMetaDataImpl;
+import org.jboss.ejb.plugins.iiop.HandleImpl;
+import org.jboss.ejb.plugins.iiop.HomeHandleImpl;
import org.jboss.ejb.plugins.iiop.RmiIdlUtil;
-import org.jboss.metadata.EntityMetaData;
-import org.jboss.metadata.MetaData;
-import org.jboss.metadata.SessionMetaData;
-import org.w3c.dom.Element;
import org.jboss.iiop.rmi.AttributeAnalysis;
import org.jboss.iiop.rmi.OperationAnalysis;
import org.jboss.iiop.rmi.InterfaceAnalysis;
+import org.jboss.metadata.EntityMetaData;
+import org.jboss.metadata.MetaData;
+import org.jboss.metadata.SessionMetaData;
import org.jboss.web.WebClassLoader;
/**
@@ -112,7 +114,7 @@
* CORBA reference for the corresponding codeEJBObject/code.
*
* @author a href=mailto:[EMAIL PROTECTED];Francisco Reverbel/a
- * @version $Revision: 1.8 $
+ * @version $Revision: 1.9 $
*/
public class IIOPContainerInvoker
extends Servant
@@ -504,8 +506,7 @@
initialContext.lookup(java:/JBossCorbaNaming));
// Unregister bean home from local CORBA naming context
- NameComponent[] name = new NameComponent[1];
- name[0] = new NameComponent(jndiName, );
+ NameComponent[] name = corbaContext.to_name(jndiName);
corbaContext.unbind(name);
// Deactivate the EJBHome
@@ -570,9 +571,15 @@
public EJBObject getEntityEJBObject(Object id)
throws RemoteException
{
+ //System.err.println( getEntityEJBObject(), id class is +
+ // id.getClass().getName());
+ //if (id instanceof CacheKey)
+ // System.err.println( CacheKey contains a
+ //+ ((CacheKey)id).getId().getClass().getName());
try {
+ id = (id instanceof CacheKey) ? id : new CacheKey(id);
return (EJBObject)PortableRemoteObject.narrow(
- poa.create_reference_with_id(toByteArray(id),
+ poa.create_reference_with_id(toByteArray(id),
beanRepositoryIds[0]),
EJBObject.class);
}
@@ -585,21 +592,14 @@
public Collection getEntityCollection(Collection ids)
throws RemoteException
{
- try {
- ArrayList list = new ArrayList(ids.size());
- Iterator idEnum = ids.iterator();
- while(idEnum.hasNext()) {
-list.add((EJBObject)PortableRemoteObject.narrow(
- poa.create_reference_with_id(toByteArray(idEnum.next()),
- beanRepositoryIds[0]),
- EJBObject.class));
- }
- return list;
- }
- catch (WrongPolicy wrongPolicy) {
- throw new ServerException(Wrong POA policy in IIOPContainerInvoker,
- wrongPolicy);
+ //System.err.println( entering getEntityCollection());
+ ArrayList list = new ArrayList(ids.size());
+ Iterator idEnum = ids.iterator();
+ while(idEnum.hasNext()) {
+ list.add(getEntityEJBObject(idEnum.next()));
}
+ //System.err.println( leaving getEntityCollection());
+ return list;
}
// Implementation of the interface InvokeHandler ---
@@ -625,7 +625,7 @@
ClassLoader oldCl =
[JBoss-dev] CVS update: contrib/iiop/src/main/org/jboss/ejb/plugins/iiop/client DynamicStub.java
User: reverbel
Date: 01/11/21 04:30:24
Modified:iiop/src/main/org/jboss/ejb/plugins/iiop/client
DynamicStub.java
Log:
Changed abstract superclass of DynamicStub: was
org.omg.CORBA_2_3.portable.ObjectImpl, now is javax.rmi.CORBA.Stub
(which extends org.omg.CORBA_2_3.portable.ObjectImpl).
This change fixes a bug I've found running the bang test.
Revision ChangesPath
1.3 +4 -4
contrib/iiop/src/main/org/jboss/ejb/plugins/iiop/client/DynamicStub.java
Index: DynamicStub.java
===
RCS file:
/cvsroot/jboss/contrib/iiop/src/main/org/jboss/ejb/plugins/iiop/client/DynamicStub.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- DynamicStub.java 2001/11/02 21:17:42 1.2
+++ DynamicStub.java 2001/11/21 12:30:24 1.3
@@ -7,7 +7,7 @@
package org.jboss.ejb.plugins.iiop.client;
import javax.rmi.CORBA.Util;
-import org.omg.CORBA_2_3.portable.ObjectImpl;
+import javax.rmi.CORBA.Stub;
import org.omg.CORBA_2_3.portable.InputStream;
import org.omg.CORBA_2_3.portable.OutputStream;
import org.omg.CORBA.portable.ApplicationException;
@@ -18,7 +18,7 @@
/**
* Dynamically generated IIOP stub classes extend this abstract superclass,
- * which extends codeorg.omg.CORBA_2_3.portable.ObjectImpl/code.
+ * which extends codejavax.rmi.CORBA.Stub/code.
*
* A codeDynamicStub/code is a local proxy of a remote object. It has
* methods (codeinvoke()/code, codeinvokeBoolean()/code,
@@ -30,10 +30,10 @@
* of operation parameters.
*
* @author a href=mailto:[EMAIL PROTECTED];Francisco Reverbel/a
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*/
public abstract class DynamicStub
- extends ObjectImpl
+ extends javax.rmi.CORBA.Stub
{
// Constructor -
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/iiop/src/main/org/jboss/ejb/plugins/iiop HomeHandleImpl.java
User: reverbel
Date: 01/11/21 04:32:41
Modified:iiop/src/main/org/jboss/ejb/plugins/iiop HomeHandleImpl.java
Log:
Added a more convenient constructor to the class HomeHandleImpl.
Revision ChangesPath
1.2 +12 -2
contrib/iiop/src/main/org/jboss/ejb/plugins/iiop/HomeHandleImpl.java
Index: HomeHandleImpl.java
===
RCS file:
/cvsroot/jboss/contrib/iiop/src/main/org/jboss/ejb/plugins/iiop/HomeHandleImpl.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- HomeHandleImpl.java 2001/08/14 21:25:40 1.1
+++ HomeHandleImpl.java 2001/11/21 12:32:41 1.2
@@ -19,7 +19,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a.
* @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
* @author a href=mailto:[EMAIL PROTECTED];Francisco Reverbel/a
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*/
public class HomeHandleImpl
implements HomeHandle
@@ -54,7 +54,17 @@
*/
public HomeHandleImpl(EJBHome home)
{
- this.ior = orb.object_to_string((org.omg.CORBA.Object)home);
+ this((org.omg.CORBA.Object)home);
+ }
+
+ /**
+* Constructs a ttHomeHandleImpl/tt.
+*
+* @param homeA CORBA reference for an codeEJBHome/code.
+*/
+ public HomeHandleImpl(org.omg.CORBA.Object home)
+ {
+ this.ior = orb.object_to_string(home);
}
// Public
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/iiop/src/main/org/jboss/ejb/plugins/iiop HandleImpl.java
User: reverbel
Date: 01/11/21 04:34:50
Added: iiop/src/main/org/jboss/ejb/plugins/iiop HandleImpl.java
Log:
IIOP-specific implementation of the EJBObject interface.
Revision ChangesPath
1.1 contrib/iiop/src/main/org/jboss/ejb/plugins/iiop/HandleImpl.java
Index: HandleImpl.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.ejb.plugins.iiop;
import java.rmi.RemoteException;
import java.util.Properties;
import javax.ejb.EJBObject;
import javax.ejb.Handle;
import javax.rmi.PortableRemoteObject;
import org.omg.CORBA.ORB;
/**
* A CORBA-based EJBObject handle implementation.
*
* @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a.
* @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
* @author a href=mailto:[EMAIL PROTECTED];Francisco Reverbel/a
* @version $Revision: 1.1 $
*/
public class HandleImpl
implements Handle
{
private static ORB orb;
static {
Properties props = System.getProperties();
orb = ORB.init(new String[0], props);
}
/**
* This handle encapsulates an stringfied CORBA reference for an
* codeEJBObject/code.
*/
private String ior;
/**
* Constructs an codeHandleImpl/code.
*
* @param ior An stringfied CORBA reference for an codeEJBObject/code.
*/
public HandleImpl(String ior)
{
this.ior = ior;
}
/**
* Constructs an ttHandleImpl/tt.
*
* @param obj An codeEJBObject/code.
*/
public HandleImpl(EJBObject obj)
{
this((org.omg.CORBA.Object)obj);
}
/**
* Constructs an ttHandleImpl/tt.
*
* @param obj A CORBA reference for an codeEJBObject/code.
*/
public HandleImpl(org.omg.CORBA.Object obj)
{
this.ior = orb.object_to_string(obj);
}
// Public
// Handle implementation -
/**
* Obtains the codeEJBObject/code represented by this handle.
*
* @return a reference to an codeEJBObject/code.
*
* @throws RemoteException
*/
public EJBObject getEJBObject()
throws RemoteException
{
try {
return (EJBObject)PortableRemoteObject.narrow(
orb.string_to_object(ior), EJBObject.class);
}
catch (Exception e) {
throw new RemoteException(Could not get EJBObject from Handle);
}
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/iiop/src/main/org/jboss/iiop/rmi ContainerAnalysis.java
User: reverbel
Date: 01/11/21 04:43:03
Modified:iiop/src/main/org/jboss/iiop/rmi ContainerAnalysis.java
Log:
Analysis changed to look at inherited methods of remote interfaces
(the IIOP container invoker needs to know about inherited methods).
Bug fix: attribute detection now compares getter/setter method names.
Revision ChangesPath
1.5 +32 -8 contrib/iiop/src/main/org/jboss/iiop/rmi/ContainerAnalysis.java
Index: ContainerAnalysis.java
===
RCS file:
/cvsroot/jboss/contrib/iiop/src/main/org/jboss/iiop/rmi/ContainerAnalysis.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ContainerAnalysis.java2001/10/30 12:34:58 1.4
+++ ContainerAnalysis.java2001/11/21 12:43:03 1.5
@@ -42,7 +42,7 @@
* Specification, version 1.1 (01-06-07).
*
* @author a href=mailto:[EMAIL PROTECTED];Ole Husgaard/a
- * @version $Revision: 1.4 $
+ * @version $Revision: 1.5 $
*/
public abstract class ContainerAnalysis
extends ClassAnalysis
@@ -366,7 +366,7 @@
for (int i = 0; i intfs.length; ++i) {
if (cls.isInterface()
- java.rmi.RemoteException.class.isAssignableFrom(cls)) {
+ java.rmi.Remote.class.isAssignableFrom(cls)) {
// Ignore java.rmi.Remote for interfaces
if (intfs[i] == java.rmi.Remote.class)
continue;
@@ -392,8 +392,14 @@
*/
protected void analyzeMethods()
{
- //methods = cls.getMethods();
- methods = cls.getDeclaredMethods();
+ // The dynamic stub and skeleton strategy generation mechanism
+ // requires the inclusion of inherited methods in the analysis of
+ // remote interfaces. To speed things up, inherited methods are
+ // not considered in the analysis of a class or non-remote interface.
+ if (cls.isInterface() java.rmi.Remote.class.isAssignableFrom(cls))
+ methods = cls.getMethods();
+ else
+ methods = cls.getDeclaredMethods();
m_flags = new byte[methods.length];
mutators = new int[methods.length];
@@ -405,9 +411,11 @@
methods[i].getName() + \.);
if (isAccessor(methods[i]) (m_flags[i]M_READ) == 0) {
+String attrName = attributeReadName(methods[i].getName());
Class iReturn = methods[i].getReturnType();
for (int j = i+1; j methods.length; ++j) {
- if (isMutator(methods[j]) (m_flags[j]M_WRITE) == 0) {
+ if (isMutator(methods[j]) (m_flags[j]M_WRITE) == 0
+ attrName.equals(attributeWriteName(methods[j].getName( {
Class[] jParams = methods[j].getParameterTypes();
if (jParams.length == 1 jParams[0] == iReturn) {
m_flags[i] |= M_READ;
@@ -418,9 +426,11 @@
}
}
} else if (isMutator(methods[i]) (m_flags[i]M_WRITE) == 0) {
+String attrName = attributeWriteName(methods[i].getName());
Class[] iParams = methods[i].getParameterTypes();
for (int j = i+1; j methods.length; ++j) {
- if (isAccessor(methods[j]) (m_flags[j]M_READ) == 0) {
+ if (isAccessor(methods[j]) (m_flags[j]M_READ) == 0
+ attrName.equals(attributeReadName(methods[j].getName( {
Class jReturn = methods[j].getReturnType();
if (iParams.length == 1 iParams[0] == jReturn) {
m_flags[i] |= M_WRITE;
@@ -473,6 +483,20 @@
}
/**
+* Convert an attribute write method name in Java format to
+* an attribute name in Java format.
+*/
+ protected String attributeWriteName(String name)
+ {
+ if (name.startsWith(set))
+ name = name.substring(3);
+ else
+ throw new IllegalArgumentException(Not an accessor: + name);
+
+ return name;
+ }
+
+ /**
* Analyse constants.
* This will fill in the codeconstants/code array.
*/
@@ -531,8 +555,8 @@
for (int i = 0; i methods.length; ++i) {
System.err.println(m_flags[+i+]= + m_flags[i]);
- if ((m_flags[i]M_INHERITED) != 0)
-continue;
+ //if ((m_flags[i]M_INHERITED) != 0)
+ // continue;
if ((m_flags[i] (M_READ|M_READONLY)) != 0) {
// Read method of an attribute.
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Optimised Servlet-EJB calls.../ Local Interfaces
Now that I've read about Local interfaces, I can see that they are the natural choice for communications between beans in the same Container. Is it being suggested that I should use these for servlet/jsp-ejb communication ? If not then we still need to support optimised calls etween the web and ejb container. it is these that fail between Jetty and JBoss. If so, then something is wrong. Do I really have to decide the architecture of my AppServer before I write my App? It should be transparent. If optimised calls between web-container and ejb-container are to be supported, then I still have ClassLoader issues to be resolved. Anyone ? Jules (having a bad day) __ 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: [JBoss-dev] Current CVS build.
Doh! have to copy run.jar to the bin dir not just the libs. Dain Sundstrom wrote: I updated about 20 minutes ago and it works fine for me. -dain -Original Message- From: Dave Smith [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 20, 2001 4:58 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Current CVS build. When running a JBOSS build from CVS Nov 20, 17:00 EST it now does not start. Here is the starting sequence. (It shuts down by itself). The config files did work with the build from 2 days ago. ./run.sh == == JBoss Bootstrap Environment JAVA: /usr/j2sdk1.3.0/bin/java JAVA_OPTS: -hotspot -Djboss.boot.loader.name=run.sh -Djava.library.path=/home/dave/import/com/candata/bbx -Djavax.xml.parsers.DocumentBuilderFactory=org.apache.crimson. jaxp.DocumentBuilderFactoryImpl -Djavax.xml.parsers.SAXParserFactory=org.apache.crimson.jaxp.S AXParserFactoryImpl CLASSPATH: /home/dave/j/bin/run.jar: == == [GPA] Microkernel ClassLoaders and Libraries initialized Libraries adding URLClassLoader 2012031725 key URL file:/home/dave/j/conf/default/ Libraries adding URLClassLoader -1231209341 key URL file:/home/dave/j/lib/ext/log4j.jar Libraries adding URLClassLoader -1729047754 key URL file:/home/dave/j/lib/ext/jboss-spine.jar [root] Started Log4jService, config=file:/home/dave/j/conf/default/log4j.properties [GPA] General Purpose Architecture [GPA] [GPA] Java version: 1.3.0,Blackdown Java-Linux Team [GPA] Java VM: Java HotSpot(TM) Client VM Blackdown-1.3.0-FCS,Blackdown Java-Linux Team [GPA] OS-System: Linux 2.2.16,i386 [GPA] JBoss Version : 3.0.0alpha(200109280911) [GPA] JBoss start time : Tue Nov 20 17:47:19 EST 2001 [GPA] localDir : /home/dave/j [GPA] installationURL : file:/home/dave/j/ [GPA] configuration : file:/home/dave/j/conf/default/ [GPA] libraries : file:/home/dave/j/lib/ext/ [GPA] local patch directory: [GPA] Oh, and remember we love you [Shutdown] Shutdown hook added [ServiceController] Controller MBean online [ServiceDeployer] Starting [ServiceDeployer] Found a temp directory left over from a previous run - deleting it. [ServiceDeployer] Temporary deploy directory is /home/dave/j/tmp/deploy/ServiceDeployer [ServiceDeployer] Started [Default] JBoss 3.0.0alpha(200109280911) [RABBIT-HOLE] Started in 0m:1s:193ms [Shutdown] Shutting down all services [Default] Shutting down [ServiceController] Stopping 1 services [ServiceController] Stopped 0 services [Shutdown] Shutdown complete [Default] Shutdown complete ___ 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: [JBoss-dev] Re: [jboss-docs] Is the build system too complicated?
I do have a slightly off-topic gripe -- as of late, (in the rh snapshots),
jboss-all/tools/bin/ant has not been executable on UNIX systems (took my
little mind a while to figure out what was going on). The
jboss-all/build/build.sh script has been failing because of it. It looks
for an executable 'ant', but never finds it (it doesn't have the
executable bit set). I can see three possible solutions:
1. Just have the executable bit set on the ant script to start with
2. Change the search() function in build.sh to read like this:
search() {
search=$*
for d in $search; do
ANT_HOME=`pwd`/$d
ANT=$ANT_HOME/bin/ant
# -- Begin modifications
# If the file exists at all, attempt to add the executable bit
if [ -e $ANT ]; then
`chmod +x $ANT`
fi
# -- End modifications
if [ -x $ANT ]; then
# found one
echo $ANT_HOME
break
fi
done
}
#(just added a -e test to see if the file exists, and attempt to make it
executable so that the next -x test works)
3. Skip looking for an executable ant script -- just make sure it exists,
and call it with 'sh ant'.
-jason
Jason Dillon [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
11/20/2001 09:38 PM
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject:[JBoss-dev] Re: [jboss-docs] Is the build system too
complicated?
I have not found an easy way to provide this common setup/initialization
stuff as a resource. Perhaps if I could tell the JAXP parser to read a
resource file when parsing this could be done, but that would require the
Ant entity hooks to be installed to handle that.
Perhaps they have done that, perhaps I could sway them todo it... though
my
previous attempts to do so has failed (too much *ucking voting).
If you can think of a way please let me know.
Thanks for your feedback!
--jason
On Tue, 20 Nov 2001, David Jencks wrote:
It has often seemed to me that there is substantial duplication between
the
setup parts of the module level build.xml files. I sure haven't figured
out a clue of a way to reduce this, but if it could be done, it might
make
the files a little less intimidating. In light of the vast improvement
over the preceding build system, this is a hardly visible quibble.
david jencks
On 2001.11.20 16:43:07 -0500 Jason Dillon wrote:
Please let me know if you think that the build system is too
complicated,
or
if there is some part of the system which is too complicated.
--jason
---
Subscribe: [EMAIL PROTECTED]
Unsubscribe:[EMAIL PROTECTED]
Archive: http://groups.yahoo.com/group/jboss-docs/
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Sponsor -~--
Universal Inkjet Refill Kit $29.95
Refill any ink cartridge for less!
Includes black and color ink.
http://us.click.yahoo.com/Vv.L9D/MkNDAA/ySSFAA/9rHolB/TM
-~-
---
Subscribe: [EMAIL PROTECTED]
Unsubscribe:[EMAIL PROTECTED]
Archive: http://groups.yahoo.com/group/jboss-docs/
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
___
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] Developing with JBoss
How would this help in the least? My understanding is that if you use a directory, the dd is checked for time changes and if it changes the whole app is undeployed and redeployed. Unless you can put your app in independently deployable chunks, you will need to undeploy and redeploy the entire application anyway. Why can't you use the Scoped Classloader, which puts several ears into the same classloader and application? Also if the problem is with jsps I thought I saw somewhere that you could change the copied, deployed, unpacked jsp files while the app was running and they would get picked up and recompiled. Haven't tried this though. david jencks On 2001.11.21 03:58:06 -0500 Rickard Öberg wrote: Hey Developing with JBoss used to be very good due to hot deploy features. Now that our app is growing rapidly (mostly LOADS of JSP's) we're seeing that it's not so nice, because we have to package the app as an EAR file before deployment. If JBoss could work from a directory, that would cut down the dev cycle by a lot. Looking at the J2EE deployer it seems as though it can take a directory as input. However, if that is the case, then it gets packaged into a JAR anyway! Thus, the overhead we skipped by not packaging it into an EAR file in the first place is added anyway. Is this really necessary, and would it be possible to change it? As it is, we have a redeploy cycle of about a minute, which is not nice... /Rickard -- Rickard Öberg ___ 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, Greg/Scott - Optimised intra-container calls ClassLoaders
On 2001.11.21 07:15:29 -0500 Scott M Stark wrote: Really, what was the package structure that caused the exception? I thought I had tested a number of variations and hadn't seen any issues with normalized ears. Regardless, I'm going to work on the deployment layer to clean it up and add support unarchived ears. I the likely case you get to this before I do, my goals for j2ee and other deployment are: - Unify the ServiceLibraries and the Scoped Classloader and always use the result. - Separate deployment into --autodeploy detection. This will watch directories and on timestamp change undeploy and redeploy. -Universal deployer. This will --determine which classloader to use (system (now ServiceLibraries) or application (now Scoped), but these should use the same code base). This may turn into your idea of virtual host. --put all accessible classes from the packaging into the extensible classloader (I'd use extractPackages from DeployerMBeanSupport) --Figure out what order to process the xml dd files, discovered in the previous step. --Feed the xml files to the appropriate deployers in the appropriate order. -individual deployers (Service, RAR, ContainerFactory, J2ee, etc) --these will now only process the (xml) dd. -A new deployer for deployment scripts that basically contain an ordered list of other things that can be deployed. Although in principal I think all dependencies should be stated explicitly, a script facility would allow deployment of units in a specified order rather than relying on the random order of detection by autodeployer. Any thoughts? David Jencks - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 21, 2001 3:30 AM Subject: Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders Scott M Stark wrote: That is correct. The packaging required to run under a 2.2 servlet container is inconsistent with that required to run under a 2.3 container due to the change in the web container class loader behavior. I see this with Tomcat 3.2.3 vs Tomcat 4.0. Really, the only time this shows up is for JSP pages trying to access EJBs. Well, *all* access from the web container to EJB's (i.e. servlets too) need to be aware of these changes. We ran into this the other day, and the fix was to bundle crimson.jar into our app too (i.e. not rely on it being available). Now, because of all this bundling going on, the EAR quickly grows HUGE, which means that for development you want hot-deploy on exploded EAR files. Unfortunately JBoss does not currently support that, so the cycling time becomes somewhat excessive. :-( /Rickard -- Rickard Öberg ___ 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
[JBoss-dev] How about a dtd for *service.xml files? (3.0)
I wrote up a dtd for *service.xml files, anyone have a problem if I check it in and modify the existing *service.xml files to use it? In particular are there problems with free-form xml being used within attribute elements? (I only tried jboss-service.xml so far.) If there are such problems can we deal with them e.g. with namespaces? Thanks david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Optimised Servlet-EJB calls.../ Local Interfaces
Julian Gosnell wrote: Is it being suggested that I should use these for servlet/jsp-ejb communication ? I would :-) If so, then something is wrong. Do I really have to decide the architecture of my AppServer before I write my App? It should be transparent. You can write your app so that these issues are transparent, but then you need to take alays care of the worst case, which is remote behaviour. If not, then you are guilty of having believed in the Seven Fallacies of Network Computing (http://wwwtec.informatik.uni-rostock.de/IuK/gk/thm/devdef/Vortrag1/tsld008.htm) Architecture is rarely transparent, although it is often quite possible to *localize* the impact of it to some degree. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Optimized Servlet-EJB calls.../ Local Interfaces
Now that I've read about Local interfaces, I can see that they are the natural choice for communications between beans in the same Container. Is it being suggested that I should use these for servlet/jsp-ejb communication ? Yep, but that is in the J2EE spec not the Servlet or ejb specs. If not then we still need to support optimized calls between the web and ejb container. it is these that fail between Jetty and JBoss. If so, then something is wrong. Do I really have to decide the architecture of my AppServer before I write my App? It should be transparent. The trick is if you think you may want in VM optimized calls you can not rely on the pass by value style method calls. This means don't use Object parameters as temp variables. Later on you can switch to Local interfaces for speed. Alternatively, you could start with local interfaces and then switch to remote if you want to move the web layer to another vm. This has a similar issue regarding by reference parameters. You can't rely on updated parameters being reflected in the web layer. If optimized calls between web-container and ejb-container are to be supported, then I still have ClassLoader issues to be resolved. Whey have to be in an EAR with class-path refs properly set in the manifest.mf file. This is documented in either the J2EE spec or the EJB spec. -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] How would RDF help us, Rickard?
Hey, I tried looking into rdf a little bit since Rickard has been pushing it for mbean configuration, but as far as I have read (not very far) I don't see the point. Is there an example of using rdf for something remotely resembling component configuration that might convince me quickly that this is a good idea? Thanks david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
Greg Wilkins wrote: What class does it fail for? Can't you remove that class/jar from the webapplication, so that it can only be loaded from the EJB classloader? It should be loaded by the EAR loader methinks. -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Developing with JBoss
David Jencks wrote: How would this help in the least? My understanding is that if you use a directory, the dd is checked for time changes For the auto-deployer, yes. I think I'd actually prefer to not use the auto-deployer, and instead make an Ant task that does the deploy command explicitly. Then there's no need to watch dd's or anything. and if it changes the whole app is undeployed and redeployed. Unless you can put your app in independently deployable chunks, you will need to undeploy and redeploy the entire application anyway. What I want to avoid is the copying and packaging that goes on. Do you have any idea of the time it takes to package 1500 JSP's into a JAR, and then have that 3-4Mb file copied and exploded into a tmp dir, and this for every time you make a change in a single JSP? Forever I can tell you. It adds up to *a lot* of time each day for just redeployment. Why can't you use the Scoped Classloader, which puts several ears into the same classloader and application? Could work, but I'd rather do something portable. Plus, it's non-trivial to break up our app (it's rather monolithic). Plus, several EAR's - several web deployments - several web contexts - no session sharing - no good. Also if the problem is with jsps I thought I saw somewhere that you could change the copied, deployed, unpacked jsp files while the app was running and they would get picked up and recompiled. Haven't tried this though. No good. So, I change a file, and get it to work. I then change a class and rebuild. Poof, my changed JSP file is gone. No, it needs to be clean, or there's just no point. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] How would RDF help us, Rickard?
David Jencks wrote: I tried looking into rdf a little bit since Rickard has been pushing it for mbean configuration, but as far as I have read (not very far) I don't see the point. Is there an example of using rdf for something remotely resembling component configuration that might convince me quickly that this is a good idea? AFAIK there are no good reasons to use RDF at all, apart from giving you that feel-good feeling and a voice in the back of your head saying you're gonna be glad for this some day. RDF is not an easy sell if you're always looking at single examples. It's when you get more stuff into RDF that you can do interesting things, since a large part of it revolves around semantic deductions. Oh yeah, now I remember, Mozilla uses RDF for all of their stuff. I believe they have a couple of this is how it went docs as well at their site (mozilla.org). I'm gonna try and use RDF for as much as possible in my future projects. At some point critical mass is reached and you can do all sorts of funky stuff. Hey, it's only XML anyway, so no loss if nothing good comes out of it. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
Scott M Stark wrote: Really, what was the package structure that caused the exception? I thought I had tested a number of variations and hadn't seen any issues with normalized ears. We had to include jaxp.jar and crimson.jar in our EAR to get XML parsing to work. With only jaxp.jar you get a LinkError (or something like that) because you'll get jaxp.jar from the app and the parser from the server, and the interfaces the parser implements is not the same as that in jaxp.jar (=classloader hell). Regardless, I'm going to work on the deployment layer to clean it up and add support unarchived ears. That would be sooo appreciated. It would save us so much time it aint funny... /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
|I was getting nasty errors when trying to make |optimised calls from the web to the ejb container. | |It seems that while JBoss is aware that both client |and server objects exist within the same vm, it was |upset that the call was being serialised, instead of |just simply made natively, and wanted to tell me about |it. | |So I investigated | |Along the path that an invocation must make from web |to ejb container a test (Class.isAssignableFrom()) is |made to establish whether the call can be made between |two ClassLoaders without serialisation. I am going to remove this test but it doesn't fix the problem. |Jetty has 2 modes in which it can run the ClassLoader |used for WebApps. | |1. Java 2 compliant - all requests for classes are |delegated first to it's parent. | |Using this strategy you may get bitten if your webapp |uses e.g. different versions of the same |infrastructure than it's container - since the |container's copies will be used in preference. |Problems also occur with abstract APIs (e.g. JAXP), |loaded by the container, looking for implementations |which the webapp contains, but the container does not |ship with. Right this is afaik the only way to make integration work, unless there is physical sharing for CL. I could be wrong. The problem you describe is not a limitation of the model but really a BUG in the application code, really you should always start by looking for classes from the CL context. The way to do this is to always set the parent of the cl you build from the context. You are done. |2. Non-compliant - only requests for system classes |are passed upwards. Don't do this, you essentially shoot all possible integration by always using the Jetty CL. If you have classes that are duplicated then you are shot for sure. |This strategy resolves the problems listed against (1) |but causes the isAssignableFrom() test mentioned above |to fail. What appears to happen is that JBoss passes of course |ClassLoader A to the EJB container which loads class X |then on to Jetty which creates it's WebApp |ClassLoader, B, as a child of A, then asks B to load |class X. B does not delegate to A, but loads class A |for a second time. because you don't delegate. Again it is a bug in the client app if you don't set the parent. Also why in the world would you do away with delegation in integration? The bug you describe above, is it the only reason? if so then that is a bit strange. |Scott, If you could explain a little about the |architecture of ClassLoaders in JBoss3, Greg and I may |be in a better position to figure out how to get this |going. It is simple rh cls will enable you to get visibility on all apps packaged classes. If Jetty uses the contextCL and we always call jetty from JBoss then you leverage this. The fact that you won't get a ClassCast is a by-product of integration not of the scope. Then the scope buys you something more powerful. In this first case you still need to package all the classes with the application. The scope CL enables you to do away with this. We will have scope at the app level and scope at the system level. I will code that. If jetty uses the RH cl directly, as it should when we actually integrate the codebases then the problem is natively taken care of, you will see the classes directly. It will make for superior packaging (lack of) where right now you have a nightmare of where did I put my classes. |Greg, I guess we are looking at pluggable |ContextLoader strategies - stand-alone, jboss etc... Again setting the parent to all your cls from context and not dissabling delegation is the simplest thing to try, you will use RH cl implicitely by delegation. It works standalone and jboss integration and you still use your own little cl stuff. INtegrated Jetty will need to use the RH cl. |WebSphere seems to have a highly configurable |ClassLoader system, and I think it is unlikely that |there is a one-size-fits-all solution here. bullshit, webshemere still doesn't support hot-deploy which tends to indicate a primitive usage of classloaders. I could be wrong there, I don't know webshemere. marcf |Sorry to complicate your mornings guys, | | |Jules | | |__ |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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
| 2. Non-compliant - only requests for system classes | are passed upwards. | | |FWIW, Tomcat4 does the same thing, which means that you have to bundle |in jaxp.jar in your webapp, or you're going to get strange class-cast |exceptions and class-not-found exceptions. The solution is to bundle all |libraries with your app. That is REALLY dumb, what in the world are they thinking? are we the only ones that do smart things with CL architectures? who is in charge of this craig? Jetty guys, doing this correctly is going to blow a hole in everyone, tomcat included... why? the packaging will become a trivial thing, you will not need to package everyone together and what not, it makes the distribution and package a trivial thing. You will see, this is really a order of magnitude simpler. So if you want to take a chance and leave Tomcat in the dust, this is the one, do it! marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
| |Your just putting the onus on the Application |programmer to work around shortcomings in the Server - |I think. Like I said, dumb backwards thinking, I am in fact doubtful that Craig would do such a thing, Rickard you sure about this? |Perhaps someone will make a pronouncement on HOW |JBoss/Jetty SHOULD behave here. Then we can figure out |how to achieve this behaviour. Done, look I am almost done with teh rewrite of the proxies (having fun at this stage), then I want to look at deployment and packaging, we need to unify the way it works, it will be important for all functional aspect of the sub-containers, eg EJB/web services and their clustering. We are running smack into the packaging madness and how it ties to ClassLoaders. We DO HAVE THE SILVER BULLET, we have had it for a year, I just need to sit down and make it simpler. We will get there. marcf | | --- Rickard Öberg [EMAIL PROTECTED] wrote: |Julian Gosnell wrote: | | 2. Non-compliant - only requests for system | classes | are passed upwards. | | | FWIW, Tomcat4 does the same thing, which means that | you have to bundle | in jaxp.jar in your webapp, or you're going to get | strange class-cast | exceptions and class-not-found exceptions. The | solution is to bundle all | libraries with your app. | |If you do that with Jetty in stand-alone, compliant |mode - you will simply find you are using the JAXP |that Jetty loaded to parse it's own XML configuration |files. | |If you do it with Jetty in embedded, non-compliant |mode - you will find isAssignableFrom() fails. | |So Jetty, at the very leat, needs to know whether it |is embedded or not, and it may be more complex than |that - I thought I would bring in the big guns at this |point ! | |Jules | | Jetty | | This strategy resolves the problems listed against | (1) | but causes the isAssignableFrom() test mentioned | above | to fail. What appears to happen is that JBoss | passes | ClassLoader A to the EJB container which loads | class X | then on to Jetty which creates it's WebApp | ClassLoader, B, as a child of A, then asks B to | load | class X. B does not delegate to A, but loads class | A | for a second time. | | | So you need to put all classes in the EAR scope | instead of in the webapp | scope to make things work. Right? | | | /Rickard | | | | -- | Rickard Öberg | | |__ |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 | | Yahoo! Groups Sponsor -~-- |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/XwUZwC/MkNDAA/ySSFAA/CefplB/TM |-~- | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
| Your just putting the onus on the Application | programmer to work around shortcomings in the Server - | I think. | | |Yes, the app programmer needs to know about classloading. Bug.. |feature.. bug... feature.. which'll it be? :-) | 100% bug |On the one hand, having straight-forward classloading makes it easy to |develop a web-app. On the other hand, having sandboxed classloading |makes the web-app more self-contained and portable, since they don't |rely on the surrounding server to provide any of its classes. bullshit marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Developing with JBoss
On 2001.11.21 11:53:03 -0500 Rickard Öberg wrote: David Jencks wrote: How would this help in the least? My understanding is that if you use a directory, the dd is checked for time changes For the auto-deployer, yes. I think I'd actually prefer to not use the auto-deployer, and instead make an Ant task that does the deploy command explicitly. Then there's no need to watch dd's or anything. and if it changes the whole app is undeployed and redeployed. Unless you can put your app in independently deployable chunks, you will need to undeploy and redeploy the entire application anyway. What I want to avoid is the copying and packaging that goes on. Do you have any idea of the time it takes to package 1500 JSP's into a JAR, and then have that 3-4Mb file copied and exploded into a tmp dir, and this for every time you make a change in a single JSP? Forever I can tell you. It adds up to *a lot* of time each day for just redeployment. Ok, I'll believe you. Why can't you use the Scoped Classloader, which puts several ears into the same classloader and application? Could work, but I'd rather do something portable. Plus, it's non-trivial to break up our app (it's rather monolithic). Plus, several EAR's - several web deployments - several web contexts - no session sharing - no good. You're talking about a non-portable development environment anyway aren't you? Putting pieces of your 1500 jsps in different files might not be so hard??? I really don't know, just talking. Also if the problem is with jsps I thought I saw somewhere that you could change the copied, deployed, unpacked jsp files while the app was running and they would get picked up and recompiled. Haven't tried this though. No good. So, I change a file, and get it to work. I then change a class and rebuild. Poof, my changed JSP file is gone. No, it needs to be clean, or there's just no point. ??? Are you proposing to change a copy of the source for the jsp rather than the source?? Cmon, you change your jsp in src, deployment of change consists of copying changed file to temp deployment directory?? You rebuild from source, you pick up the changes. Only problem I see is automatically finding the correct tmp deploy directory again after redeployment of the whole ear. david /Rickard -- Rickard Öberg ___ 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] Developing with JBoss
Rickard Öberg wrote: David Jencks wrote: How would this help in the least? My understanding is that if you use a directory, the dd is checked for time changes For the auto-deployer, yes. I think I'd actually prefer to not use the auto-deployer, and instead make an Ant task that does the deploy command explicitly. Then there's no need to watch dd's or anything. I ran into the same problem and solved it by running Tomcat 4.0 as a separate process during development. Since tomcat works just fine with an already unpacked tree for my webapp, I simply modify my JSPs directly (I have a symbolic link from my webapp development tree to tomcat's webapps directory.) My ant rule to compile servlets and EJB remote/home interfaces is followed by a simple request to tomcat to reload the app: wget --http-user=foo --http-passwd=bar http://localhost:8080/manager/reload?path=/myapp I found this to be much easier than having to put the webapp in the ear for jboss. -- Andrew Scherpbier ( [EMAIL PROTECTED]) CTO, BlackBall Music ( http://www.blackballmusic.com/) ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
|I guess if you want your own implementation of JAXP, |then you should probably have to reinclude the JAXP |api itself no problem use the scope. marcf | | | Should the app-server not try, even in this | situation, | to optimise intra-container calls ? | | Jules | | --- Rickard Öberg [EMAIL PROTECTED] wrote: | Julian Gosnell wrote: | | Your just putting the onus on the Application | programmer to work around shortcomings in the | Server - | I think. | | | Yes, the app programmer needs to know about | classloading. Bug.. | feature.. bug... feature.. which'll it be? :-) | | On the one hand, having straight-forward | classloading makes it easy to | develop a web-app. On the other hand, having | sandboxed classloading | makes the web-app more self-contained and | portable, | since they don't | rely on the surrounding server to provide any of | its | classes. | | If you do that with Jetty in stand-alone, | compliant | mode - you will simply find you are using the | JAXP | that Jetty loaded to parse it's own XML | configuration | files. | | | Yes, the straight-forward mode. | | | If you do it with Jetty in embedded, | non-compliant | mode - you will find isAssignableFrom() fails. | | | Yup, the more complex and portable case. | | /Rickard | | -- | Rickard Öberg | | | __ | 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 | | Yahoo! Groups Sponsor | | For the latest information about Jetty, please see | http://jetty.mortbay. | | Your use of Yahoo! Groups is subject to | http://docs.yahoo.com/info/terms/ | | | |__ |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 | | Yahoo! Groups Sponsor -~-- |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/Vv.L9D/MkNDAA/ySSFAA/CefplB/TM |-~- | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
|Well, I believe the real fix is to make the EJB-loader use the non |Java2 class-loading style as well, i.e. force people to bundle in JAR's |that the app is going to use. That is the ultimate way to get things |portable, and to be able to allow different running apps use different |versions of, say, JAXP. no see my previous mail and the proper use of scopes, Rickard READ that code :) |What goes into 3? | |1 and 2, yes. That must be available from the classloader. I am curious to know myself. |Absolutely. And that is indeed the case, or you'll get funky classcast |exceptions (we had those a couple of days ago and had muchos fun trying |to figure out what happened). the scope stuff will ELIMINATE this class of problems ALTOGETHER I GUARANTEE IT. |Well, what is the need to optimize them anymore, really? I mean, use |local interfaces and that's it. The proxies don't have to do the check, |since it will be implied from what type of proxies that are used. Hey, |it's portable too. You still need to share the interfaces used by the different classes, the use of local interfaces doesn't impact the problem at all. marcf | |-- |Rickard Öberg | | | Yahoo! Groups Sponsor -~-- |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/XwUZwC/MkNDAA/ySSFAA/CefplB/TM |-~- | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
|If they are not optimised, RH currently throws an |exception and the test fails. So this needs fixing. RH is still using the old CL structure for the apps, when we default to the scope stuff, this class of problems will go away, we will need to integrate them with Jetty in teh 2 fashions explained above (actually the rh cl integration native due to teh silly spec requirements). | |I have heard of, but know nothing about, local |interfaces. I would have thought though, that they |must still be constrained by the basic laws of Class |assignability - i.e. if the way the ClassLoaders is that is correct, see my previous mail, orthogonal issues, rickard is sleeping this morning |Anyway, JBoss attempts to implement optimised |intra-container calls through the standard interface. |Are you suggesting we should throw all this code away |now? It would save me a lot of effort. are you kidding? as you know that won't simplify the problem and forcing people to use local stuff in EJB is still weird in my mind. WORA/SMCHORA sentimental bull. |Otherwise this brings us straight back to the same |problem. ClassLoader architecture which is what I need |to coordinate between JBoss and Jetty in order to pass |the testsuite. yes, correct. marcf| |Jules | | | /Rickard | | -- | Rickard Öberg | | |__ |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 | | Yahoo! Groups Sponsor -~-- |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/XwUZwC/MkNDAA/ySSFAA/CefplB/TM |-~- | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
|Julian Gosnell wrote: | |What goes into 3? | | | Your site's e.g. Logging classes etc.. which every app | uses. You figure it's cheaper to load them once into | the apps parent CL, than many times, into every app. | | |Ok, good point. I believe Tomcat handles this by using a common |directory that contains libraries that should be available to webapps |and server alike. right that would be the integration of the scope of apps and the RH cl microkernel. See previous mails. |Well, if you want to use local interfaces, then yes, you have to be |careful with how you package classes. They need to be in the EAR. right same problem, it doesn't fix the packaging. Orthogonal issues. |I'm torn. The optimization was introduced because there was no standard |way to do it, but now that it does... well.. what's the point? Backward |compatibility with people who have written apps that takes advantage of |it, yes, but that should be it. All new apps should use local interfaces |if you want local behaviour. Local behaviour in EJB: 1- same problem with the classes (values etc) that NEED to be shared between stacks 2- again 1 means that we still have the same problem but if we didn't EJB is not the only stack, we need that generic so that all apps/mbean work, an EJB only solution wouldn't work. marcf | |/Rickard | |-- |Rickard Öberg | | | Yahoo! Groups Sponsor -~-- |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/XwUZwC/MkNDAA/ySSFAA/CefplB/TM |-~- | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
|Well, *all* access from the web container to EJB's (i.e. servlets too) |need to be aware of these changes. We ran into this the other day, and |the fix was to bundle crimson.jar into our app too (i.e. not rely on it |being available). | |Now, because of all this bundling going on, the EAR quickly grows HUGE, |which means that for development you want hot-deploy on exploded EAR |files. Unfortunately JBoss does not currently support that, so the |cycling time becomes somewhat excessive. :-( The problem is not the support of exploded dirs, the problem is the packaging. DO YOU GUYS REALIZE WE ARE TALKING ABOUT AVATARS OF THE PACKAGING AND HOW IT TIES INTO CLASSLOADING? they are artificial problems, the cl arch of RH (forthcoming) will magically make them dissapear. or so we hope. marcf | |/Rickard | |-- |Rickard Öberg | | | Yahoo! Groups Sponsor -~-- |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/bAmslD/MkNDAA/ySSFAA/CefplB/TM |-~- | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
|-Original Message- |From: Scott M Stark [mailto:[EMAIL PROTECTED]] |That is correct. The packaging required to run under a 2.2 servlet |container |is inconsistent with that required to run under a 2.3 container due to the |change in the web container class loader behavior. I see this with Tomcat |3.2.3 |vs Tomcat 4.0. Really, the only time this shows up is for JSP pages trying |to access EJBs. Due to a problem/feature of the 2.2 version of jasper this |required duplicate classes to be placed into the war. This is no longer |required in the 2.3 spec version, and in fact now causes a problem. | Right ok, then let's integrate with Jetty and leave everybody else behind, buhbye! |The whole optimized call thing is going to change along with the class |loader architecture. It is also unnecessary due to the introduction of |local interfaces. that I don't agree see my previous mails marcf | |- Original Message - |From: Greg Wilkins [EMAIL PROTECTED] |To: [EMAIL PROTECTED] |Cc: Rickard Öberg [EMAIL PROTECTED]; |[EMAIL PROTECTED] |Sent: Wednesday, November 21, 2001 2:58 AM |Subject: Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - |Optimised intra-container calls ClassLoaders | | | Julian Gosnell wrote: | | Your just putting the onus on the Application | programmer to work around shortcomings in the Server - | I think. | | | But that is exactly the problem with the non-compliant | class loader as specified by the 2.3 servlet spec. | | Because it advocates a application developer knows better | approach, then the application developer get's total control | over non-system classes - so they have to set it up right, | else it does not work. | | If they want to share class instances between the servlet | container and the EJB container, then they MUST prevent | the servlet context from seeing those classes, else | it will load it's own copy of them. | | There is absolutely no programatic way to distinguish | between a webapp that has included a class on purpose to | override an old version in the container, or due to | an unknowing programmer being overzealous with their | classpath. | | | Perhaps someone will make a pronouncement on HOW | JBoss/Jetty SHOULD behave here. Then we can figure out | how to achieve this behaviour. | | | Unfortunatley the default behaviour should be what the | specification says and the 2.3 servlet spec definitely | requires the non java2 compliant class loader. | | Somebody should check the full J2EE specification to | see exactly what it specifies, as there is no guarantee | that the specs are compatible in this regards. | | I'm in two minds about providing the compliant loader | options - while I think it is the simple and correct | way to go, it may just complicate things to propogate | a non standard mode. Maybe EJB developers are just going | to have to be a lot more careful with their classpaths | now??? | | And this includes the developers of the JBoss web integration | test suite. Their should not be classes in the webapp | context that are also available via the EJB container or | system class loader. | | Regards | | | | | Yahoo! Groups Sponsor -~-- |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/bAmslD/MkNDAA/ySSFAA/CefplB/TM |-~- | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Classloader puzzle
Hi, I have a classloader problem in the IIOP container invoker code and would really appreciate some helpful hints... Classloader wizards: to understand the problem you do not have to know anything about CORBA/IIOP, so please read on! The problem only shows up with entity beans. When the IIOP container invoker creates a CORBA reference for such a bean, it embeds the bean´s primary key into the CORBA reference. When handling a bean invocation, the container invoker extracts the PK from the CORBA reference and passes this PK to the container as the first argument of a MethodInvocation. A ClassNotFoundException is thrown when the container invoker attempts to extract the PK from the CORBA reference (got the stack trace below running RMH's well-known cabin bean): java.lang.ClassNotFoundException: com.titan.cabin.CabinPK at org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:372) at org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:111) at java.lang.ClassLoader.loadClass(ClassLoader.java:253) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:195) at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:654) at java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:918) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at org.jboss.ejb.CacheKey.readExternal(CacheKey.java:118) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1212) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker.toObject(IIOPContainerInvoker.java:896) at org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker._invoke(IIOPContainerInvoker.java:665) at org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:239) at org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:456) at org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:581) I've found a way of circumventing the problem, but am not satisfied with it. Things work if I wrap the PK into a MarshalledObject before embedding it into the CORBA reference, and do the opposite thing when extracting the PK from the reference. Runs fine, but is very slow... The bank test takes forever to run. This code is in org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker, under contrib/iiop. Insertion/extraction of the PK is done through the methods toByteArray() and toObject(). Each of these methods has two implementations, one of them commented out. The commented out implementation solves the problem in the way described above. Suggestions are very welcome! Cheers, Francisco ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
| Well, I believe the real fix is to make the EJB-loader use the non | Java2 class-loading style as well, i.e. force people to bundle in JAR's | that the app is going to use. That is the ultimate way to get things | portable, and to be able to allow different running apps use different | versions of, say, JAXP. | | |I have to say that I reluctantly agree. Now that the non-compliant |loader cat is out of the bag, we have no choice but to force users |to be disciplined about their bundling of jars. For consistency this RH Scoped classloader to the rescue. I still need to fix the jung stuff for the ordering and overwritting but we are there. |should apply the the EJB container as well as teh servlet container |(again assuming the J2EE spec does agree with the 2.3 servlet spec). | | |However, I would like to suggest a change in the language. We should |try to force the users to NOT include jars that they can reasonably |expect the container will provide. You don't force your users jack, you give them a simple and consistent behavior as we are trying with RH and then it works and when it doesnt they know why. UI design at its simplest. |JAXP is a key example, as I think it was the driver for the change |in the specification. Users wanted richer XML parsing for their |web applications than was provided by their containers. Hence they |now have the ability to write an application that is dependant on |a specific JAXP version and/or provider by bundling the jars for |them. But now almost all container provide recent versions |of JAXP with good parser implementations, so applications that |include jaxp.jar and xerces.jar are probably fixing a problem that |no longer exists! | |So our language should encourage users to NOT include their own |versions of jars unless absolutely necessary for a particular |deployment. Somewhere is should be clearly stated that the BYO |implementation approach is bad because: Relax, when teh code is out and we see how it behaves then we can put forth recommendations of usage. Right now the UI recommendations are based on monolythic cl approaches. Give me time. | + Firstly and foremost, it is just bad OO design. You should be |dependant on the interfaces not the implementations. Sure it |allows you to get around short term deployment issues, but it is |a much better approach to try to get your container to provide |the APIs and implementations that you need. | | + Including your own jars does create confusion and problems in |calling local interfaces that actually cross classloader boundaries. |The new priority inversion of classloader increases the chances |of cross loader calls being made. | | + There is a significant cost in terms of memory and serialization. | | + Applications that provide their own implementations of common |libraries cannot receive the benefits of updating the container. |If new versions are deployed by a container that fix bugs or |improve performance, these are not used by applications that |have included their own jars. | | + The logical extension of shipping your own jaxp.jar in order |to be portable is to ship your own swing, your own jboss and |eventually your own JVM, OS and hardware :-) | |Thus I think the documentation should not be written so that |developers think I better include jaxp.jar xerces.jar as it is |better to be safe than sorry. | |Rather they should be encouraged to not include these jars, in |the knowledge that IF a problem does occur with a particular |container AND they can't update that container, only then should |they can fix that deployment by including specific versions of the |jars they need. | |Finally users should be given the confidence that their containers |of choice are open and being actively maintained, thus new APIs and |implementations should rapidly become available in the containers. | |regards my own eyes are rolling when I read the points. You are still carrying knowledge of the container to the user as developer. Bad UI design. Better than including CL dependencies in XML but still kind of silly. THIS IS PACKAGING KNOWLEDGE, i.e. it is worth about 0.2c marcf | | |-- |Greg Wilkins[EMAIL PROTECTED] GB Phone: +44-(0)7092063462 |Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 |http://www.mortbay.com AU Phone: +61-(0)2 98107029 | | | Yahoo! Groups Sponsor -~-- |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/1_Y1qC/MkNDAA/ySSFAA/CefplB/TM |-~- | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAIL PROTECTED]
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
|OK - So I will go with Jetty's non-compliant |ClassLoader strategy. Calls will only be delegated |upwards if they cannot be satisfied locally. then use the scope cl architecture. I will help you there. |Trouble is, this fails the isAssignableFrom() check in |JRMPContainerInvoker.invoke() and blows up. won't |So, I shall check my code in (hopefully tonight) and |hope that some kind soul removes all the |optimise/serialise code soon. yeah, consider it done. |I guess that wraps it all up. | |Greg, mate, you got away this time ! as far as I am concerned, you are all talking BS on some distant isolated island. I am on shore waiving my arms going guys ! guys! here! here ! look promised land! but you all can't hear me and pat yourselves on the back nonetheless, I'll send magic help! marcf | |Cheers, all, | | |Jules | | |P.S. | |Still mystified about how local interfaces solve all |this magically - I shall have to read up on it | | - Original Message - | From: Greg Wilkins [EMAIL PROTECTED] | To: [EMAIL PROTECTED] | Cc: Rickard Öberg [EMAIL PROTECTED]; | [EMAIL PROTECTED] | Sent: Wednesday, November 21, 2001 2:58 AM | Subject: Re: [jetty-discuss] Re: [JBoss-dev] | JBoss3/Jetty4, Greg/Scott - | Optimised intra-container calls ClassLoaders | | | Julian Gosnell wrote: | | Your just putting the onus on the Application | programmer to work around shortcomings in the | Server - | I think. | | | But that is exactly the problem with the | non-compliant | class loader as specified by the 2.3 servlet spec. | | Because it advocates a application developer | knows better | approach, then the application developer get's | total control | over non-system classes - so they have to set it | up right, | else it does not work. | | If they want to share class instances between the | servlet | container and the EJB container, then they MUST | prevent | the servlet context from seeing those classes, | else | it will load it's own copy of them. | | There is absolutely no programatic way to | distinguish | between a webapp that has included a class on | purpose to | override an old version in the container, or due | to | an unknowing programmer being overzealous with | their | classpath. | | | Perhaps someone will make a pronouncement on HOW | JBoss/Jetty SHOULD behave here. Then we can | figure out | how to achieve this behaviour. | | | Unfortunatley the default behaviour should be what | the | specification says and the 2.3 servlet spec | definitely | requires the non java2 compliant class loader. | | Somebody should check the full J2EE specification | to | see exactly what it specifies, as there is no | guarantee | that the specs are compatible in this regards. | | I'm in two minds about providing the compliant | loader | options - while I think it is the simple and | correct | way to go, it may just complicate things to | propogate | a non standard mode. Maybe EJB developers are | just going | to have to be a lot more careful with their | classpaths | now??? | | And this includes the developers of the JBoss web | integration | test suite. Their should not be classes in the | webapp | context that are also available via the EJB | container or | system class loader. | | Regards | | | | | Yahoo! Groups Sponsor | | For the latest information about Jetty, please see | http://jetty.mortbay. | | Your use of Yahoo! Groups is subject to | http://docs.yahoo.com/info/terms/ | | | |__ |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 | | Yahoo! Groups Sponsor -~-- |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/r9F0cB/MkNDAA/ySSFAA/CefplB/TM |-~- | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss 2.4.3 classloading problems
Ok, a perfect example of a user with UI problems in the CL behaviour. |I'm using the bundled JBoss-2.4.3_Tomcat-4.0 package, and trying to use |Castor from one of my session beans to turn an entity bean's data into an |XML string (no JDO-thang, just plain marshalling to xml). I get a Castor |exception about not finding my own beans' data, and after a few hours of |web-searching, I've found a few references mentioning this as a classloader |problem. The session beans have the MBean Cl as parent which has visibility on the castor classes. Something else is going on. marcf | |According to the web sources, Castor (laying in jboss/lib/ext) is loaded by |a different classloader, which is being used for my EJBs; therefore Castor |is unable to see/use my beans, so I'm unable to use Castor. | |Is there any workaround or solution for the problem? | |Thanks, |Christopher |-- |.Digital.Yearning.for.Networked.Assassination.and.Xenocide | |___ |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-dev] CVS update: jbosscx/src/main/org/jboss/resource/connectionmanager ManagedConnectionPoolFactory.java
User: thedug
Date: 01/11/21 10:14:51
Modified:src/main/org/jboss/resource/connectionmanager
ManagedConnectionPoolFactory.java
Log:
destroy() should actually close the connection so that the tcp connection isn't
left open.
Revision ChangesPath
1.3 +16 -0
jbosscx/src/main/org/jboss/resource/connectionmanager/ManagedConnectionPoolFactory.java
Index: ManagedConnectionPoolFactory.java
===
RCS file:
/cvsroot/jboss/jbosscx/src/main/org/jboss/resource/connectionmanager/ManagedConnectionPoolFactory.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ManagedConnectionPoolFactory.java 2001/09/11 18:38:58 1.2
+++ ManagedConnectionPoolFactory.java 2001/11/21 18:14:51 1.3
@@ -63,6 +63,22 @@
pool = null;
}
+/**
+ * Permanently closes an object, after it is removed from the pool. The
+ * object will not be returned to the pool - after this, it is gone. This
+ * is called when the pool shrinks, and when the pool is shut down.
+ */
+public void deleteObject(Object pooledObject) {
+try{
+((ManagedConnection)pooledObject).destroy();
+}catch(ResourceException e) {
+log.println(Unable to destroy ManagedConnection: +e);
+}
+
+ }
+
+
+
/**
* Creates a new ManagedConnection with the specified parameters.
*
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
Sanity, thanks professor seems you are on shore with me for once :) | Regardless, I'm going to work on the deployment layer to clean it up | and add support unarchived ears. | |I the likely case you get to this before I do, my goals for j2ee and other |deployment are: | | |- Unify the ServiceLibraries and the Scoped Classloader and always use the |result. correct. I will do it if you don't. |- Separate deployment into |--autodeploy detection. This will watch directories and on timestamp change |undeploy and redeploy. | |-Universal deployer. This will |--determine which classloader to use (system (now ServiceLibraries) or |application (now Scoped), but these should use the same code base). This |may turn into your idea of virtual host. Yes, good how are you going to do that? how about just moving the scl to sl? the only problem there is the ordering of lookups which I think differs significantly but... we can look at using one structure. If we always set the SL as parent to teh scl then I don't think we need to hint anything. |--put all accessible classes from the packaging into the extensible |classloader (I'd use extractPackages from DeployerMBeanSupport) woot? what is this? |--Figure out what order to process the xml dd files, discovered in the |previous step. |--Feed the xml files to the appropriate deployers in the appropriate order. | |-individual deployers (Service, RAR, ContainerFactory, J2ee, etc) |--these will now only process the (xml) dd. yes, good |-A new deployer for deployment scripts that basically contain an ordered |list of other things that can be deployed. Although in principal I think |all dependencies should be stated explicitly, a script facility would allow |deployment of units in a specified order rather than relying on the random |order of detection by autodeployer. | |Any thoughts? Excellent, some sanity finally, excellent professor, excellent. |David Jencks marcf | | - Original Message - | From: Rickard Öberg [EMAIL PROTECTED] | To: Scott M Stark [EMAIL PROTECTED] | Cc: [EMAIL PROTECTED]; | [EMAIL PROTECTED] | Sent: Wednesday, November 21, 2001 3:30 AM | Subject: Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - | Optimised intra-container calls ClassLoaders | | | Scott M Stark wrote: | | That is correct. The packaging required to run under a 2.2 servlet | container | is inconsistent with that required to run under a 2.3 container due | to | the | change in the web container class loader behavior. I see this with | Tomcat | 3.2.3 | vs Tomcat 4.0. Really, the only time this shows up is for JSP pages | trying | to access EJBs. | | | Well, *all* access from the web container to EJB's (i.e. servlets too) | need to be aware of these changes. We ran into this the other day, and | the fix was to bundle crimson.jar into our app too (i.e. not rely on it | being available). | | Now, because of all this bundling going on, the EAR quickly grows HUGE, | which means that for development you want hot-deploy on exploded EAR | files. Unfortunately JBoss does not currently support that, so the | cycling time becomes somewhat excessive. :-( | | /Rickard | | -- | Rickard Öberg | | | ___ | 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 | | | | Yahoo! Groups Sponsor -~-- |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/XwUZwC/MkNDAA/ySSFAA/CefplB/TM |-~- | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Developing with JBoss
Luke Taylor wrote: It's not just about the time for the deployment, which is minimal - if you're working on frontend stuff and just essentially modifying web pages, then you lose your whole session state. If you have a complicated web application with security, shopping carts etc, and you're working on the checkout pages, then you have to go through the whole use-case procedure every time you redeploy. If a web container can be configured to pick up the jsp's directly then you only have to reload the page to see a change. One solution is to use a template engine such as Velocity instead of JSP. Then there's no problem whatsoever: just have it pick up changed templates from your /src dev directory. That is, if you have a choice in the first place. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
OK, I'll risk one more posting... Marc, You seem to understand where I am coming from ! When will this new CL stuff come in ? Jetty's WAR CL will be a child of the one passed us by the J2EEDeployer in Thread.currentThread().getContextClassLoader(). What should it's behaviour be ? 1. DELEGATE up, then look in WAR (Java2 compliant) 2. Look in WAR, then DELEGATE up (sandboxing WebApp) 3. neither of the above. I have mentioned the problems associated with each approach already in this thread. 1. Optimisation code currently works - but containers classes are used in preference to WAR's 2. WAR's classes used, but optimisation code currently fails. 3. ??? Now a bit of an ill-informed rant: Since using a Remote EJB interface is more restrictive than using a Local one (everything must be serialisable) I can guarantee that whilst a Local interface may not work remotely, a Remote interface will always work locally... Still with me ? Therefore, why shouldn't my choice be to always use a Remote interface if I can, thus keeping all my options open and why shouldn't JBoss be able to apply exactly the same optimisations that it would to a local LocalInterface deployment to my local RemoteInterface deployment ? In fact why do I need a Local interface at all ? I don't want the interface to mandate my geographical location. I want all that done by a hot-pluggable implementation which will go as fast as it can in any given deployment scenario. It's all just a dynamic proxy anyway - isn't it ? I'm putting on my flame-proof jacket right now... If anyone wants me I'm on holiday, with my EJB2.0 spec trying to understand what the hell's going on. Peace and Love, Jules P.S. Be gentle - it's been a hard day... --- marc fleury [EMAIL PROTECTED] wrote: |If they are not optimised, RH currently throws an |exception and the test fails. So this needs fixing. RH is still using the old CL structure for the apps, when we default to the scope stuff, this class of problems will go away, we will need to integrate them with Jetty in teh 2 fashions explained above (actually the rh cl integration native due to teh silly spec requirements). | |I have heard of, but know nothing about, local |interfaces. I would have thought though, that they |must still be constrained by the basic laws of Class |assignability - i.e. if the way the ClassLoaders is that is correct, see my previous mail, orthogonal issues, rickard is sleeping this morning |Anyway, JBoss attempts to implement optimised |intra-container calls through the standard interface. |Are you suggesting we should throw all this code away |now? It would save me a lot of effort. are you kidding? as you know that won't simplify the problem and forcing people to use local stuff in EJB is still weird in my mind. WORA/SMCHORA sentimental bull. |Otherwise this brings us straight back to the same |problem. ClassLoader architecture which is what I need |to coordinate between JBoss and Jetty in order to pass |the testsuite. yes, correct. marcf| |Jules | | | /Rickard | | -- | Rickard Öberg | | |__ |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 | | Yahoo! Groups Sponsor -~-- |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/XwUZwC/MkNDAA/ySSFAA/CefplB/TM |-~- | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ 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: [JBoss-dev] Optimized Servlet-EJB calls.../ Local Interfaces
my understanding of local interfaces is portability in the optimization. Period. It is then heavily used in the 2.0 cmp to enforce collocation of dependencies. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Dain |Sundstrom |Sent: Wednesday, November 21, 2001 11:11 AM |To: 'Julian Gosnell'; [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] Optimized Servlet-EJB calls.../ Local |Interfaces | | | | Now that I've read about Local interfaces, I can see | that they are the natural choice for communications | between beans in the same Container. | | Is it being suggested that I should use these for | servlet/jsp-ejb communication ? | |Yep, but that is in the J2EE spec not the Servlet or ejb specs. | | If not then we still need to support optimized calls | between the web and ejb container. it is these that | fail between Jetty and JBoss. | | If so, then something is wrong. Do I really have to | decide the architecture of my AppServer before I write | my App? It should be transparent. | |The trick is if you think you may want in VM optimized calls you can not |rely on the pass by value style method calls. This means don't use Object |parameters as temp variables. Later on you can switch to Local interfaces |for speed. | |Alternatively, you could start with local interfaces and then switch to |remote if you want to move the web layer to another vm. This has a similar |issue regarding by reference parameters. You can't rely on updated |parameters being reflected in the web layer. | | If optimized calls between web-container and | ejb-container are to be supported, then I still have | ClassLoader issues to be resolved. | |Whey have to be in an EAR with class-path refs properly set in the |manifest.mf file. This is documented in either the J2EE spec or the EJB |spec. | |-dain | |___ |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] Developing with JBoss
In our app, we don't use wars and ears, only jars for our EJBs. Our jsps run off of a directory exposed through Jetty. That way we can easily modify jsps on the fly. Can't see why anybody would use WARS and EARS unless you were shipping a product. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Luke Taylor Sent: Wednesday, November 21, 2001 12:59 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Developing with JBoss Andrew Scherpbier wrote: Rickard Öberg wrote: David Jencks wrote: How would this help in the least? My understanding is that if you use a directory, the dd is checked for time changes For the auto-deployer, yes. I think I'd actually prefer to not use the auto-deployer, and instead make an Ant task that does the deploy command explicitly. Then there's no need to watch dd's or anything. I ran into the same problem and solved it by running Tomcat 4.0 as a separate process during development. Since tomcat works just fine with an already unpacked tree for my webapp, I simply modify my JSPs directly (I have a symbolic link from my webapp development tree to tomcat's webapps directory.) I remember now raising the same sort of issue during the JBoss training in London. I always end up running a separate web container during development because the turnaround of redeploying due to minor jsp changes is just too frustrating. It's not just about the time for the deployment, which is minimal - if you're working on frontend stuff and just essentially modifying web pages, then you lose your whole session state. If you have a complicated web application with security, shopping carts etc, and you're working on the checkout pages, then you have to go through the whole use-case procedure every time you redeploy. If a web container can be configured to pick up the jsp's directly then you only have to reload the page to see a change. The only solution I've found is to run a separate tomcat instance against jboss, with only the web application configured. The full ear is still deployed in jboss as it would be in production. Configuring security for a separate web container is a bit of a drag. The ideal situation would be if an integrated JBoss/Jetty or JBoss/Tomcat could also be configured to use a separately configured web application context during development and have the web coantainer spot modifications to JSPs as above. Dunno if this is feasible, pie in the sky or what ... Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.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-dev] jboss build failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = HERE ARE THE LAST 50 LINES OF THE LOG FILE os.arch: x86 os.version: 2.4.9-12 compile-classes: [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/connector/output/classes [javac] Compiling 48 source files to /disk/orig/home/lubega/jbossro/jboss-all/connector/output/classes /disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/PreparedStatementInPool.java:30: warning: setUnicodeStream(int,java.io.InputStream,int) in java.sql.PreparedStatement has been deprecated public class PreparedStatementInPool extends StatementInPool implements PreparedStatement ^ /disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/PreparedStatementInPool.java:449: warning: setUnicodeStream(int,java.io.InputStream,int) in java.sql.PreparedStatement has been deprecated impl.setUnicodeStream(parameterIndex, x, length); ^ /disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:26: warning: getUnicodeStream(java.lang.String) in java.sql.ResultSet has been deprecated public class ResultSetInPool implements ResultSet ^ /disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:26: warning: getBigDecimal(java.lang.String,int) in java.sql.ResultSet has been deprecated public class ResultSetInPool implements ResultSet ^ /disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:26: warning: getUnicodeStream(int) in java.sql.ResultSet has been deprecated public class ResultSetInPool implements ResultSet ^ /disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:26: warning: getBigDecimal(int,int) in java.sql.ResultSet has been deprecated public class ResultSetInPool implements ResultSet ^ /disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:267: warning: getBigDecimal(int,int) in java.sql.ResultSet has been deprecated return impl.getBigDecimal(arg0, arg1); ^ /disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:318: warning: getBigDecimal(java.lang.String,int) in java.sql.ResultSet has been deprecated return impl.getBigDecimal(arg0, arg1); ^ /disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:1643: warning: getUnicodeStream(int) in java.sql.ResultSet has been deprecated return impl.getUnicodeStream(arg0); ^ /disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:1668: warning: getUnicodeStream(java.lang.String) in java.sql.ResultSet has been deprecated return impl.getUnicodeStream(arg0); ^ /disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/connectionmanager/ManagedConnectionPoolFactory.java:75: cannot resolve symbol symbol : method println (java.lang.String) location: class org.jboss.logging.Logger log.println(Unable to destroy ManagedConnection: +e); ^ 1 error 10 warnings BUILD FAILED /disk/orig/home/lubega/jbossro/jboss-all/connector/build.xml:320: Compile failed, messages should have been provided. Total time: 3 minutes 10 seconds ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Developing with JBoss
David Jencks wrote: Could work, but I'd rather do something portable. Plus, it's non-trivial to break up our app (it's rather monolithic). Plus, several EAR's - several web deployments - several web contexts - no session sharing - no good. You're talking about a non-portable development environment anyway aren't you? Putting pieces of your 1500 jsps in different files might not be so hard??? Yes, I am talking about non-portable development environment. When I'm done, I package an EAR anyway. And no, again, splitting the app into multiple WAR's is Not An Option. ??? Are you proposing to change a copy of the source for the jsp rather than the source?? That's what I thought *you* meant... which would be dumb.. Cmon, you change your jsp in src, deployment of change consists of copying changed file to temp deployment directory?? That's much better, assuming I know where the tmp directory is. And I don't, since the name keeps changing for each deployment. :-( You rebuild from source, you pick up the changes. Only problem I see is automatically finding the correct tmp deploy directory again after redeployment of the whole ear. Exactly. Paaain.. /R -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
|the reason it remains is that most implementations have such |a huge problem getting the class loader scopes to work at |all, that making it configurable is just impossible. |(believe it or not!) look we are going to put it out with Jetty and when you see other vendors starting to support the same, you will know they stole it from here. marcf | |john | | | |Yes, the app programmer needs to know about classloading. Bug.. | |feature.. bug... feature.. which'll it be? :-) | | 100% bug | | |On the one hand, having straight-forward classloading makes it easy to | |develop a web-app. On the other hand, having sandboxed classloading | |makes the web-app more self-contained and portable, since they don't | |rely on the surrounding server to provide any of its classes. | | bullshit | | marcf | | | For the latest information about Jetty, please see http://jetty.mortbay. | | Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | Yahoo! Groups Sponsor -~-- |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/Vv.L9D/MkNDAA/ySSFAA/CefplB/TM |-~- | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Developing with JBoss
|I remember now raising the same sort of issue during the JBoss training |in London. I always end up running a separate web container during Yes I remember, |development because the turnaround of redeploying due to minor jsp |changes is just too frustrating. | |It's not just about the time for the deployment, which is minimal - if |you're working on frontend stuff and just essentially modifying web |pages, then you lose your whole session state. If you have a complicated |web application with security, shopping carts etc, and you're working on |the checkout pages, then you have to go through the whole use-case |procedure every time you redeploy. If a web container can be configured |to pick up the jsp's directly then you only have to reload the page to |see a change. I see |The only solution I've found is to run a separate tomcat instance |against jboss, with only the web application configured. The full ear is |still deployed in jboss as it would be in production. Configuring |security for a separate web container is a bit of a drag. that is a good point |The ideal situation would be if an integrated JBoss/Jetty or |JBoss/Tomcat could also be configured to use a separately configured web |application context during development and have the web coantainer spot |modifications to JSPs as above. Hey Rickard and you both have RW, use it! don't let poor David do all the work. You know what you want, code what you want |Dunno if this is feasible, pie in the sky or what ... sure, marcf | |Luke. | | |-- | Luke Taylor. Monkey Machine Ltd. | PGP Key ID: 0x57E9523Chttp://www.mkeym.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] Classloader puzzle
| |java.lang.ClassNotFoundException: com.titan.cabin.CabinPK | at |org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:372) This is RH CL working on Service libraries, when we integrate the CL and SCL this will go away (or so we hope) really let me finish the proxy rewrite and then I will move onto packaging marcf | at |org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:111) | at java.lang.ClassLoader.loadClass(ClassLoader.java:253) | at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) | at java.lang.Class.forName0(Native Method) | at java.lang.Class.forName(Class.java:195) | at |java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:654) | at |java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:918) | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366) | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) | at |java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186) | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) | at org.jboss.ejb.CacheKey.readExternal(CacheKey.java:118) | at |java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1212) | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) | at |org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker.toObject(IIO |PContainerInvoker.java:896) | at |org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker._invoke(IIOP |ContainerInvoker.java:665) | at |org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:239) | at |org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:456) | at org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:581) | |I've found a way of circumventing the problem, but am not satisfied with |it. Things work if I wrap the PK into a MarshalledObject before embedding |it into the CORBA reference, and do the opposite thing when extracting the |PK from the reference. Runs fine, but is very slow... The bank test takes |forever to run. | |This code is in org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker, |under contrib/iiop. Insertion/extraction of the PK is done through the |methods toByteArray() and toObject(). Each of these methods has two |implementations, one of them commented out. The commented out |implementation solves the problem in the way described above. | |Suggestions are very welcome! | |Cheers, | |Francisco | | | | | | | | |___ |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: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
|When will this new CL stuff come in ? all the code is out, what is missing is SCL/SL integration that david and i are talking about. |Jetty's WAR CL will be a child of the one passed us by |the J2EEDeployer in |Thread.currentThread().getContextClassLoader(). | |What should it's behaviour be ? | |1. DELEGATE up, then look in WAR (Java2 compliant) yes this will work |2. Look in WAR, then DELEGATE up (sandboxing WebApp) if you want this for spec then go and use the RH cl natively once it is built. |3. neither of the above. use 1 for now (our alpha is out) and then move to 2 when we got the stuff done. |1. Optimisation code currently works - but containers |classes are used in preference to WAR's yes, the solution to this is scoped usage in CL |2. WAR's classes used, but optimisation code currently |fails. yes, to me this is more important. |3. ??? | |Now a bit of an ill-informed rant: | |Since using a Remote EJB interface is more restrictive |than using a Local one (everything must be |serialisable) I can guarantee that whilst a Local |interface may not work remotely, a Remote interface |will always work locally... | |Still with me ? | |Therefore, why shouldn't my choice be to always use a |Remote interface if I can, thus keeping all my options |open and why shouldn't JBoss be able to apply exactly |the same optimisations that it would to a local |LocalInterface deployment to my local RemoteInterface |deployment ? correct we will optimize for you, Local stuff really has applications in EJB CMP2.0 but apart from that you don't buy much on JBoss except portability to Weblogic but why would you ? |In fact why do I need a Local interface at all ? my point exactly. Again it enforces colocation which is important in CMP2.0 dumb in web apps. |I don't want the interface to mandate my geographical |location. I want all that done by a hot-pluggable right, you got it. |implementation which will go as fast as it can in any |given deployment scenario. yes which we do. |If anyone wants me I'm on holiday, with my EJB2.0 spec |trying to understand what the hell's going on. | |Peace and Love, yes, case closed, marcf | |Jules | |P.S. | |Be gentle - it's been a hard day... | | --- marc fleury [EMAIL PROTECTED] wrote: |If |they are not optimised, RH currently throws an | |exception and the test fails. So this needs fixing. | | RH is still using the old CL structure for the apps, | when we default to the | scope stuff, this class of problems will go away, we | will need to integrate | them with Jetty in teh 2 fashions explained above | (actually the rh cl | integration native due to teh silly spec | requirements). | | | |I have heard of, but know nothing about, local | |interfaces. I would have thought though, that they | |must still be constrained by the basic laws of | Class | |assignability - i.e. if the way the ClassLoaders | is | | that is correct, see my previous mail, orthogonal | issues, rickard is | sleeping this morning | | |Anyway, JBoss attempts to implement optimised | |intra-container calls through the standard | interface. | |Are you suggesting we should throw all this code | away | |now? It would save me a lot of effort. | | are you kidding? as you know that won't simplify the | problem and forcing | people to use local stuff in EJB is still weird in | my mind. WORA/SMCHORA | sentimental bull. | | |Otherwise this brings us straight back to the same | |problem. ClassLoader architecture which is what I | need | |to coordinate between JBoss and Jetty in order to | pass | |the testsuite. | | yes, correct. | | marcf| | |Jules | | | | | | /Rickard | | | | -- | | Rickard Öberg | | | | | |__ | |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 | | | | Yahoo! Groups Sponsor | | | |For the latest information about Jetty, please see | http://jetty.mortbay. | | | |Your use of Yahoo! Groups is subject to | http://docs.yahoo.com/info/terms/ | | | | | | | ___ | 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 | | Yahoo! Groups Sponsor -~-- |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/1_Y1qC/MkNDAA/ySSFAA/CefplB/TM |-~- | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list
RE: [JBoss-dev] Developing with JBoss
|In our app, we don't use wars and ears, only jars for our EJBs. Our jsps |run off of a directory exposed through Jetty. That way we can |easily modify |jsps on the fly. Can't see why anybody would use WARS and EARS unless you |were shipping a product. this from teh packaging lover of 3 days ago ? ;=) marcf | | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED]]On Behalf Of Luke | Taylor | Sent: Wednesday, November 21, 2001 12:59 PM | To: [EMAIL PROTECTED] | Subject: Re: [JBoss-dev] Developing with JBoss | | | Andrew Scherpbier wrote: | | Rickard Öberg wrote: | | David Jencks wrote: | | How would this help in the least? My understanding is that | if you use a | directory, the dd is checked for time changes | | | For the auto-deployer, yes. I think I'd actually prefer to |not use the | auto-deployer, and instead make an Ant task that does the deploy | command explicitly. Then there's no need to watch dd's or anything. | | | I ran into the same problem and solved it by running Tomcat 4.0 as a | separate process during development. Since tomcat works just |fine with | an already unpacked tree for my webapp, I simply modify my | JSPs directly | (I have a symbolic link from my webapp development tree to tomcat's | webapps directory.) | | | I remember now raising the same sort of issue during the JBoss training | in London. I always end up running a separate web container during | development because the turnaround of redeploying due to minor jsp | changes is just too frustrating. | | It's not just about the time for the deployment, which is minimal - if | you're working on frontend stuff and just essentially modifying web | pages, then you lose your whole session state. If you have a complicated | web application with security, shopping carts etc, and you're working on | the checkout pages, then you have to go through the whole use-case | procedure every time you redeploy. If a web container can be configured | to pick up the jsp's directly then you only have to reload the page to | see a change. | | The only solution I've found is to run a separate tomcat instance | against jboss, with only the web application configured. The full ear is | still deployed in jboss as it would be in production. Configuring | security for a separate web container is a bit of a drag. | | The ideal situation would be if an integrated JBoss/Jetty or | JBoss/Tomcat could also be configured to use a separately configured web | application context during development and have the web coantainer spot | modifications to JSPs as above. | | Dunno if this is feasible, pie in the sky or what ... | | Luke. | | | -- | Luke Taylor. Monkey Machine Ltd. | PGP Key ID: 0x57E9523Chttp://www.mkeym.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
[JBoss-dev] jboss build failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = HERE ARE THE LAST 50 LINES OF THE LOG FILE os.arch: x86 os.version: 2.4.9-12 compile-classes: [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/connector/output/classes [javac] Compiling 48 source files to /disk/orig/home/lubega/jbossro/jboss-all/connector/output/classes /disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/PreparedStatementInPool.java:30: warning: setUnicodeStream(int,java.io.InputStream,int) in java.sql.PreparedStatement has been deprecated public class PreparedStatementInPool extends StatementInPool implements PreparedStatement ^ /disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/PreparedStatementInPool.java:449: warning: setUnicodeStream(int,java.io.InputStream,int) in java.sql.PreparedStatement has been deprecated impl.setUnicodeStream(parameterIndex, x, length); ^ /disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:26: warning: getUnicodeStream(java.lang.String) in java.sql.ResultSet has been deprecated public class ResultSetInPool implements ResultSet ^ /disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:26: warning: getBigDecimal(java.lang.String,int) in java.sql.ResultSet has been deprecated public class ResultSetInPool implements ResultSet ^ /disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:26: warning: getUnicodeStream(int) in java.sql.ResultSet has been deprecated public class ResultSetInPool implements ResultSet ^ /disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:26: warning: getBigDecimal(int,int) in java.sql.ResultSet has been deprecated public class ResultSetInPool implements ResultSet ^ /disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:267: warning: getBigDecimal(int,int) in java.sql.ResultSet has been deprecated return impl.getBigDecimal(arg0, arg1); ^ /disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:318: warning: getBigDecimal(java.lang.String,int) in java.sql.ResultSet has been deprecated return impl.getBigDecimal(arg0, arg1); ^ /disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:1643: warning: getUnicodeStream(int) in java.sql.ResultSet has been deprecated return impl.getUnicodeStream(arg0); ^ /disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:1668: warning: getUnicodeStream(java.lang.String) in java.sql.ResultSet has been deprecated return impl.getUnicodeStream(arg0); ^ /disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/connectionmanager/ManagedConnectionPoolFactory.java:75: cannot resolve symbol symbol : method println (java.lang.String) location: class org.jboss.logging.Logger log.println(Unable to destroy ManagedConnection: +e); ^ 1 error 10 warnings BUILD FAILED /disk/orig/home/lubega/jbossro/jboss-all/connector/build.xml:320: Compile failed, messages should have been provided. Total time: 3 minutes 11 seconds ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Developing with JBoss
-Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 21, 2001 1:50 PM To: [EMAIL PROTECTED]; Luke Taylor; [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Developing with JBoss |In our app, we don't use wars and ears, only jars for our EJBs. Our jsps |run off of a directory exposed through Jetty. That way we can |easily modify |jsps on the fly. Can't see why anybody would use WARS and EARS unless you |were shipping a product. this from teh packaging lover of 3 days ago ? ;=) Doh! I did say, unless you were shipping a product :) marcf | | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED]]On Behalf Of Luke | Taylor | Sent: Wednesday, November 21, 2001 12:59 PM | To: [EMAIL PROTECTED] | Subject: Re: [JBoss-dev] Developing with JBoss | | | Andrew Scherpbier wrote: | | Rickard Öberg wrote: | | David Jencks wrote: | | How would this help in the least? My understanding is that | if you use a | directory, the dd is checked for time changes | | | For the auto-deployer, yes. I think I'd actually prefer to |not use the | auto-deployer, and instead make an Ant task that does the deploy | command explicitly. Then there's no need to watch dd's or anything. | | | I ran into the same problem and solved it by running Tomcat 4.0 as a | separate process during development. Since tomcat works just |fine with | an already unpacked tree for my webapp, I simply modify my | JSPs directly | (I have a symbolic link from my webapp development tree to tomcat's | webapps directory.) | | | I remember now raising the same sort of issue during the JBoss training | in London. I always end up running a separate web container during | development because the turnaround of redeploying due to minor jsp | changes is just too frustrating. | | It's not just about the time for the deployment, which is minimal - if | you're working on frontend stuff and just essentially modifying web | pages, then you lose your whole session state. If you have a complicated | web application with security, shopping carts etc, and you're working on | the checkout pages, then you have to go through the whole use-case | procedure every time you redeploy. If a web container can be configured | to pick up the jsp's directly then you only have to reload the page to | see a change. | | The only solution I've found is to run a separate tomcat instance | against jboss, with only the web application configured. The full ear is | still deployed in jboss as it would be in production. Configuring | security for a separate web container is a bit of a drag. | | The ideal situation would be if an integrated JBoss/Jetty or | JBoss/Tomcat could also be configured to use a separately configured web | application context during development and have the web coantainer spot | modifications to JSPs as above. | | Dunno if this is feasible, pie in the sky or what ... | | Luke. | | | -- | Luke Taylor. Monkey Machine Ltd. | PGP Key ID: 0x57E9523Chttp://www.mkeym.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: [JBoss-dev] Re: [jboss-docs] Is the build system too complicated?
The executable bit is set on tools/bin/ant. Why dosen't your cvs client set
it when you check it out?
--jason
On Wed, 21 Nov 2001 [EMAIL PROTECTED] wrote:
I do have a slightly off-topic gripe -- as of late, (in the rh snapshots),
jboss-all/tools/bin/ant has not been executable on UNIX systems (took my
little mind a while to figure out what was going on). The
jboss-all/build/build.sh script has been failing because of it. It looks
for an executable 'ant', but never finds it (it doesn't have the
executable bit set). I can see three possible solutions:
1. Just have the executable bit set on the ant script to start with
2. Change the search() function in build.sh to read like this:
search() {
search=$*
for d in $search; do
ANT_HOME=`pwd`/$d
ANT=$ANT_HOME/bin/ant
# -- Begin modifications
# If the file exists at all, attempt to add the executable bit
if [ -e $ANT ]; then
`chmod +x $ANT`
fi
# -- End modifications
if [ -x $ANT ]; then
# found one
echo $ANT_HOME
break
fi
done
}
#(just added a -e test to see if the file exists, and attempt to make it
executable so that the next -x test works)
3. Skip looking for an executable ant script -- just make sure it exists,
and call it with 'sh ant'.
-jason
Jason Dillon [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
11/20/2001 09:38 PM
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject:[JBoss-dev] Re: [jboss-docs] Is the build system too
complicated?
I have not found an easy way to provide this common setup/initialization
stuff as a resource. Perhaps if I could tell the JAXP parser to read a
resource file when parsing this could be done, but that would require the
Ant entity hooks to be installed to handle that.
Perhaps they have done that, perhaps I could sway them todo it... though
my
previous attempts to do so has failed (too much *ucking voting).
If you can think of a way please let me know.
Thanks for your feedback!
--jason
On Tue, 20 Nov 2001, David Jencks wrote:
It has often seemed to me that there is substantial duplication between
the
setup parts of the module level build.xml files. I sure haven't figured
out a clue of a way to reduce this, but if it could be done, it might
make
the files a little less intimidating. In light of the vast improvement
over the preceding build system, this is a hardly visible quibble.
david jencks
On 2001.11.20 16:43:07 -0500 Jason Dillon wrote:
Please let me know if you think that the build system is too
complicated,
or
if there is some part of the system which is too complicated.
--jason
---
Subscribe: [EMAIL PROTECTED]
Unsubscribe:[EMAIL PROTECTED]
Archive: http://groups.yahoo.com/group/jboss-docs/
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Sponsor -~--
Universal Inkjet Refill Kit $29.95
Refill any ink cartridge for less!
Includes black and color ink.
http://us.click.yahoo.com/Vv.L9D/MkNDAA/ySSFAA/9rHolB/TM
-~-
---
Subscribe: [EMAIL PROTECTED]
Unsubscribe:[EMAIL PROTECTED]
Archive: http://groups.yahoo.com/group/jboss-docs/
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
___
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] Developing with JBoss
Rickard Öberg wrote: That's much better, assuming I know where the tmp directory is. And I don't, since the name keeps changing for each deployment. :-( Something people have been compaining about roughly forever. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Developing with JBoss
Bill Burke wrote: In our app, we don't use wars and ears, only jars for our EJBs. Our jsps run off of a directory exposed through Jetty. That way we can easily modify jsps on the fly. Can't see why anybody would use WARS and EARS unless you were shipping a product. I've worked in a lot of companies where the production environment was that separated from development - the simpler the package you can hand over the better, since the people who support production environments tend to be on a different planet. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Developing with JBoss
On Wed, 21 Nov 2001, Rickard [ISO-8859-1] Öberg wrote: What I want to avoid is the copying and packaging that goes on. Do you have any idea of the time it takes to package 1500 JSP's into a JAR, and then have that 3-4Mb file copied and exploded into a tmp dir, and this for every time you make a change in a single JSP? Forever I can tell you. It adds up to *a lot* of time each day for just redeployment. This is a problem I believe with ant. It adds/updates ALL input files to the jar, when the rule is called. It should only add/update files that are newer than the jar file. Then the building would be fast. For development, I run jboss locally, and symlink from jboss' deploy dir to my build dir. Then, you are only dealing with the rmdir and unpack stuff, when undeploying/deploying. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [jboss-docs] Is the build system too complicated?
Unfortunately, my firewall currently doesn't let me check out via cvs
directly unless it's over ssh, and I don't have RW access to the
repository (yet :) -- I've been downloading the nightly snapshots (ugh)
in .tgz form from http://www.jboss.org/snapshots/. When I untar that, the
executable bit is not set.(using gnu tar and gzip on linux with the
command 'tar -xzvf jboss-all.tgz`) Actually, from a few spot checks, it
looks as if everything comes out '-rw-r--r--', including build.sh itself.
Yes, I've tried using the -p option with tar to extract permissions
information -- no effect (I think that's the default anyway, though I'm
not sure)
-jason
Jason Dillon [EMAIL PROTECTED]
11/21/2001 02:09 PM
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject:Re: [JBoss-dev] Re: [jboss-docs] Is the build system too
complicated?
The executable bit is set on tools/bin/ant. Why dosen't your cvs client
set
it when you check it out?
--jason
On Wed, 21 Nov 2001 [EMAIL PROTECTED] wrote:
I do have a slightly off-topic gripe -- as of late, (in the rh
snapshots),
jboss-all/tools/bin/ant has not been executable on UNIX systems (took my
little mind a while to figure out what was going on). The
jboss-all/build/build.sh script has been failing because of it. It
looks
for an executable 'ant', but never finds it (it doesn't have the
executable bit set). I can see three possible solutions:
1. Just have the executable bit set on the ant script to start with
2. Change the search() function in build.sh to read like this:
search() {
search=$*
for d in $search; do
ANT_HOME=`pwd`/$d
ANT=$ANT_HOME/bin/ant
# -- Begin modifications
# If the file exists at all, attempt to add the executable bit
if [ -e $ANT ]; then
`chmod +x $ANT`
fi
# -- End modifications
if [ -x $ANT ]; then
# found one
echo $ANT_HOME
break
fi
done
}
#(just added a -e test to see if the file exists, and attempt to make it
executable so that the next -x test works)
3. Skip looking for an executable ant script -- just make sure it
exists,
and call it with 'sh ant'.
-jason
Jason Dillon [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
11/20/2001 09:38 PM
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject:[JBoss-dev] Re: [jboss-docs] Is the build system
too complicated?
I have not found an easy way to provide this common setup/initialization
stuff as a resource. Perhaps if I could tell the JAXP parser to read a
resource file when parsing this could be done, but that would require
the
Ant entity hooks to be installed to handle that.
Perhaps they have done that, perhaps I could sway them todo it... though
my
previous attempts to do so has failed (too much *ucking voting).
If you can think of a way please let me know.
Thanks for your feedback!
--jason
On Tue, 20 Nov 2001, David Jencks wrote:
It has often seemed to me that there is substantial duplication
between
the
setup parts of the module level build.xml files. I sure haven't
figured
out a clue of a way to reduce this, but if it could be done, it might
make
the files a little less intimidating. In light of the vast
improvement
over the preceding build system, this is a hardly visible quibble.
david jencks
On 2001.11.20 16:43:07 -0500 Jason Dillon wrote:
Please let me know if you think that the build system is too
complicated,
or
if there is some part of the system which is too complicated.
--jason
---
Subscribe: [EMAIL PROTECTED]
Unsubscribe:[EMAIL PROTECTED]
Archive: http://groups.yahoo.com/group/jboss-docs/
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Sponsor
-~--
Universal Inkjet Refill Kit $29.95
Refill any ink cartridge for less!
Includes black and color ink.
http://us.click.yahoo.com/Vv.L9D/MkNDAA/ySSFAA/9rHolB/TM
-~-
---
Subscribe: [EMAIL PROTECTED]
Unsubscribe:[EMAIL PROTECTED]
Archive: http://groups.yahoo.com/group/jboss-docs/
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
Re: [JBoss-dev] Re: [jboss-docs] Is the build system too complicated?
I see. Let me see if I can fix the snapshots, else I will fix build.sh.
--jason
On Wed, 21 Nov 2001 [EMAIL PROTECTED] wrote:
Unfortunately, my firewall currently doesn't let me check out via cvs
directly unless it's over ssh, and I don't have RW access to the
repository (yet :) -- I've been downloading the nightly snapshots (ugh)
in .tgz form from http://www.jboss.org/snapshots/. When I untar that, the
executable bit is not set.(using gnu tar and gzip on linux with the
command 'tar -xzvf jboss-all.tgz`) Actually, from a few spot checks, it
looks as if everything comes out '-rw-r--r--', including build.sh itself.
Yes, I've tried using the -p option with tar to extract permissions
information -- no effect (I think that's the default anyway, though I'm
not sure)
-jason
Jason Dillon [EMAIL PROTECTED]
11/21/2001 02:09 PM
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject:Re: [JBoss-dev] Re: [jboss-docs] Is the build system too
complicated?
The executable bit is set on tools/bin/ant. Why dosen't your cvs client
set
it when you check it out?
--jason
On Wed, 21 Nov 2001 [EMAIL PROTECTED] wrote:
I do have a slightly off-topic gripe -- as of late, (in the rh
snapshots),
jboss-all/tools/bin/ant has not been executable on UNIX systems (took my
little mind a while to figure out what was going on). The
jboss-all/build/build.sh script has been failing because of it. It
looks
for an executable 'ant', but never finds it (it doesn't have the
executable bit set). I can see three possible solutions:
1. Just have the executable bit set on the ant script to start with
2. Change the search() function in build.sh to read like this:
search() {
search=$*
for d in $search; do
ANT_HOME=`pwd`/$d
ANT=$ANT_HOME/bin/ant
# -- Begin modifications
# If the file exists at all, attempt to add the executable bit
if [ -e $ANT ]; then
`chmod +x $ANT`
fi
# -- End modifications
if [ -x $ANT ]; then
# found one
echo $ANT_HOME
break
fi
done
}
#(just added a -e test to see if the file exists, and attempt to make it
executable so that the next -x test works)
3. Skip looking for an executable ant script -- just make sure it
exists,
and call it with 'sh ant'.
-jason
Jason Dillon [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
11/20/2001 09:38 PM
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject:[JBoss-dev] Re: [jboss-docs] Is the build system
too complicated?
I have not found an easy way to provide this common setup/initialization
stuff as a resource. Perhaps if I could tell the JAXP parser to read a
resource file when parsing this could be done, but that would require
the
Ant entity hooks to be installed to handle that.
Perhaps they have done that, perhaps I could sway them todo it... though
my
previous attempts to do so has failed (too much *ucking voting).
If you can think of a way please let me know.
Thanks for your feedback!
--jason
On Tue, 20 Nov 2001, David Jencks wrote:
It has often seemed to me that there is substantial duplication
between
the
setup parts of the module level build.xml files. I sure haven't
figured
out a clue of a way to reduce this, but if it could be done, it might
make
the files a little less intimidating. In light of the vast
improvement
over the preceding build system, this is a hardly visible quibble.
david jencks
On 2001.11.20 16:43:07 -0500 Jason Dillon wrote:
Please let me know if you think that the build system is too
complicated,
or
if there is some part of the system which is too complicated.
--jason
---
Subscribe: [EMAIL PROTECTED]
Unsubscribe:[EMAIL PROTECTED]
Archive: http://groups.yahoo.com/group/jboss-docs/
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Sponsor
-~--
Universal Inkjet Refill Kit $29.95
Refill any ink cartridge for less!
Includes black and color ink.
http://us.click.yahoo.com/Vv.L9D/MkNDAA/ySSFAA/9rHolB/TM
-~-
---
Subscribe: [EMAIL PROTECTED]
Unsubscribe:[EMAIL PROTECTED]
Archive: http://groups.yahoo.com/group/jboss-docs/
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
[JBoss-dev] CVS update: jbosscx/src/main/org/jboss/resource/connectionmanager ManagedConnectionPoolFactory.java
User: starksm
Date: 01/11/21 11:41:16
Modified:src/main/org/jboss/resource/connectionmanager
ManagedConnectionPoolFactory.java
Log:
Fix the bad check-in by thedug
Revision ChangesPath
1.4 +9 -5
jbosscx/src/main/org/jboss/resource/connectionmanager/ManagedConnectionPoolFactory.java
Index: ManagedConnectionPoolFactory.java
===
RCS file:
/cvsroot/jboss/jbosscx/src/main/org/jboss/resource/connectionmanager/ManagedConnectionPoolFactory.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ManagedConnectionPoolFactory.java 2001/11/21 18:14:51 1.3
+++ ManagedConnectionPoolFactory.java 2001/11/21 19:41:16 1.4
@@ -68,14 +68,18 @@
* object will not be returned to the pool - after this, it is gone. This
* is called when the pool shrinks, and when the pool is shut down.
*/
-public void deleteObject(Object pooledObject) {
-try{
+public void deleteObject(Object pooledObject)
+{
+try
+{
((ManagedConnection)pooledObject).destroy();
-}catch(ResourceException e) {
-log.println(Unable to destroy ManagedConnection: +e);
}
+catch(ResourceException e)
+{
+log.error(Unable to destroy ManagedConnection: , e);
+}
- }
+ }
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jbosscx/src/main/org/jboss/resource/connectionmanager ManagedConnectionPoolFactory.java
Sorry,
I was merging a change I made to 2.4 and didn't realize the log method had
changed.
Also, I noticed that you changed formatting. Does JBoss enforce coding
standards in
regards to formatting? If so, where can I find this information?
Thanks,
d.
-Original Message-
From: Scott M Stark [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 21, 2001 1:41 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] CVS update:
jbosscx/src/main/org/jboss/resource/connectionmanager
ManagedConnectionPoolFactory.java
User: starksm
Date: 01/11/21 11:41:16
Modified:src/main/org/jboss/resource/connectionmanager
ManagedConnectionPoolFactory.java
Log:
Fix the bad check-in by thedug
Revision ChangesPath
1.4 +9 -5
jbosscx/src/main/org/jboss/resource/connectionmanager/ManagedConnectionPoolF
actory.java
Index: ManagedConnectionPoolFactory.java
===
RCS file:
/cvsroot/jboss/jbosscx/src/main/org/jboss/resource/connectionmanager/Managed
ConnectionPoolFactory.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ManagedConnectionPoolFactory.java 2001/11/21 18:14:51 1.3
+++ ManagedConnectionPoolFactory.java 2001/11/21 19:41:16 1.4
@@ -68,14 +68,18 @@
* object will not be returned to the pool - after this, it is gone.
This
* is called when the pool shrinks, and when the pool is shut down.
*/
-public void deleteObject(Object pooledObject) {
-try{
+public void deleteObject(Object pooledObject)
+{
+try
+{
((ManagedConnection)pooledObject).destroy();
-}catch(ResourceException e) {
-log.println(Unable to destroy ManagedConnection: +e);
}
+catch(ResourceException e)
+{
+log.error(Unable to destroy ManagedConnection: , e);
+}
- }
+ }
___
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] CVS update: jbosscx/src/main/org/jboss/resource/connectionmanager ManagedConnectionPoolFactory.java
Standards are here:
http://www.jboss.org/developers/guide/codestyle.jsp
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Ferguson, Doug [EMAIL PROTECTED]
To: 'Scott M Stark' [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Wednesday, November 21, 2001 12:15 PM
Subject: RE: [JBoss-dev] CVS update:
jbosscx/src/main/org/jboss/resource/connectionmanager
ManagedConnectionPoolFactory.java
Sorry,
I was merging a change I made to 2.4 and didn't realize the log method had
changed.
Also, I noticed that you changed formatting. Does JBoss enforce coding
standards in
regards to formatting? If so, where can I find this information?
Thanks,
d.
-Original Message-
From: Scott M Stark [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 21, 2001 1:41 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] CVS update:
jbosscx/src/main/org/jboss/resource/connectionmanager
ManagedConnectionPoolFactory.java
User: starksm
Date: 01/11/21 11:41:16
Modified:src/main/org/jboss/resource/connectionmanager
ManagedConnectionPoolFactory.java
Log:
Fix the bad check-in by thedug
Revision ChangesPath
1.4 +9 -5
jbosscx/src/main/org/jboss/resource/connectionmanager/ManagedConnectionPoolF
actory.java
Index: ManagedConnectionPoolFactory.java
===
RCS file:
/cvsroot/jboss/jbosscx/src/main/org/jboss/resource/connectionmanager/Managed
ConnectionPoolFactory.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ManagedConnectionPoolFactory.java 2001/11/21 18:14:51 1.3
+++ ManagedConnectionPoolFactory.java 2001/11/21 19:41:16 1.4
@@ -68,14 +68,18 @@
* object will not be returned to the pool - after this, it is
gone.
This
* is called when the pool shrinks, and when the pool is shut
down.
*/
-public void deleteObject(Object pooledObject) {
-try{
+public void deleteObject(Object pooledObject)
+{
+try
+{
((ManagedConnection)pooledObject).destroy();
-}catch(ResourceException e) {
-log.println(Unable to destroy ManagedConnection: +e);
}
+catch(ResourceException e)
+{
+log.error(Unable to destroy ManagedConnection: , e);
+}
- }
+ }
___
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-dev] Review the coding standards
The main branch code is getting screwed up again with a mixuture of coding styles. Review the JBoss standards and use them to avoid getting your code reformatted: http://www.jboss.org/developers/guide/codestyle.jsp Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Classloader puzzle
Hi, On Wed, 21 Nov 2001, marc fleury wrote: | |java.lang.ClassNotFoundException: com.titan.cabin.CabinPK | at |org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:372) This is RH CL working on Service libraries, when we integrate the CL and SCL this will go away (or so we hope) Hope it will go away, but am not that sure... This problem is around since I started doing the IIOP stuff. It (and the MarshalledObject workaround) precedes RH. Regards, Francisco really let me finish the proxy rewrite and then I will move onto packaging marcf | at |org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:111) | at java.lang.ClassLoader.loadClass(ClassLoader.java:253) | at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) | at java.lang.Class.forName0(Native Method) | at java.lang.Class.forName(Class.java:195) | at |java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:654) | at |java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:918) | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366) | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) | at |java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186) | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) | at org.jboss.ejb.CacheKey.readExternal(CacheKey.java:118) | at |java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1212) | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) | at |org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker.toObject(IIO |PContainerInvoker.java:896) | at |org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker._invoke(IIOP |ContainerInvoker.java:665) | at |org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:239) | at |org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:456) | at org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:581) | |I've found a way of circumventing the problem, but am not satisfied with |it. Things work if I wrap the PK into a MarshalledObject before embedding |it into the CORBA reference, and do the opposite thing when extracting the |PK from the reference. Runs fine, but is very slow... The bank test takes |forever to run. | |This code is in org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker, |under contrib/iiop. Insertion/extraction of the PK is done through the |methods toByteArray() and toObject(). Each of these methods has two |implementations, one of them commented out. The commented out |implementation solves the problem in the way described above. | |Suggestions are very welcome! | |Cheers, | |Francisco | | | | | | | | |___ |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
[JBoss-dev] CVS update: newsite/src/docs main.css
User: user57
Date: 01/11/21 12:41:47
Modified:src/docs main.css
Log:
o changed code, command and output styles to use 12px for fonts
Revision ChangesPath
1.9 +2 -4 newsite/src/docs/main.css
Index: main.css
===
RCS file: /cvsroot/jboss/newsite/src/docs/main.css,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- main.css 2001/11/21 03:21:08 1.8
+++ main.css 2001/11/21 20:41:47 1.9
@@ -2,7 +2,7 @@
* CSS Style Sheet for the JBoss website.
*/
-/* $Id: main.css,v 1.8 2001/11/21 03:21:08 user57 Exp $ */
+/* $Id: main.css,v 1.9 2001/11/21 20:41:47 user57 Exp $ */
BODY {
font-family: Arial,serif;
@@ -129,21 +129,19 @@
border-style: solid;
padding: 5px;
font-family: monospace;
+ font-size: 12px;
}
.code {
color: #00ff55;
- font-size: 10px;
}
.command {
color: #ffee00;
- font-size: 13px;
}
.output {
color: #ee;
- font-size: 10px;
}
.red {
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs binary.jsp
User: starksm Date: 01/11/21 13:13:48 Modified:src/docs binary.jsp Log: Add a link to the 3.0 alpha. Revision ChangesPath 1.14 +10 -6 newsite/src/docs/binary.jsp Index: binary.jsp === RCS file: /cvsroot/jboss/newsite/src/docs/binary.jsp,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- binary.jsp2001/11/07 19:55:36 1.13 +++ binary.jsp2001/11/21 21:13:48 1.14 @@ -1,3 +1,4 @@ + jsp:include page=head.jsp flush=true / jsp:include page=slogan.jsp flush=true jsp:param name=SLOGAN value=BINARIES/ @@ -43,11 +44,17 @@ p class=headJBoss 2.4p p class=text - -table border=0 + + table border=0 trth align=leftp class=textPackages/ththp class=textnbsp;nbsp;nbsp;Sizenbsp;nbsp;nbsp;/ththp class=textDate/th/tr tr +tda class=link href=http://prdownloads.sourceforge.net/jboss/jboss-3.0.0alpha.zip;JBoss-3.0.0.zip alpha/a/td +td align=rightp class=text9951882/td +td align=centerp class=textNovember 21, 2001/td + /tr +trth colspan=3 bgcolor=#008000/th/tr + tr tda class=link href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.3.zip;JBoss-2.4.3.zip/a/td td align=rightp class=text6125514/td td align=centerp class=textOctober 3, 2001/td @@ -67,10 +74,7 @@ td align=rightp class=text10512966/td td align=centerp class=textOctober 30, 2001/td /tr -/table - - hr -table border=0 +trth colspan=3 bgcolor=#008000/th/tr tr tda class=link href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.1.zip;JBoss-2.4.1.zip/a/td td align=rightp class=text8379911/td ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
On 2001.11.21 13:16:11 -0500 marc fleury wrote: Sanity, thanks professor seems you are on shore with me for once :) | Regardless, I'm going to work on the deployment layer to clean it up | and add support unarchived ears. | |I the likely case you get to this before I do, my goals for j2ee and other |deployment are: | | |- Unify the ServiceLibraries and the Scoped Classloader and always use the |result. correct. I will do it if you don't. |- Separate deployment into |--autodeploy detection. This will watch directories and on timestamp change |undeploy and redeploy. | |-Universal deployer. This will |--determine which classloader to use (system (now ServiceLibraries) or |application (now Scoped), but these should use the same code base). This |may turn into your idea of virtual host. Yes, good how are you going to do that? (not completely worked out yet) I think every jboss dd could include a scope (or virtual host) attribute at its top level. If something comes in as a subpackage of something with an explicit scope (ejb-jar or rar or sar in ear), it goes in the same scope. If the scope is missing, if it is a sar or rar, it goes in the system scope, otherwise it gets its own private uniquely named scope. how about just moving the scl to sl? scl = scoped classloader sl = service libraries? the only problem there is the ordering of lookups which I think differs significantly but... we can look at using one structure. If we always set the SL as parent to teh scl then I don't think we need to hint anything. I wondered, I haven't had the time to try this. |--put all accessible classes from the packaging into the extensible |classloader (I'd use extractPackages from DeployerMBeanSupport) woot? what is this? I'm not an expert on this. Looking (quickly) at the j2ee deployer, it looked to me as if there was a lot of effort expended to trace various manifest classpaths etc etc. What would happen if we just put everything in the package (ear, sar, rar, whatever) in one (jboss) URLClassloader? I don't understand what these internal dependency indications are for or the consequences of ignoring them. It might as well go in one classloader, you can't redeploy embedded pieces of a deployment unit anyway. For instance, in the jar in sar, you can now have a sar with a directory structure with classes in it, plus a bunch of jars in it. This gets unpacked into a copy of the original sar, plus copies of the jars unpacked out of the sar. One (JBoss) URLClassloader handles all of them. Would there be any problems doing this for an ear? I asked a few weeks ago and no one answered. |--Figure out what order to process the xml dd files, discovered in the |previous step. |--Feed the xml files to the appropriate deployers in the appropriate order. | |-individual deployers (Service, RAR, ContainerFactory, J2ee, etc) |--these will now only process the (xml) dd. yes, good |-A new deployer for deployment scripts that basically contain an ordered |list of other things that can be deployed. Although in principal I think |all dependencies should be stated explicitly, a script facility would allow |deployment of units in a specified order rather than relying on the random |order of detection by autodeployer. | |Any thoughts? Excellent, some sanity finally, excellent professor, excellent. |David Jencks marcf thanks david jencks | snip ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Developing with JBoss
On 2001.11.21 14:06:58 -0500 danch wrote: Rickard Öberg wrote: That's much better, assuming I know where the tmp directory is. And I don't, since the name keeps changing for each deployment. :-( Something people have been compaining about roughly forever. I think there are possible problems with trying to always use the same temp dir -- for instance you might have problems removing the old copy before you wanted to start the new one. We might be able to cook up some crazy really hot redeploy whereby the new version is started before the old one is stopped, allowing the requests in process in the old version to complete while new requests go to the new version. What if we made the location of the temp dir visible through an mbean representing the deployment? You could have a little ant task to ask where the war went. david jencks ___ 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-dev] CVS update: newsite/src/docs main.css navigation.jsp slogan.jsp
User: user57
Date: 01/11/21 13:47:32
Modified:src/docs main.css navigation.jsp slogan.jsp
Log:
o truncated quickstart output examples a bit more to make the page a bit
more readable
o changed [Printable Version] to [Print] and added [Send To Printer] on
pritable page
o only using em/em on the faq section when terms are most notibly
described
o changed the main style sheet to use relative font sizes (except for
menu and slogan) so that browsers can correctly adujst them to the
users preferences (making the text bigger or smaller)
* Note: The general text size is a touch larger than before, but is really
close to the harded coded 13px and seems to look ok on IE and Mozilla and
even in Konqueror, which never seemed to look good at all)
Revision ChangesPath
1.10 +20 -48newsite/src/docs/main.css
Index: main.css
===
RCS file: /cvsroot/jboss/newsite/src/docs/main.css,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- main.css 2001/11/21 20:41:47 1.9
+++ main.css 2001/11/21 21:47:32 1.10
@@ -2,16 +2,15 @@
* CSS Style Sheet for the JBoss website.
*/
-/* $Id: main.css,v 1.9 2001/11/21 20:41:47 user57 Exp $ */
+/* $Id: main.css,v 1.10 2001/11/21 21:47:32 user57 Exp $ */
BODY {
font-family: Arial,serif;
- font-size: 13px;
+ font-size: 0.9em;
color: #00;
}
P, DIV, TBODY, TD, LI, DD {
- font-size: 13px;
color: #00;
}
@@ -33,49 +32,49 @@
clear: both;
font-weight: bold;
font-variant: small-caps;
- letter-spacing: 0.1em;
+ letter-spacing: 0.05em;
}
H1 {
- font-size: 15px;
+ font-size: 1.4em;
}
H2 {
- font-size: 15px;
+ font-size: 1.3em;
}
H3 {
- font-size: 14px;
+ font-size: 1.2em;
}
H4 {
- font-size: 13px;
+ font-size: 1.1em;
}
H5 {
padding-top: 5px;
- font-size: 13px;
+ font-size: 1.0em;
font-weight: normal;
letter-spacing: normal;
}
H6 {
padding-top: 5px;
- font-size: 13px;
+ font-size: 1.0em;
font-variant: normal;
font-weight: normal;
letter-spacing: normal;
}
-.linkhead {
+.linkhead, .linkmenu {
font-size: 12px;
- color: #ff;
font-weight: bold;
}
+.linkhead {
+ color: #ff;
+}
.linkmenu {
- font-size: 12px;
color: #0a0a0a;
- font-weight: bold;
text-decoration: none;
}
.linkmenu:hover {
@@ -84,34 +83,21 @@
}
.head {
- font-size: 14px;
+ font-size: 1.3em;
color: #336633;
font-weight: bold;
- padding-top: 1px;
}
.slogan {
- font-size: 15px;
- color: #338833;
- font-weight: bold;
-}
-
-.text {
- font-size: 13px;
- color: #00;
-}
-
-.link {
- font-size: 13px;
- color: #003399;
+ font-size: 15px;
font-weight: bold;
-}
-.link:hover {
- color: #336633;
+ font-variant: small-caps;
+ letter-spacing: 0.05em;
+ color: #338833;
}
.copy {
- font-size: 11px;
+ font-size: 0.7em;
color: #808080;
}
.copy:hover {
@@ -129,7 +115,7 @@
border-style: solid;
padding: 5px;
font-family: monospace;
- font-size: 12px;
+ font-size: 0.8em;
}
.code {
@@ -147,17 +133,3 @@
.red {
color: red;
}
-
-/* Old stuff we keep around for reference */
-
-a.menu { color: black; text-decoration: none }
-td.black { background-color: #00 }
-td.dark { background-color: #276561 }
-td.light { background-color: #307d77 }
-td.link { font-family: Arial,serif; font-size: 13px; color: #404040; font-weight:
bold; }
-td.newsbody { font-family: Arial,serif; font-size: 13px; color: #00}
-td.newsheader {font-family: Arial,serif; font-size: 14px; color: #336633;
font-weight: bold; }
-/*td.newsheader { color: black; background-color: #C1E0B2 }*/
-td.pageheader { color: white; font-weight: bold; font-size: 14pt; background-color:
#99 }
-td.yellow { background-color: #f4c641 }
-span.red { color: red; font-weight: bold }
1.16 +2 -2 newsite/src/docs/navigation.jsp
Index: navigation.jsp
===
RCS file: /cvsroot/jboss/newsite/src/docs/navigation.jsp,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- navigation.jsp2001/11/21 03:21:08 1.15
+++ navigation.jsp2001/11/21 21:47:32 1.16
@@ -51,7 +51,7 @@
td bgcolor=#ffcc00
table cellspacing=0 cellpadding=0 border=0
trtd width=110 height=16 bgcolor=#c6b80bp class=linkhead
- a class=linkhead href=/HOME/a
+ HOME
[JBoss-dev] CVS update: newsite/src/docs/developers cvs.jsp navigation.jsp slogan.jsp
User: user57
Date: 01/11/21 13:47:33
Modified:src/docs/developers cvs.jsp navigation.jsp slogan.jsp
Log:
o truncated quickstart output examples a bit more to make the page a bit
more readable
o changed [Printable Version] to [Print] and added [Send To Printer] on
pritable page
o only using em/em on the faq section when terms are most notibly
described
o changed the main style sheet to use relative font sizes (except for
menu and slogan) so that browsers can correctly adujst them to the
users preferences (making the text bigger or smaller)
* Note: The general text size is a touch larger than before, but is really
close to the harded coded 13px and seems to look ok on IE and Mozilla and
even in Konqueror, which never seemed to look good at all)
Revision ChangesPath
1.14 +1 -4 newsite/src/docs/developers/cvs.jsp
Index: cvs.jsp
===
RCS file: /cvsroot/jboss/newsite/src/docs/developers/cvs.jsp,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- cvs.jsp 2001/11/21 03:21:09 1.13
+++ cvs.jsp 2001/11/21 21:47:33 1.14
@@ -1,12 +1,9 @@
jsp:include page=head.jsp flush=true/
-!-- $Id: cvs.jsp,v 1.13 2001/11/21 03:21:09 user57 Exp $ --
jsp:include page=slogan.jsp flush=true
jsp:param name=SLOGAN value=SOURCE CODE AND CVS/
/jsp:include
-!-- CONTENT --
-
-h2JBoss is Developed Publicly/h2
+!-- $Id: cvs.jsp,v 1.14 2001/11/21 21:47:33 user57 Exp $ --
jsp:include page=/common/picateam.jsp flush=true/
1.13 +2 -2 newsite/src/docs/developers/navigation.jsp
Index: navigation.jsp
===
RCS file: /cvsroot/jboss/newsite/src/docs/developers/navigation.jsp,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- navigation.jsp2001/11/21 03:21:09 1.12
+++ navigation.jsp2001/11/21 21:47:33 1.13
@@ -52,7 +52,7 @@
td bgcolor=#ffcc00
table cellspacing=0 cellpadding=0 border=0
trtd width=110 height=16 bgcolor=#313184p class=linkhead
- a class=linkhead href=/HOME/a
+ HOME
/td/tr/table
a class=linkmenu href=/developers/vision.jspOurnbsp;Visionsupfont
color=red New/font/sup/abr
a class=linkmenu href=/developers/index.jspFornbsp;Developers/abr
@@ -165,7 +165,7 @@
% } else { // if printable %
hr
-p[a href=%= request.getRequestURI() %Normal Version/a]
+p[a href=javascript:history.go(-1)Back/a]
[a href=#TOPTop/a]
/div
1.4 +3 -2 newsite/src/docs/developers/slogan.jsp
Index: slogan.jsp
===
RCS file: /cvsroot/jboss/newsite/src/docs/developers/slogan.jsp,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- slogan.jsp2001/11/21 03:21:09 1.3
+++ slogan.jsp2001/11/21 21:47:33 1.4
@@ -11,7 +11,7 @@
img src=/pictures/cog1.gif width=44 height=13 align=absmiddle
%= request.getParameter(SLOGAN) %
img src=/pictures/cog2.gif width=44 height=13
align=absmiddle/td
- td align=right[a class=copy href=?printable=truePrintable
Version/a]/td/tr/table
+ td align=right[a class=copy
href=?printable=truePrint/a]/td/tr/table
/td
td width=65img src=/pictures/main3.gif width=65 height=20/td
/tr
@@ -31,7 +31,8 @@
h1 class=slogan%= request.getParameter(SLOGAN) %/h1
/td
td align=right
- [a href=%= request.getRequestURI() %Normal Version/a]
+ [a href=javascript:history.go(-1)Back/a]
+ [a href=javascript:window.print()Send To Printer/a]
/td
/tr
/table
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs/developers/guide buildsystem-faq.jsp quickstart.jsp
User: user57 Date: 01/11/21 13:47:33 Modified:src/docs/developers/guide buildsystem-faq.jsp quickstart.jsp Log: o truncated quickstart output examples a bit more to make the page a bit more readable o changed [Printable Version] to [Print] and added [Send To Printer] on pritable page o only using em/em on the faq section when terms are most notibly described o changed the main style sheet to use relative font sizes (except for menu and slogan) so that browsers can correctly adujst them to the users preferences (making the text bigger or smaller) * Note: The general text size is a touch larger than before, but is really close to the harded coded 13px and seems to look ok on IE and Mozilla and even in Konqueror, which never seemed to look good at all) Revision ChangesPath 1.4 +17 -8 newsite/src/docs/developers/guide/buildsystem-faq.jsp Index: buildsystem-faq.jsp === RCS file: /cvsroot/jboss/newsite/src/docs/developers/guide/buildsystem-faq.jsp,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- buildsystem-faq.jsp 2001/11/21 07:16:57 1.3 +++ buildsystem-faq.jsp 2001/11/21 21:47:33 1.4 @@ -1,16 +1,23 @@ jsp:include page=/developers/head.jsp flush=true/ -!-- $Id: buildsystem-faq.jsp,v 1.3 2001/11/21 07:16:57 user57 Exp $ -- jsp:include page=/developers/slogan.jsp flush=true jsp:param name=SLOGAN value=BUILD SYSTEM FAQ/ /jsp:include -!-- -- +!-- $Id: buildsystem-faq.jsp,v 1.4 2001/11/21 21:47:33 user57 Exp $ -- jsp:include page=/common/picateam.jsp flush=true/ -pFind the answers to the most frequently asked questions about the +pFind the answers to the most frequently asked questions (FAQ) about the build system here. +pThis is a work in progress, so you might not find the exact question or + rather answer that you were looking for. If you have a question which + you believe should be listed here, please send us some + a href=mailto:[EMAIL PROTECTED];email/a letting us know. + +pIf you are looking for a more compresensive document about the build + system check out the a href=buildsystem.jspBuild System Guide/a. + br clear=all !-- -- @@ -19,7 +26,7 @@ pul lia href=#Ant_directlyWhy can't I use ttant/tt directly?/a - lia href=#What_are_HooksWhat are emhooks/em?/a + lia href=#What_are_HooksWhat are hooks?/a /ul !-- -- @@ -48,7 +55,7 @@ p[a href=#ContentsContents/a] -h2a name=What_are_Hooks/aWhat are emhooks/em?/h2 +h2a name=What_are_Hooks/aWhat are hooks?/h2 pIf you have looked through a ttbuild/build.xml/tt file, you may have noticed a section dealing with module hooks. Just what are those hooks @@ -67,7 +74,7 @@ actions when those modules were actually exectute, or rather emonly/em when they are executed. In comes module emhooks/em. -pemHooks/em are simply targets named in a specific fasion which will +pHooks are simply targets named in a specific fasion which will be executed before and/or after the module is executed (as specified by the module executor... the bit which executes the list modules, and the existance of the target as specified by the hook naming convention). @@ -81,6 +88,8 @@ by the user. This is used to only pull the files which were actually generated by the current module execution. +jsp:include page=/common/picateam.jsp flush=true/ + pFor example, consider the difference between the ttall/tt and ttmost/tt targets. The first should generate all of the possible files that a module has to offer, while the latter should only generate @@ -105,12 +114,12 @@ pWith any luck that all makes sense to you now. If now just remeber that emhooks/em are used to empull/em output from modules and generated the release structure for a project. For each module that exists in a - project and generates output, emhooks/em should be defined in the + project and generates output, hooks should be defined in the projects ttbuild/build.xml/tt file which copy the generated files from module to project output. pIf you are a adding support for a new module, or changing an existing - emhook/em, please make sure that you test all of the targets which + hook, please make sure that you test all of the targets which will trigger the hook to be called before commiting the changes. Your fellow developers will appreciate the extra time you took to test that everything works... even if they don't show it =)
[JBoss-dev] CVS update: jboss/src/resources/org/jboss/metadata jbosscmp-jdbc.dtd
User: d_jencks Date: 01/11/21 14:01:30 Added: src/resources/org/jboss/metadata jbosscmp-jdbc.dtd Log: DTD for jboss cmp2 with jdbc. This seems to match what the code does pretty well, but should be considered preliminary. Revision ChangesPath 1.1 jboss/src/resources/org/jboss/metadata/jbosscmp-jdbc.dtd Index: jbosscmp-jdbc.dtd === ?xml version='1.0' encoding='UTF-8' ? !-- This is the XML DTD for the jbosscmp-jdbc deployment descriptor. !DOCTYPE jaws PUBLIC -//JBoss//DTD jbosscmp-jdbc//EN http://www.jboss.org/j2ee/dtd/jbosscmp-jdbc.dtd; -- !--jbosscmp-jdbc -- !--Top level element for jboss cmp2 for jdbc datasources-- !ELEMENT jbosscmp-jdbc (defaults, (enterprise-beans, relationships?, dependent-value-classes?)?) !--defaults -- !--Default values for many entity bean settings -- !ELEMENT defaults (datasource, debug, create-table, remove-table, tuned-updates, read-only, time-out, select-for-update, pk-constraint, relation-mapping-style) !--datasource -- !--datasource for connections to underlying persistent store. -- !ELEMENT datasource (#PCDATA) !--debug -- !--Turns on sql logging -- !ELEMENT debug(#PCDATA) !--create-table -- !--Should the persistence manager attempt to create tables if they are not present? (true/false) -- !ELEMENT create-table (#PCDATA) !--remove-table -- !--Should the persistence manager attempt to remove tables on shutdown? (true/false)-- !ELEMENT remove-table (#PCDATA) !--tuned-updates -- !--Should the persistence manager include only modified fields in update statements? (true/false) -- !ELEMENT tuned-updates (#PCDATA) !--read-only -- !--Is the bean read-only? (true/false)-- !ELEMENT read-only(#PCDATA) !--time-out -- !--Timeout value for connection activity (milliseconds).-- !ELEMENT time-out (#PCDATA) !--select-for-update -- !--Should select statements lock using select for update? (true/false) -- !ELEMENT select-for-update (#PCDATA) !--pk-constraint -- !--Should the persistence manager generate primary keys for generated tables? (true/false) -- !ELEMENT pk-constraint(#PCDATA) !--relation-mapping-style -- !--Relation mapping style (foreign-key/??)-- !ELEMENT relation-mapping-style (#PCDATA) !--enterprise-beans -- !--Element containing all enterprise beans for cmp-2 -- !ELEMENT enterprise-beans (entity*) !--entity -- !--Metadata for one entity bean -- !ELEMENT entity
Re: [JBoss-dev] Classloader puzzle
It sure looks like the system (Service libraries) rather than application classloader is being used, despite your code that clearly sets the contextClassLoader to the container's. Have you checked that poaCurrent doesn't change the context classloader and the classloader is really what you expect when you call toObject? david jencks On 2001.11.21 13:04:25 -0500 Francisco Reverbel wrote: Hi, I have a classloader problem in the IIOP container invoker code and would really appreciate some helpful hints... Classloader wizards: to understand the problem you do not have to know anything about CORBA/IIOP, so please read on! The problem only shows up with entity beans. When the IIOP container invoker creates a CORBA reference for such a bean, it embeds the bean´s primary key into the CORBA reference. When handling a bean invocation, the container invoker extracts the PK from the CORBA reference and passes this PK to the container as the first argument of a MethodInvocation. A ClassNotFoundException is thrown when the container invoker attempts to extract the PK from the CORBA reference (got the stack trace below running RMH's well-known cabin bean): java.lang.ClassNotFoundException: com.titan.cabin.CabinPK at org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:372) at org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:111) at java.lang.ClassLoader.loadClass(ClassLoader.java:253) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:195) at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:654) at java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:918) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at org.jboss.ejb.CacheKey.readExternal(CacheKey.java:118) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1212) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker.toObject(IIOPContainerInvoker.java:896) at org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker._invoke(IIOPContainerInvoker.java:665) at org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:239) at org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:456) at org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:581) I've found a way of circumventing the problem, but am not satisfied with it. Things work if I wrap the PK into a MarshalledObject before embedding it into the CORBA reference, and do the opposite thing when extracting the PK from the reference. Runs fine, but is very slow... The bank test takes forever to run. This code is in org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker, under contrib/iiop. Insertion/extraction of the PK is done through the methods toByteArray() and toObject(). Each of these methods has two implementations, one of them commented out. The commented out implementation solves the problem in the way described above. Suggestions are very welcome! Cheers, Francisco ___ 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-dev] CVS update: website-snapshots build.xml
User: user57
Date: 01/11/21 14:42:36
Modified:.build.xml
Log:
o HACKED the build file to make all 'build.sh' and
'tools/bin/ant[Run]' files executable.
! I don't really like it, but don't have much choice. Thanks SUN!
Revision ChangesPath
1.2 +41 -17website-snapshots/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/website-snapshots/build.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- build.xml 2001/11/20 00:42:20 1.1
+++ build.xml 2001/11/21 22:42:35 1.2
@@ -10,7 +10,7 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.1 2001/11/20 00:42:20 user57 Exp $ --
+!-- $Id: build.xml,v 1.2 2001/11/21 22:42:35 user57 Exp $ --
project default=main name=JBoss Website/Snapshots
@@ -264,9 +264,9 @@
echoExporting CVS modules for snaphots.../echo
-!-- Make sure there is an entry for this cvsroot --
+ !-- Make sure there is an entry for this cvsroot --
- cvspass cvsroot=${snapshot.cvsroot} password=/
+ cvspass cvsroot=${snapshot.cvsroot} password=/
cvs cvsroot=${snapshot.cvsroot}
command=-Q -r -f -z3 export
date=TODAY
@@ -291,10 +291,18 @@
!-- build jboss-all.tgz --
-tar tarfile=${build.snapshots}/jboss-all.tar
- longfile=gnu
- basedir=${build.snapshots.tmp}
- includes=jboss-all/**
+tar tarfile=${build.snapshots}/jboss-all.tar longfile=gnu
+ tarfileset dir=${build.snapshots.tmp} mode=655
+include name=jboss-all/**/build.sh/
+include name=jboss-all/**/tools/bin/ant/
+include name=jboss-all/**/tools/bin/antRun/
+ /tarfileset
+ tarfileset dir=${build.snapshots.tmp} mode=644
+include name=jboss-all/**/
+exclude name=jboss-all/**/build.sh/
+exclude name=jboss-all/**/tools/bin/ant/
+exclude name=jboss-all/**/tools/bin/antRun/
+ /tarfileset
/tar
gzip src=${build.snapshots}/jboss-all.tar
zipfile=${build.snapshots}/jboss-all.tgz/
@@ -309,27 +317,43 @@
!-- build jboss-mq.tgz --
-tar tarfile=${build.snapshots}/jboss-mq.tar
- longfile=gnu
- basedir=${build.snapshots.tmp}
- includes=jboss-mq/**
+tar tarfile=${build.snapshots}/jboss-mq.tar longfile=gnu
+ tarfileset dir=${build.snapshots.tmp} mode=655
+include name=jboss-mq/**/build.sh/
+include name=jboss-mq/**/tools/bin/ant/
+include name=jboss-mq/**/tools/bin/antRun/
+ /tarfileset
+ tarfileset dir=${build.snapshots.tmp} mode=644
+include name=jboss-mq/**/
+exclude name=jboss-mq/**/build.sh/
+exclude name=jboss-mq/**/tools/bin/ant/
+exclude name=jboss-mq/**/tools/bin/antRun/
+ /tarfileset
/tar
gzip src=${build.snapshots}/jboss-mq.tar
zipfile=${build.snapshots}/jboss-mq.tgz/
!-- build jboss-plugins.zip --
-
- zip zipfile=${build.snapshots}/jboss-plugins.zip
+
+zip zipfile=${build.snapshots}/jboss-plugins.zip
fileset dir=${build.snapshots.tmp}
include name=jboss-plugins/**/
/fileset
/zip
!-- build jboss-plugins.tgz --
- tar tarfile=${build.snapshots}/jboss-plugins.tar
- longfile=gnu
- basedir=${build.snapshots.tmp}
- includes=jboss-plugins/**
+tar tarfile=${build.snapshots}/jboss-plugins.tar longfile=gnu
+ tarfileset dir=${build.snapshots.tmp} mode=655
+include name=jboss-plugins/**/build.sh/
+include name=jboss-plugins/**/tools/bin/ant/
+include name=jboss-plugins/**/tools/bin/antRun/
+ /tarfileset
+ tarfileset dir=${build.snapshots.tmp} mode=644
+include name=jboss-plugins/**/
+exclude name=jboss-plugins/**/build.sh/
+exclude name=jboss-plugins/**/tools/bin/ant/
+exclude name=jboss-plugins/**/tools/bin/antRun/
+ /tarfileset
/tar
gzip src=${build.snapshots}/jboss-plugins.tar
zipfile=${build.snapshots}/jboss-plugins.tgz/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [jboss-docs] Is the build system too complicated?
java really pisses me off sometimes. why can't you get file perms from a
given platform? all of this platform independence has really dumbed down
the file access apis, too much in my oppinon.
rant
it appears that there is noway with the vanilla jdk to check if a file is
executable... which is really *ucking stupid if you ask me... but since you
didn't well I am telling you anyways. Afterall who would want to execute a
file from Java? Whatever, where do they find the people that design this
crap.
/rant
Anyways, I have HACKED the build file to make all 'build.sh' and
'tools/bin/ant[Run]' files executable. I don't really like it, but don't
have much choice. Thanks SUN!
* * *
Let me know if this fixes your problem, should be ready early tomorrow
morning on the website.
--jason
On Wed, 21 Nov 2001 [EMAIL PROTECTED] wrote:
Unfortunately, my firewall currently doesn't let me check out via cvs
directly unless it's over ssh, and I don't have RW access to the
repository (yet :) -- I've been downloading the nightly snapshots (ugh)
in .tgz form from http://www.jboss.org/snapshots/. When I untar that, the
executable bit is not set.(using gnu tar and gzip on linux with the
command 'tar -xzvf jboss-all.tgz`) Actually, from a few spot checks, it
looks as if everything comes out '-rw-r--r--', including build.sh itself.
Yes, I've tried using the -p option with tar to extract permissions
information -- no effect (I think that's the default anyway, though I'm
not sure)
-jason
Jason Dillon [EMAIL PROTECTED]
11/21/2001 02:09 PM
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject:Re: [JBoss-dev] Re: [jboss-docs] Is the build system too
complicated?
The executable bit is set on tools/bin/ant. Why dosen't your cvs client
set
it when you check it out?
--jason
On Wed, 21 Nov 2001 [EMAIL PROTECTED] wrote:
I do have a slightly off-topic gripe -- as of late, (in the rh
snapshots),
jboss-all/tools/bin/ant has not been executable on UNIX systems (took my
little mind a while to figure out what was going on). The
jboss-all/build/build.sh script has been failing because of it. It
looks
for an executable 'ant', but never finds it (it doesn't have the
executable bit set). I can see three possible solutions:
1. Just have the executable bit set on the ant script to start with
2. Change the search() function in build.sh to read like this:
search() {
search=$*
for d in $search; do
ANT_HOME=`pwd`/$d
ANT=$ANT_HOME/bin/ant
# -- Begin modifications
# If the file exists at all, attempt to add the executable bit
if [ -e $ANT ]; then
`chmod +x $ANT`
fi
# -- End modifications
if [ -x $ANT ]; then
# found one
echo $ANT_HOME
break
fi
done
}
#(just added a -e test to see if the file exists, and attempt to make it
executable so that the next -x test works)
3. Skip looking for an executable ant script -- just make sure it
exists,
and call it with 'sh ant'.
-jason
Jason Dillon [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
11/20/2001 09:38 PM
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject:[JBoss-dev] Re: [jboss-docs] Is the build system
too complicated?
I have not found an easy way to provide this common setup/initialization
stuff as a resource. Perhaps if I could tell the JAXP parser to read a
resource file when parsing this could be done, but that would require
the
Ant entity hooks to be installed to handle that.
Perhaps they have done that, perhaps I could sway them todo it... though
my
previous attempts to do so has failed (too much *ucking voting).
If you can think of a way please let me know.
Thanks for your feedback!
--jason
On Tue, 20 Nov 2001, David Jencks wrote:
It has often seemed to me that there is substantial duplication
between
the
setup parts of the module level build.xml files. I sure haven't
figured
out a clue of a way to reduce this, but if it could be done, it might
make
the files a little less intimidating. In light of the vast
improvement
over the preceding build system, this is a hardly visible quibble.
david jencks
On 2001.11.20 16:43:07 -0500 Jason Dillon wrote:
Please let me know if you think that the build system is too
complicated,
or
if there is some part of the system which is too complicated.
--jason
---
Subscribe: [EMAIL PROTECTED]
Unsubscribe:[EMAIL PROTECTED]
Archive: http://groups.yahoo.com/group/jboss-docs/
Your use of Yahoo!
[JBoss-dev] CVS update: thirdparty/mortbay/jetty/lib javax.servlet.jar org.apache.jasper.jar org.mortbay.jetty.jar
User: jules_gosnell Date: 01/11/21 15:13:00 Modified:mortbay/jetty/lib javax.servlet.jar org.apache.jasper.jar org.mortbay.jetty.jar Log: my first cut of the JBoss3/Jetty4 integration - enjoy ! Revision ChangesPath 1.2 +239 -126 thirdparty/mortbay/jetty/lib/javax.servlet.jar Binary file 1.5 +984 -705 thirdparty/mortbay/jetty/lib/org.apache.jasper.jar Binary file 1.3 +1488 -1417thirdparty/mortbay/jetty/lib/org.mortbay.jetty.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty build.xml
User: jules_gosnell
Date: 01/11/21 15:13:00
Modified:jettybuild.xml
Log:
my first cut of the JBoss3/Jetty4 integration - enjoy !
Revision ChangesPath
1.11 +55 -24contrib/jetty/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/contrib/jetty/build.xml,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- build.xml 2001/11/19 15:34:04 1.10
+++ build.xml 2001/11/21 23:13:00 1.11
@@ -29,9 +29,9 @@
!-- Setup the basic project roots. --
path id=project.rootpathelement location=../..//path
-property name=project.root refid=project.root/
+property name=project.root refid=project.root/
property name=project.build value=${project.root}/build/
-
+
!-- Include user and project property overrides. --
property file=${user.home}/.buildmagic.properties/
property file=${user.home}/.ant.properties/
@@ -130,7 +130,7 @@
!--
| Configure the build system.
|
- | Configuration elements should be placed in the appropriate
+ | Configuration elements should be placed in the appropriate
| _configure-* targets.
--
@@ -180,6 +180,13 @@
/fileset
/path
+!-- Java Authentication and Authorization Service (JAAS) --
+property name=sun.jaas.root value=${project.thirdparty}/sun/jaas/
+property name=sun.jaas.lib value=${sun.jaas.root}/lib/
+path id=sun.jaas.classpath
+ pathelement path=${sun.jaas.lib}/jaas.jar/
+/path
+
!-- Log4j --
property name=apache.log4j.root value=${project.thirdparty}/apache/log4j/
property name=apache.log4j.lib value=${apache.log4j.root}/lib/
@@ -218,6 +225,7 @@
path refid=sun.jndi.classpath/
path refid=sun.jmx.classpath/
path refid=sun.jaxp.classpath/
+ path refid=sun.jaas.classpath/
path refid=apache.log4j.classpath/
path refid=junit.junit.classpath/
path refid=mortbay.jetty.classpath/
@@ -299,14 +307,14 @@
!-- Compile--
!-- == --
- !--
+ !--
| Compile everything.
|
- | This target should depend on other compile-* targets for each
+ | This target should depend on other compile-* targets for each
| different type of compile that needs to be performed, short of
| documentation compiles.
--
- target name=compile
+ target name=compile
depends=compile-classes, compile-etc, compile-resources
description=Compile all source files./
@@ -356,7 +364,7 @@
!-- Archives --
!-- == --
- !--
+ !--
| Build all jar files.
--
@@ -388,32 +396,55 @@
include name=org.mortbay.tools.jar/
include name=cryptix-sasl-jetty.jar/
/fileset
-
+
/jar
/target
+target name=devel depends=jars
+ description=Deploy and Test the Jetty plugin
+echoUndeploying old Jetty plugin.../echo
+delete
file=../../build/output/jboss-3.0.0alpha/deploy/lib/${module.name}.sar/
+sleep seconds=5/
+
+echoDeploying new Jetty plugin.../echo
+copy file=${build.lib}/${module.name}.sar
+ filtering=no
+ todir=../../build/output/jboss-3.0.0alpha/deploy/lib
+ /
+sleep seconds=5/
+
+exec dir=../../testsuite/
+ executable=/bin/sh
+
+ arg value=./build.sh/
+ arg value=-emacs/
+ arg value=-Djavac.debug=true/
+ arg value=-Dtest=WebIntegrationUnitTestCase/
+ arg value=one-test/
+/exec
+/target
!-- == --
!-- Documents --
!-- == --
- !--
+ !--
| Create all generated documenation.
|
- | This target should depend on other docs-* targets for each
+ | This target should depend on other docs-* targets for each
| different type of docuementation that is to be generated.
--
- target name=docs depends=init, docs-api
+ target name=docs depends=init, docs-api
description=Builds all documentation.
/target
!-- Javadocs is an exception, but provide a docs-api to conform. --
target name=docs-api depends=docs-javadocs/
- !--
- | Check if we need to build javadocs
+ !--
+ | Check if we need to build javadocs
|
| Javadocs will only be generated if one or more .java
[JBoss-dev] CVS update: thirdparty/mortbay/jetty3extra/lib org.mortbay.ftp.jar org.mortbay.jetty.jmx.jar org.mortbay.tools.jar
User: jules_gosnell Date: 01/11/21 15:13:00 Modified:mortbay/jetty3extra/lib org.mortbay.ftp.jar org.mortbay.jetty.jmx.jar org.mortbay.tools.jar Log: my first cut of the JBoss3/Jetty4 integration - enjoy ! Revision ChangesPath 1.2 +13 -13thirdparty/mortbay/jetty3extra/lib/org.mortbay.ftp.jar Binary file 1.2 +67 -82thirdparty/mortbay/jetty3extra/lib/org.mortbay.jetty.jmx.jar Binary file 1.2 +96 -87thirdparty/mortbay/jetty3extra/lib/org.mortbay.tools.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty JBossWebApplicationContext.java JBossLogSink.java JBossUserRealm.java Jetty.java JettyMBean.java JettyResolver.java JettyService.java SetupHandler.java
User: jules_gosnell
Date: 01/11/21 15:13:01
Modified:jetty/src/main/org/jboss/jetty JBossLogSink.java
JBossUserRealm.java Jetty.java JettyMBean.java
JettyResolver.java JettyService.java
SetupHandler.java
Added: jetty/src/main/org/jboss/jetty
JBossWebApplicationContext.java
Log:
my first cut of the JBoss3/Jetty4 integration - enjoy !
Revision ChangesPath
1.7 +9 -8 contrib/jetty/src/main/org/jboss/jetty/JBossLogSink.java
Index: JBossLogSink.java
===
RCS file: /cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/JBossLogSink.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- JBossLogSink.java 2001/10/03 22:27:02 1.6
+++ JBossLogSink.java 2001/11/21 23:13:01 1.7
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: JBossLogSink.java,v 1.6 2001/10/03 22:27:02 jules_gosnell Exp $
+// $Id: JBossLogSink.java,v 1.7 2001/11/21 23:13:01 jules_gosnell Exp $
package org.jboss.jetty;
@@ -22,7 +22,7 @@
* This class bidges the API between Jetty and Log4J.
*
* @author a href=mailto:;Jules Gosnell/a
- * @version $Id: JBossLogSink.java,v 1.6 2001/10/03 22:27:02 jules_gosnell Exp $
+ * @version $Id: JBossLogSink.java,v 1.7 2001/11/21 23:13:01 jules_gosnell Exp $
* @since 1.0
* @see org.mortbay.util.LogSink
*/
@@ -34,7 +34,7 @@
HashMap _dispatch = new HashMap();
interface Logger {void log(String s);}
-
+
public
JBossLogSink()
{
@@ -65,6 +65,7 @@
throws InterruptedException
{
_started = false;
+//_log=null;
}
public void
@@ -101,10 +102,10 @@
{
// is it possible to translate these into JBoss logging options...?
}
-
+
public void
setOptions(String logOptions)
- {
+ {
// setOptions((logOptions.indexOf(OPT_TIMESTAMP) = 0),
// (logOptions.indexOf(OPT_LABEL) = 0),
// (logOptions.indexOf(OPT_TAG) = 0),
@@ -112,7 +113,7 @@
// (logOptions.indexOf(OPT_STACKTRACE) = 0),
// (logOptions.indexOf(OPT_ONELINE) = 0));
}
-
+
public String
getOptions()
{
@@ -125,7 +126,7 @@
// (_logOneLine?O:);
return ;
}
-
+
/* */
/** Log a message.
* This method formats the log information as a string and calls
@@ -158,7 +159,7 @@
/** Log a message.
* The formatted log string is written to the log sink. The default
* implementation writes the message to a PrintWriter.
- * @param formattedLog
+ * @param formattedLog
*/
public synchronized void
log(String formattedLog)
1.8 +131 -79 contrib/jetty/src/main/org/jboss/jetty/JBossUserRealm.java
Index: JBossUserRealm.java
===
RCS file: /cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/JBossUserRealm.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- JBossUserRealm.java 2001/09/17 23:07:47 1.7
+++ JBossUserRealm.java 2001/11/21 23:13:01 1.8
@@ -5,13 +5,17 @@
* See terms of license at gnu.org.
*/
-// $Id: JBossUserRealm.java,v 1.7 2001/09/17 23:07:47 jules_gosnell Exp $
+// $Id: JBossUserRealm.java,v 1.8 2001/11/21 23:13:01 jules_gosnell Exp $
package org.jboss.jetty;
-import java.util.HashSet;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.Set;
+import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
+import javax.security.auth.Subject;
import org.apache.log4j.Category;
import org.jboss.security.EJBSecurityManager;
import org.jboss.security.RealmMapping;
@@ -25,106 +29,103 @@
/** An implementation of UserRealm that integrates with the JBossSX
* security manager associted with the web application.
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.7 $
+ * @version $Revision: 1.8 $
*/
+
+// TODO
+
public class JBossUserRealm
implements UserRealm
{
- private String _realmName;
- private Category _log;
-
- //
-
- class User
-extends SimplePrincipal
-implements UserPrincipal
- {
-HttpRequest _request;
-
-User(String name, HttpRequest request)
+ class JBossUserPrincipal
+extends SimplePrincipal // The JBoss API
+implements UserPrincipal // The Jetty API
+ {
+JBossUserPrincipal(String name)
{
super(name);
- _request = request;
+
[JBoss-dev] Security exceptions when calling a local interface
Are you guys aware that the LocalHome interface can be called from someone without enough permissions and the exception thrown should be of type EJBException, not RemoteException? I interpreted the following as the Security Interceptor throwing a RemoteException when it should throw an EJBException. From this on the exception chaining become some kind of a chaos. I assigned method permissions and everything worked fine. [2001-11-20 20:49:25,032,LogInterceptor,ERROR] TransactionRolledbackException, causedBy: java.lang.reflect.UndeclaredThrowableException at $Proxy18.findByPrimaryKey(Unknown Source) . . . Caused by: java.rmi.RemoteException: checkSecurityAssociation; nested exception is: java.lang.SecurityException: No method permissions assigned to method=findByPrimaryKey ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/system ServiceConfigurator.java
User: user57 Date: 01/11/21 15:31:39 Modified:src/main/org/jboss/system ServiceConfigurator.java Log: o using class to create Logger instance Revision ChangesPath 1.9 +2 -2 jboss/src/main/org/jboss/system/ServiceConfigurator.java Index: ServiceConfigurator.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/system/ServiceConfigurator.java,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- ServiceConfigurator.java 2001/11/19 06:58:57 1.8 +++ ServiceConfigurator.java 2001/11/21 23:31:39 1.9 @@ -42,7 +42,7 @@ * * @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a * @author a href=mailto:[EMAIL PROTECTED];Hiram Chirino/a - * @version $Revision: 1.8 $ + * @version $Revision: 1.9 $ * * pb20010830 marc fleury:/b * ul @@ -73,7 +73,7 @@ private MBeanServer server; /** The instance logger. */ - private static Logger log = Logger.create(Configurator); + private static Logger log = Logger.create(ServiceConfigurator.class); // Constructors -- ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] suggest changing log4j layout patterns
Dosen't look like the 1.1.3 xml configurator does the right thing with
custom priorities, also looks like it can not set the CategoryFactory
either.
=(
--jason
On Fri, 16 Nov 2001, Scott M Stark wrote:
The priority is fine but the thread is not. As of log4j 1.1.3 the log4j.dtd
says is supports a priority class but I have not tried it.
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: Scott M Stark [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, November 16, 2001 10:45 AM
Subject: Re: [JBoss-dev] suggest changing log4j layout patterns
How about at least adding the priority. I don't think that this info that
will dump to console with this format is excesive, perhaps you might not
want the thread name there.
Do you know if we are still forced to use log4j.properties (instead of
log4j.xml) due to the JBoss TRACE priority?
--jason
On Fri, 16 Nov 2001, Scott M Stark wrote:
The console output should be short and simple. In any production
envrionment your likely to not even be using it so its just for quick
looks
and I don't want excessive info displayed there. The default server.log
format can be more verbose. Its also trival to change these settings if
you know enough about log4j, so I would rather keep the defaults
simpler and let you change them for your specific need.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, November 15, 2001 4:09 PM
Subject: [JBoss-dev] suggest changing log4j layout patterns
I suggest that we change the log4j layout patterns to add more useful
information to the console and server.log files:
For console:
%-5p %c{1} [%t] - %m%n
INFO JMXAdaptorService [main] - Starting
DEBUG MailingPOEJB [Passivator Thread for MailingPO] - ejbPassivate
For server.log:
%d %-5r %-5p %c [%t] (%x) - %m%n
2001-11-13 11:35:32,210 2396 INFO org.jboss.util.Shutdown [main]
() -
Shutdown hook added
2001-11-13 11:35:36,576 6762 WARN
org.jboss.configuration.ConfigurationService [main] () -
Monitor:name=BeanCacheMonitor does not implement any Service methods
* * *
I have found that the extra information is very, very useful to debug
components running inside of JBoss. The above puts the minimal amount
of
useful information on the console in a terse format and dumps all
usefull
information into server.log in a verbose format.
I believe that users of JBoss would benifit from these settings by
default
and I suggest that we update the log4j.properties (or use log4j.xml)
with
these layout formats.
Any objections?
--jason
___
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
___
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-dev] CVS update: jboss/src/etc/conf/default log4j.properties
User: user57
Date: 01/11/21 16:10:01
Modified:src/etc/conf/default log4j.properties
Log:
o added priority to Default and Console patterns
o added example to add full NDC and thread information to Default
(server.log)
o added example to limit org.jboss to INFO
o added example to limit org.jboss.util to DEBUG
Revision ChangesPath
1.14 +24 -9 jboss/src/etc/conf/default/log4j.properties
Index: log4j.properties
===
RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/log4j.properties,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- log4j.properties 2001/10/18 08:27:42 1.13
+++ log4j.properties 2001/11/22 00:10:01 1.14
@@ -4,13 +4,14 @@
## ##
### == ###
-### $Id: log4j.properties,v 1.13 2001/10/18 08:27:42 kimptoc Exp $ ###
+### $Id: log4j.properties,v 1.14 2001/11/22 00:10:01 user57 Exp $ ###
# This creates a server.log appender and a console appender.
# Set the LoggerFactory as the default CategoryFactory
log4j.categoryFactory=org.jboss.logging.LoggerFactory
+# Setup the root category
log4j.rootCategory=DEBUG, Default, Console
### The server.log file appender
@@ -18,28 +19,42 @@
log4j.appender.Default=org.apache.log4j.FileAppender
log4j.appender.Default.File=../log/server.log
log4j.appender.Default.layout=org.apache.log4j.PatternLayout
-# A default format: [Category] msg\n
-log4j.appender.Default.layout.ConversionPattern=[%d,%c{1},%p] %m%n
-# A format useful for debugging concurrency: [Category,thread,elapased_ms] msg\n
-#log4j.appender.Default.layout.ConversionPattern=[%c{1},%t,%r] %m%n
+
# Truncate if it aleady exists.
log4j.appender.Default.Append=false
+# The default pattern: Date Priority [Category] Message\n
+log4j.appender.Default.layout.ConversionPattern=%d{ABSOLUTE} %-5p [%c] %m%n
+
+# The full pattern: Date MS Priority [Category] (Thread:NDC) Message\n
+#log4j.appender.Default.layout.ConversionPattern=%d{ABSOLUTE} %-5r %-5p [%c]
(%t:%x) %m%n
+
+# The old style pattern
+#log4j.appender.Default.layout.ConversionPattern=[%d,%c{1},%p] %m%n
+
### The console appender
log4j.appender.Console=org.jboss.logging.log4j.ConsoleAppender
log4j.appender.Console.Threshold=INFO
log4j.appender.Console.layout=org.apache.log4j.PatternLayout
-log4j.appender.Console.layout.ConversionPattern=[%d{ABSOLUTE},%c{1}] %m%n
+# The default pattern: Date Priority [Category] Message\n
+log4j.appender.Console.layout.ConversionPattern=%d{ABSOLUTE} %-5p [%c{1}] %m%n
+
+# The old style pattern
+#log4j.appender.Console.layout.ConversionPattern=[%d{ABSOLUTE},%c{1}] %m%n
+
# Example of increasing the priority threshold for the DefaultDS category
#log4j.category.DefaultDS=FATAL
-# Example of only showing INFO msgs for any categories under org.jboss.util
-#log4j.category.org.jboss.util=INFO
+# Only show INFO messages for org.jboss
+#log4j.category.org.jboss=INFO
+
+# Example of only showing DEBUG msgs for any categories under org.jboss.util
+#log4j.category.org.jboss.util=DEBUG
+
# An example of enabling the custom TRACE level priority that is used
# by the JBoss internals to diagnose low level details. This example
# turns on TRACE level msgs for the org.jboss.ejb.plugins package and its
# subpackages. This will produce A LOT of logging output.
#log4j.category.org.jboss.ejb.plugins=TRACE#org.jboss.logging.TracePriority
-
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] java.sql.SQLException: Connection has been closed!
RH CVS HEAD- refreshed an hour or so ago Running the WebIntegration testsuite: I guess the setEntityContext(null) - may have done this ! I'll scout around, but I don't think (tentatively) this is mine. Jules [00:11:37,740,Jetty] UserTransactionServlet: init [00:11:38,112,Default] setEntityContext(null) called [00:11:38,383,OILClientIL] ConnectionReceiverOILClient is connecting to: 127.0.0.1:42107 [00:11:38,519,Default] Sending a message.. [00:11:38,583,Default] entry ejbFindAll [00:11:38,629,Default] Initializing DATABASE tables for BMP test... [00:11:38,649,Default] java.sql.SQLException: Connection has been closed! [00:11:38,670,Default] at org.jboss.resource.adapter.jdbc.local.ConnectionInPool.close(ConnectionInPool.java:774) [00:11:38,670,Default] at org.jboss.test.cts.ejb.CtsBmpBean.initializeDatabaseTable(CtsBmpBean.java:531) [00:11:38,671,Default] at org.jboss.test.cts.ejb.CtsBmpBean.ensureTableExists(CtsBmpBean.java:496) [00:11:38,702,Default] at org.jboss.test.cts.ejb.CtsBmpBean.ejbFindAll(CtsBmpBean.java:190) [00:11:38,703,Default] at java.lang.reflect.Method.invoke(Native Method) [00:11:38,720,Default] at org.jboss.ejb.plugins.BMPPersistenceManager.callFinderMethod(BMPPersistenceManager.java:588) [00:11:38,720,Default] at org.jboss.ejb.plugins.BMPPersistenceManager.findEntities(BMPPersistenceManager.java:307) [00:11:38,720,Default] at org.jboss.ejb.EntityContainer.find(EntityContainer.java:606) [00:11:38,738,Default] at java.lang.reflect.Method.invoke(Native Method) [00:11:38,738,Default] at org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(EntityContainer.java:926) [00:11:38,738,Default] at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(EntitySynchronizationInterceptor.java:234) [00:11:38,738,Default] at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java:151) [00:11:38,739,Default] at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:104) [00:11:38,739,Default] at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:100) [00:11:38,739,Default] at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:156) [00:11:38,743,Default] at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:56) [00:11:38,743,Default] at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:106) [00:11:38,743,Default] at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:109) [00:11:38,743,Default] at org.jboss.ejb.EntityContainer.invokeHome(EntityContainer.java:441) [00:11:38,744,Default] at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invokeHome(JRMPContainerInvoker.java:460) [00:11:38,744,Default] at org.jboss.ejb.plugins.jrmp.interfaces.HomeProxy.invokeHome(HomeProxy.java:237) [00:11:38,744,Default] at org.jboss.ejb.plugins.jrmp.interfaces.HomeProxy.invoke(HomeProxy.java:182) [00:11:38,744,Default] at $Proxy20.findAll(Unknown Source) [00:11:38,744,Default] at org.jboss.test.web.servlets.UserTransactionServlet.processRequest(UserTransactionServlet.java:66) [00:11:38,744,Default] at org.jboss.test.web.servlets.UserTransactionServlet.doGet(UserTransactionServlet.java:97) [00:11:38,745,Default] at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) [00:11:38,745,Default] at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) [00:11:38,745,Default] at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:289) [00:11:38,745,Default] at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:526) [00:11:38,745,Default] at org.mortbay.http.HttpContext.handle(HttpContext.java:1145) [00:11:38,745,Default] at org.mortbay.http.HttpContext.handle(HttpContext.java:1099) [00:11:38,746,Default] at org.jboss.jetty.JBossWebApplicationContext.handle(JBossWebApplicationContext.java:185) [00:11:38,746,Default] at org.mortbay.http.HttpServer.service(HttpServer.java:725) [00:11:38,746,Default] at org.mortbay.http.HttpConnection.service(HttpConnection.java:745) [00:11:38,746,Default] at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:918) [00:11:38,746,Default] at org.mortbay.http.HttpConnection.handle(HttpConnection.java:760) [00:11:38,746,Default] at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:138) [00:11:38,747,Default] at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:287) [00:11:38,747,Default] at org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:715) [00:11:38,747,Default] at java.lang.Thread.run(Thread.java:484) [00:11:38,764,Jetty] WARNING: GET /jbosstest/UserTransactionServlet HTTP/1.1 java.rmi.ServerException: null _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL
[JBoss-dev] JBoss 3.0.0 Alpha - Exception while loading...
I get following exceptions. What's wrong? D:\jboss-3.0.0alpha\binrun.batJBOSS_CLASSPATH=;run.jar[GPA] Microkernel ClassLoaders and Libraries initializedLibraries adding URLClassLoader -1003117907 key URL file:/D:/jboss-3.0.0alpha//conf/default/Libraries adding URLClassLoader 912512067 key URL file:/D:/jboss-3.0.0alpha//lib/ext/log4j.jarLibraries adding URLClassLoader 634821366 key URL file:/D:/jboss-3.0.0alpha//lib/ext/jboss-spine.jar[19:19:52,960,root] Started Log4jService, config=file:/D:/jboss-3.0.0alpha//conf/default/log4j.properties[19:19:52,980,GPA] General Purpose Architecture [GPA][19:19:52,980,GPA] Java version: 1.3.1_01,Sun Microsystems Inc.[19:19:52,990,GPA] Java VM: Java HotSpot(TM) Client VM 1.3.1_01,Sun Microsystems Inc.[19:19:52,990,GPA] OS-System: Windows 2000 5.0,x86[19:19:52,990,GPA] JBoss Version : 3.0.0alpha(200111202304)[19:19:53,000,GPA] JBoss start time : Wed Nov 21 19:19:51 EST 2001[19:19:53,000,GPA] localDir : D:\jboss-3.0.0alpha[19:19:53,000,GPA] installationURL : file:/D:/jboss-3.0.0alpha/\[19:19:53,010,GPA] configuration : file:/D:/jboss-3.0.0alpha/\conf\default\[19:19:53,010,GPA] libraries : file:/D:/jboss-3.0.0alpha/\lib\ext\[19:19:53,010,GPA] local patch directory:[19:19:53,010,GPA] Oh, and remember we love you[19:19:53,090,Shutdown] Shutdown hook added[19:19:53,210,ServiceController] Controller MBean online[19:19:53,380,ServiceDeployer] Starting[19:19:53,410,ServiceDeployer] Temporary deploy directory is D:\jboss-3.0.0alpha\tmp\deploy\ServiceDeployer[19:19:53,420,ServiceDeployer] Started[19:19:53,471,ServiceDeployer] deploy failedjavax.xml.parsers.FactoryConfigurationError: org.apache.crimson.jaxp.DocumentBuilderFactoryImpl at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:154) at org.jboss.deployment.ServiceDeployer.getDocument(ServiceDeployer.java:633) at org.jboss.deployment.ServiceDeployer.deployLocalClasses(ServiceDeployer.java:281) at org.jboss.deployment.ServiceDeployer.deploy(ServiceDeployer.java:178) at org.jboss.deployment.DeployerMBeanSupport.deploy(DeployerMBeanSupport.java:107) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.Main.init(Main.java:199) at org.jboss.Main$1.run(Main.java:411) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.Main.main(Main.java:406)[19:19:53,511,Default] javax.xml.parsers.FactoryConfigurationError: org.apache.crimson.jaxp.DocumentBuilderFactoryImpl[19:19:53,511,Default] at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:154)[19:19:53,511,Default] at org.jboss.deployment.ServiceDeployer.getDocument(ServiceDeployer.java:633)[19:19:53,511,Default] at org.jboss.deployment.ServiceDeployer.deployLocalClasses(ServiceDeployer.java:281)[19:19:53,521,Default] at org.jboss.deployment.ServiceDeployer.deploy(ServiceDeployer.java:178)[19:19:53,521,Default] at org.jboss.deployment.DeployerMBeanSupport.deploy(DeployerMBeanSupport.java:107)[19:19:53,521,Default] at java.lang.reflect.Method.invoke(Native Method)[19:19:53,531,Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)[19:19:53,531,Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)[19:19:53,531,Default] at org.jboss.Main.init(Main.java:199)[19:19:53,531,Default] at org.jboss.Main$1.run(Main.java:411)[19:19:53,541,Default] at java.security.AccessController.doPrivileged(Native Method)[19:19:53,541,Default] at org.jboss.Main.main(Main.java:406)[19:19:53,541,Default] JBoss 3.0.0alpha(200111202304) [RABBIT-HOLE] Started in 0m:1s:633ms[19:19:53,551,Shutdown] Shutting down all services[19:19:53,551,Default] Shutting down[19:19:53,561,ServiceController] Stopping 1 services[19:19:53,561,ServiceController] Stopped 0 services[19:19:53,561,Shutdown] Shutdown complete[19:19:53,571,Default] Shutdown complete Yong T. Kim (kimion.com)Software Developer[EMAIL PROTECTED]http://www.kimion.com
Re: [JBoss-dev] Developing with JBoss
On Wed, 21 Nov 2001, David Jencks wrote: On 2001.11.21 14:06:58 -0500 danch wrote: Rickard Öberg wrote: That's much better, assuming I know where the tmp directory is. And I don't, since the name keeps changing for each deployment. :-( Something people have been compaining about roughly forever. I think there are possible problems with trying to always use the same temp dir -- for instance you might have problems removing the old copy before you wanted to start the new one. We might be able to cook up some crazy really hot redeploy whereby the new version is started before the old one is stopped, allowing the requests in process in the old version to complete while new requests go to the new version. What if we made the location of the temp dir visible through an mbean representing the deployment? You could have a little ant task to ask where the war went. What I would really like, is to see that a redeploy needs to happen, and have the new file extracted into a new directory first, THEN have the old version undeployed, then have the new one deployed, then have the old one deleted. The current way things are done, there is a big window open while the undeployment and redeployment is happening. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
