Re: Missing DataSourceRealm MBean definition
At 07:22 AM 11/7/2003 +0100, you wrote: Christopher Schultz wrote: Jacob, Tomcat5 no longer provides a separate LE version. You can take that as a hint not to use the LE version in Tomcat4.1.x. It causes nothing but confusion. I disagree. The 'LE' version actually has less confusion because there aren't fighting XML parsers involved. I don't know why Tomcat 5.x doesn't have an 'LE' version. I couldn't find any official word that LE versions caused confusion and have been elimintated :) I would second your point of view IF guys who make LE version gave us pointers to ALL missing components, like JavaMail, etc. Yep, and my argument is based on what *is*, not what should be. There *is* confusion, I wish there weren't. On the other hand, using system-wide XML parsers, and only those, has a drawback. Suppose one of your applications needs a particular version, while it doesn't sit well with Tomcat. What confusion will ensue then? Well, what is your alternative? It violates the sun classloading and servlet specs to load an XML parser from the WebappClassLoader and Tomcat enforces this. The same applies to any packages that already exist in the JDK. Furthermore, he LE version is meant to be used with j2sdk1.4+ which will force its own XML parsers (Crimson, Xalan, and the non-standard - at least w3c dom - XML parser API's that they include with it) on you unless you override it using the endorsed standards override mechanism. This is where Tomcat's common/endorsed directory comes into play. Given that info, what are you trying to say? The fact is, you can't include your own XML parser per webapp in the same running container. This may very well cause confusion, but you'll have to talk to Sun about its classloading rules, not the developers of Tomcat. I believe that Craig commented something like that on the notion of having global Struts installation in Tomcat. OK, granted, it makes more sense, since you can build your WebApp for a particular version of Struts, while XML API should stay the same. But still, if you have a combo that is working - Tomcat X.Y.Z and Xerces A.B.C - then it is reasonable to ship it together. I disagree with using a global version of Struts and I'm surprised Craig even said that since he has, as far as I am aware, always been a proponent of *avoiding* using libraries in a global classloader. This is not only problematic for the reasons you state, but what do you do about static variables? If they are set for one app, they are set for all. Not good. And, as I said before, you can't include your own XML parser in WEB-INF/lib. Your alternative to all this is to have separate Tomcat containers running apps that require different XML parsers with your preferred XML parser APIs in each respective Tomcat's common/endorsed directory. Jake - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Missing DataSourceRealm MBean definition
All, When going through the pain of setting up a DataSourceRealm and associated configuration, I found that I had to create my own MBean definition in the mbeans-descriptors.xml file. That was in version 4.1.27. Today, I upgraded to 4.1.29 and had to go through the same procedure. So, that leads me to ask two questions: 1. Am I really going something wrong? I would imagine that Tomcat, which ships with the DataSourceRealm class, would contain the correct MBean definition. 2. If I'm not screwing anything up, then why doesn't Tomcat ship with the correct MBean definition for DataSourceRealms? I happen to be using the 'LE' version of Tomcat, if that changes anything. Thanks, -chris ps. I also noticed that the 'LE' version does not come with commons-dbcp and commons-pool libraries. I thought the 'LE' version was only trimmed-down for JDK 1.4 users because it did not include an XML parser -- which is included with the JDK, now. What gives? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Missing DataSourceRealm MBean definition
At 10:46 AM 11/6/2003 -0500, you wrote: ps. I also noticed that the 'LE' version does not come with commons-dbcp and commons-pool libraries. I thought the 'LE' version was only trimmed-down for JDK 1.4 users because it did not include an XML parser -- which is included with the JDK, now. What gives? Tomcat5 no longer provides a separate LE version. You can take that as a hint not to use the LE version in Tomcat4.1.x. It causes nothing but confusion. Jake - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Missing DataSourceRealm MBean definition
Jacob, ps. I also noticed that the 'LE' version does not come with commons-dbcp and commons-pool libraries. I thought the 'LE' version was only trimmed-down for JDK 1.4 users because it did not include an XML parser -- which is included with the JDK, now. What gives? Tomcat5 no longer provides a separate LE version. You can take that as a hint not to use the LE version in Tomcat4.1.x. It causes nothing but confusion. I disagree. The 'LE' version actually has less confusion because there aren't fighting XML parsers involved. I don't know why Tomcat 5.x doesn't have an 'LE' version. I couldn't find any official word that LE versions caused confusion and have been elimintated :) -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Missing DataSourceRealm MBean definition
At 11:09 AM 11/6/2003 -0500, you wrote: Jacob, ps. I also noticed that the 'LE' version does not come with commons-dbcp and commons-pool libraries. I thought the 'LE' version was only trimmed-down for JDK 1.4 users because it did not include an XML parser -- which is included with the JDK, now. What gives? Tomcat5 no longer provides a separate LE version. You can take that as a hint not to use the LE version in Tomcat4.1.x. It causes nothing but confusion. I disagree. The 'LE' version actually has less confusion because there aren't fighting XML parsers involved. I don't know why Tomcat 5.x doesn't have an 'LE' version. I couldn't find any official word that LE versions caused confusion and have been elimintated :) -chris Search the archives. There has been plenty of discussion on this. The docs mention that the LE version leaves out what the JDK already has. However, other stuff such as dbcp and other jars are removed as well. This is not documented well (if at all) and has been, in my experience on the list, the cause of endless confusion. If all you are concerned about is the XML stuff, just delete everything in the common/endorsed directory and you are good to go. However, I wouldn't do this as crimson isn't exactly up to date, the dom apis aren't standard (taken from an unofficial version of the spec), and I would make sure to put xalan.jar in there to override the old buggy version that comes with the JDK. Jake - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Missing DataSourceRealm MBean definition
Christopher Schultz wrote: Jacob, Tomcat5 no longer provides a separate LE version. You can take that as a hint not to use the LE version in Tomcat4.1.x. It causes nothing but confusion. I disagree. The 'LE' version actually has less confusion because there aren't fighting XML parsers involved. I don't know why Tomcat 5.x doesn't have an 'LE' version. I couldn't find any official word that LE versions caused confusion and have been elimintated :) I would second your point of view IF guys who make LE version gave us pointers to ALL missing components, like JavaMail, etc. On the other hand, using system-wide XML parsers, and only those, has a drawback. Suppose one of your applications needs a particular version, while it doesn't sit well with Tomcat. What confusion will ensue then? I believe that Craig commented something like that on the notion of having global Struts installation in Tomcat. OK, granted, it makes more sense, since you can build your WebApp for a particular version of Struts, while XML API should stay the same. But still, if you have a combo that is working - Tomcat X.Y.Z and Xerces A.B.C - then it is reasonable to ship it together. Nix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
