a couple of days ago, and I love it! It's a GSM phone, and I don't know if they're all this way, but it sounds clearer than my home phone. It almost sounds like I'm in the same room as someone when I'm talking to them. This is a big plus for me as I've always been annoyed by the bad sound of my previous phones.
I can check my raibledesigns.com e-mail using the IMAP4 protocol, and I can also check my Yahoo! Mail anywhere I can get a signal. Very cool - helps to cure my e-mail addiction. I hooked it up to my Powerbook G4 via infrared with GSM Remote and was able to have all my contact's numbers in almost no time.
from the Chief Developer of Tomcat and Struts:
> On Fri, 9 Aug 2002, Matt Raible wrote:
>
> Struts Dev Team - please verify my hypothesis below.
>
> I believe the Struts JARs and the DBCP JARs from common should be the
> same. After all, Struts does use the DBCP in it's distribution. You
> might want to upgrade to the latest build of Struts (which includes
> DBCP and Logging, among others). I know they're planning on releasing
> 1.1 Beta 2 this weekend.
>
The story is somewhat convoluted (I *hate* class loaders :-), but it goes
like this:
If you are going to use a JNDI datasource, then both your webapp AND
Tomcat need to see the same copy of the JDBC driver and the dbcp classes
(for 4.1.x) -- and the way to make that happen is to put the driver into
common/lib.
Because commons-dbcp.jar is there, it's dependent jars (such as
commons-collections.jar, jdbc2_0-stdext.jar, and (recently added)
commons-lang.jar) need to be in common/lib as well. Plus, of course,
jndi.jar if you're on a 1.2 system.
Having any of these JARs duplicated inside the webapp causes a problem
in 4.x based systems, because they try to use the local copy first -- and a
copy if foo.bar.MyClass loaded from the webapp is *not* the same class
as a copy of foo.bar.MyClass loaded from common/lib. This is a place where
Tomcat's modified class loader model causes grief (but only because you're
trying to use the same classes that Tomcat internally is trying to use -- if you
were using something like GenericDataSource with your own copy of the
connection pool, it would not be a problem).
One workaround for this would be to try turning off the modified loader
delegation model, by putting something like this in your server.xml file (or in
a context configuration file on Tomcat 4.1.x.):
<Context path="/myapp" ...>
<Loader delegate="false"/>
</Context>
This *should* let you have a copy of all the JAR files inside your webapp,
as well as in common/lib, but not cause any conflicts.
Please let me know, one way or the other, if this works -- it's clearly a
desireable goal that you can ship a WAR file with all the included commons
JARs but not have problems like this. I want to review how Tomcat's default
configuration can make this easier. And, from a Struts application perspective
(not just for Roller), this is a pretty serious usability issue.
> HTH,
>
> Matt
>
Craig McClanahan
PS: In Tomcat 4.1.x, the "deploy" command of the manager app lets you include
a context configuration file in the WAR, at location "META-INF/context.xml". So it
might still be possible to configure a single WAR that works correctly in Tomcat
4.1.x and still works in other servers (that would obviously ignore such a file).
Thanks for the clear and concise definition of how this all works Craig. So basically, in Tomcat 4.x, don't keep duplicates of your JARs in $CATALINA_HOME/common/lib AND in yourApp/WEB-INF/lib, OR turn off the modified loader delegation as specified above. Tomcat 4.1.x looks very cool, I'm just curious to know why they're on a Beta Release of 4.1.8, but still no official release?
