Re: [DOCS] Tyrex-Tomcat HOWTO

[David Haraburda]

Thanks for fixing up my XML typos.

I guess I personally don't really care where the Tyrex HOWTO goes.. Tyrex is a bit
different though, so it may belong somewhere
else.  Only one comment:  you put my Tyrex stuff under Tyrex Connection Pool and
Castor ORM with mysql, and this is an inaccurate title.  Tyrex is more than
connection pooling, and it doesn't have anything to do with (at least the example
doesn't) Castor ORM.  Also, I didn't really mean for it to serve as an example for
MySQL, because I didnt actaully test that config.

That's my $0.02 about it :-)

Thanks,

David

Les Hughes wrote:

 David / All,

 Had problems rendering your doc so I've patched it onto the end of mine and
 cleaned up the XML so that it styles up OK. Here it is.

 Comments?

 Les

 PS I will stop moaning about getting this committed, I promise... :-)

  -Original Message-
  From: Les Hughes [mailto:[EMAIL PROTECTED]]
  Sent: 02 July 2002 13:29
  To: 'Tomcat Developers List'
  Subject: RE: [DOCS] Tyrex-Tomcat HOWTO
 
 
  Hi all,
 
  Could we add this into the JNDI Datasources HOWTO that I
  wrote the other
  week (I dont think this has been committed yet BTW)
 
  If someone can commit my HOWTO, I'll merge the two together
  and submit a
  patch this afternoon.
 
  Hope this is OK
 
  Les
 
 
 
   -Original Message-
   From: David Haraburda [mailto:[EMAIL PROTECTED]]
   Sent: 28 June 2002 20:05
   To: [EMAIL PROTECTED]
   Subject: [DOCS] Tyrex-Tomcat HOWTO
  
  
   Hi all,
  
   Here is a short HOWTO I've written on how to use Tyrex 1.0
  with Tomcat
   4.1 (which goes along with the patch I submitted, which was just
   recently committed).  I've added the appropriate XML tags, using the
   other HOWTOs as examples, so very little modification should
   be needed.
   Feedback on the content however, is greatly appreciated. :-)
  
   Thanks,
  
   David
  
 
  --
  To unsubscribe, e-mail:
  mailto:[EMAIL PROTECTED]
  For additional commands, e-mail:
  mailto:[EMAIL PROTECTED]
 

   
  Name: jndi-datasource-examples-howto.xml
jndi-datasource-examples-howto.xmlType: XML Document (text/xml)
  Encoding: quoted-printable

   
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: [PATCH] Tyrex 1.0 w/ Tomcat

[David Haraburda]

Remy Maucherat wrote:


 For the transaction stuff to work properly, don't you need a valve also
 to bind/unbind the Tyrex context ?

Hmm, not sure exactly what you mean here (sorry :-).  I think you are referring
to the fact
that the transaction is bound to the current thread, and what if the transaction
is needed in
a different thread?


 Or is this only needed if you would want your transaction to last more
 than one request ?

Is this even something that should happen?  Beginning a transaction, and then
not closing
it until some other request happens, whenever that may be?  I don't see how this
could
ever be a good idea.

Any transaction in the system can be retrieved from the transaction manager,
by calling
getTransaction( xid ) -- but I'm still not sure you could retrieve the
transaction across requests --
since the only information available when looking up the UserTransaction is
whatever is passed
to getObjectInstance, I don't think this is possible, and a valve couldn't help
in this case.

Then again, maybe I totally misunderstood. :-)



 I'm +1 for the patch. We'll need to add detailed instructions on how to
 use it. Also, the JARs won't ship with Tomcat (it's just too much).

As soon as this gets finalized, then I can work up a short HOWTO or something.

David


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

[PATCH] Tyrex 1.0 w/ Tomcat

[David Haraburda]

 = 
 org.apache.commons.dbcp.BasicDataSourceFactory;
 
-public static final String TYREX_DATASOURCE_FACTORY = 
-Package + .TyrexDataSourceFactory;
+public static final String TYREX_RESOURCE_FACTORY =
+Package + .TyrexResourceFactory;
 
 public static final String TYREX_TRANSACTION_FACTORY = 
 Package + .TyrexTransactionFactory;
@@ -100,5 +100,9 @@
 public static final String OBJECT_FACTORIES = ;
 
 public static final String FACTORY = factory;
+
+public static final String TYREX_DOMAIN_CONFIG = tyrexDomainConfig;
+
+public static final String TYREX_DOMAIN_NAME = tyrexDomainName;
 
 }
Index: 
jakarta-tomcat-4.0/catalina/src/share//org/apache/naming/factory/ResourceFactory.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/ResourceFactory.java,v
retrieving revision 1.7
diff -b -d -u -r1.7 ResourceFactory.java
--- 
jakarta-tomcat-4.0/catalina/src/share//org/apache/naming/factory/ResourceFactory.java  
 24 Feb 2002 05:09:58 -  1.7
+++ 
+jakarta-tomcat-4.0/catalina/src/share//org/apache/naming/factory/ResourceFactory.java 
+  21 Jun 2002 07:47:11 -
@@ -170,6 +170,16 @@
 .newInstance();
 } catch(Throwable t) {
 }
+} else if (ref.getClassName().equals(tyrex.resource.Resource)) {
+String tyrexResourceFactoryClassName =
+System.getProperty(tyrex.resource.Resource.Factory,
+   Constants.TYREX_RESOURCE_FACTORY);
+try {
+factory = (ObjectFactory)
+Class.forName(tyrexResourceFactoryClassName)
+.newInstance();
+} catch(Throwable t) {
+}
 }
 }
 if (factory != null) {
Index: 
jakarta-tomcat-4.0/catalina/src/share//org/apache/naming/factory/TyrexTransactionFactory.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/TyrexTransactionFactory.java,v
retrieving revision 1.3
diff -b -d -u -r1.3 TyrexTransactionFactory.java
--- 
jakarta-tomcat-4.0/catalina/src/share//org/apache/naming/factory/TyrexTransactionFactory.java
   22 Feb 2002 08:47:14 -  1.3
+++ 
+jakarta-tomcat-4.0/catalina/src/share//org/apache/naming/factory/TyrexTransactionFactory.java
+   21 Jun 2002 07:47:11 -
@@ -71,21 +71,23 @@
 import javax.naming.Reference;
 import javax.naming.RefAddr;
 import javax.naming.spi.ObjectFactory;
+import java.net.URL;
 import org.apache.naming.TransactionRef;
-import tyrex.tm.Tyrex;
-
+import tyrex.tm.TransactionDomain;
+import javax.transaction.UserTransaction;
 /**
  * Object factory for Tyrex User transactions.br
+ *
  * Tyrex is an open-source transaction manager, developed by Assaf Arkin and
  * exolab.org. See the a href=http://tyrex.exolab.org/;Tyrex homepage/a
  * for more details about Tyrex and downloads.
  * 
+ * @author David Haraburda
  * @author Remy Maucherat
  * @version $Revision: 1.3 $ $Date: 2002/02/22 08:47:14 $
  */
 
-public class TyrexTransactionFactory
-implements ObjectFactory {
+public class TyrexTransactionFactory extends TyrexFactory {
 
 
 // --- Constructors
@@ -104,9 +106,9 @@
 
 
 /**
- * Crete a new User transaction instance.
+ * Create a UserTransaction.
  * 
- * @param obj The reference object describing the DataSource
+ * @param obj The reference object
  */
 public Object getObjectInstance(Object obj, Name name, Context nameCtx,
 Hashtable environment)
@@ -114,13 +116,11 @@
 
 if (obj instanceof TransactionRef) {
 Reference ref = (Reference) obj;
-if (ref.getClassName()
-.equals(javax.transaction.UserTransaction)) {
 
+if (ref.getClassName().equals(javax.transaction.UserTransaction) )
+{
 try {
-
-return Tyrex.getUserTransaction();
-
+return getTransactionDomain().getUserTransaction();
 } catch (Throwable t) {
 log(Cannot create Transaction, Exception, t);
 throw new NamingException


/*
 * $Header$
 * $Revision$
 * $Date$
 *
 * 
 *
 * The Apache Software License, Version 1.1
 *
 * Copyright (c) 1999 The Apache Software Foundation.  All rights
 * reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1

Re: What's up with Tyrex?

[David Haraburda]

Remy Maucherat wrote:

 The Tyrex code currently uses 0.9.7. Migrating to 1.0 should happen
 soon, but may be slightly tricky.

Yep, looks like that is true.



 If you have ideas/patches, feel free to send them to the list.

Well, regarding the TyrexDataSourceFactory class, it looks like it can be
removed.  The tyrex.resource.jdbc.xa.EnabledDataSource (formerly
tyrex.jdbc.xa.EnabledDataSource, which TyrexDataSourceFactory creates)
implements javax.spi.ObjectFactory, so it can create these objects itself.  It
looks like tyrex.jdbc.ServerDataSource is gone, so no problem there.

And then regarding the TyrexTransactionFactory...

I am not sure of what direction or how migration to 1.0 was going to happen --
if anyone is currently working on this I'd like to know what is going to
happen.  If not, if I could get an idea of what is wanted/needed to happen, I
could cook up a patch, as I'd like to see Tyrex 1.0 working with Tomcat (older
versions aren't even available for download from tyrex.exolab.org).

Tyrex now has the idea of a TransactionDomain, which is created from an XML
config file, and manages transactions, data sources, etc.  Creating an
ObjectFactory for this new TransactionDomain shouldn't be a big deal, or even
updating TyrexTransactionFactory to get the UserTransactions from this new
class, to provide a bit of backward compatiability (although the new transaction
domain xml file still has to be loaded somehow).

My apologies for being confused or causing confusion -- both can happen when I
post this late at night :-)

David



 Remy

 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

What's up with Tyrex?

[David Haraburda]

Hello,

The build instructions, and the build.properties.sample file are both
setup for Tyrex 1.0 (I'm building from CVS), but Tomcat won't compile
(specifically, the two Tyrex class in org.apache.naming.factory),
because the tyrex.jdbc package is apparently gone from 1.0.  It looks
like the Tyrex CVS repository has been re-structured quite a bit, as a
lot of things were removed, so I am not sure where this functionality
went.  Is this just an error in the Tomcat docs?  Is there a plan to
integrate 1.0 into Tomcat?  I'd submit a patch, but I'm not sure where
all the tyrex.jdbc code moved to (or what code replaces it).

Just wondering.

Thanks,

David



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: Job postings ?

[David Haraburda]

As a (mostly) lurker and occasional patch submitter on the Tomcat-dev
list, and especially as someone who is in between contract/consulting
jobs right now, I think most wouldn't mind these occasional kind of
posts -- something that shows up in my inbox will get my attention right
away -- most aren't going to check such a web page on a daily or even
weekly basis.  This works out better for potential candidates, and for
companies hiring.

Just my two cents,

David

On Tue, 2002-06-04 at 18:05, [EMAIL PROTECTED] wrote:
 
 As allways, it's easier to do than ask permission.
 
 Since you asked, I think it's too much overhead to have a page,
 but sending a mail on tomcat-dev doesn't hurt, it's quite
 refreshing to know there are still companies hiring.
 
 
 Costin
 
 On Tue, 4 Jun 2002, Remy Maucherat wrote:
 
  Hi,
  
  Just wondering if posting Tomcat-specific job offers on the list is
  acceptable, or if there is another place I could post that too (the
  rationale would be to be able to hire someone with extensive Tomcat
  knowledge, and even better someone already involved with the community).
  Since there's now a Vendor page on the Jakarta website, maybe I could add
  a Job Listings page :)
  
  Comments ?
  
  Remy
  
  
  --
  To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
  For additional commands, e-mail: mailto:[EMAIL PROTECTED]
  
  
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 
 



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: JNDI/Webapp ClassLoader Bug (ContextBindings.java), patch (?)attached

[David Haraburda]

Hi Remy,

Thanks for responding and thanks for adding the patch to 4.1.  I do have a
question for you though:

Looking at the J2EE spec, I can't find anything that says applications shouldn't
create ClassLoaders, although you do say it is implied.  I am just wondering,
where do you find this implication?  I realize that most web applications
probably don't need to create their own classloaders, but (I've only glanced at
this part of the Cocoon code) it seems to be justified at first look in this
case.

Just looking for some clarification.

Thanks again,

David

Remy Maucherat wrote:

  Hi,
 
  I believe I have found a bug (or a problem at least) with the way Tomcat
  handles associating webapp contexts to JNDI naming contexts.
 
  ContextBindings.java, which apparently handles these associations does
  not account for the fact that a web application may have its own
  ClassLoader.  I am trying to use Apache Cocoon which does this.  I've
  properly enlisted the object I want in the namespace using the
  server.xml file and the web.xml file.  After Tomcat creates this
  NamingContext, it binds it to Cocoon's context in
  ContextBindings.java, using the current ClassLoader as a key, which
  happens to be Tomcat's WebAppClassLoader.  Cocoon provides its own
  ClassLoader (because it is a rather complex beast :-), so when I try to
  get to my object in the namespace it can't be found (even though its
  parent ClassLoader is the correct WebAppClassLoader)
 
  This may or may not be appropriate, but I've found that it works for
  me.  I've modified the following methods in ContextBindings.java:
 
  getClassLoader()
  getClassLoaderName()
  isClassLoaderBound()
 
  so that they check the hashtable for the current ClassLoader, and
  continue to search up the heirarchy by looking at that ClassLoader's
  parent -- returning success at the first match, and returning failure
  once it has been all the way up the heirarchy.  A method I did not
  modify was unbindClassLoader() -- I'll leave that to further discussion
  because (if my solution is acceptable) I'm not sure if it is appropriate
  to leave it or change it.
 
  This patch is against CVS revision 1.4 of the file, which I got from the
  source distribution of Tomcat 4.0.4 beta 3.

 The J2EE ENC is, by definition, a J2EE features. Applications which would
 like to use it should comply with the J2EE model, which implies:
 - not forking threads
 - not creating classloaders
 - running inside a security manager

 Cocoon does not adhere to this model, and will probably have problems using
 the J2EE ENC in other app servers. To get around this, it would be better
 for Cocoon to set the webapp CL as the thread context CL during the
 processing of the user code.

 Since this patch does not seem to introduce any problems and improves
 robustness, I think I'll apply it to the 4.1.x codebase.

 Remy

 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

PATCH - AdaptiveClassLoader.java

[David Haraburda]

Hi,

This is a patch for AdaptiveClassLoader -- it fixes the problem(s) I've
described in my previous post.  In short:

The API documentation for java.lang.ClassLoader states that subclasses
of ClassLoader should implement the findResource and findResources
method.  I've added these methods to AdaptiveClassLoader, and fixed up
getResource.  What happens is that when the final method getResources on
java.lang.ClassLoader is called, (as is the case for
javax.naming.InitialContext when it searches for jndi.properties), it
calls findResources on the current instance of the ClassLoader.  Becuase
AdaptiveClassLoader does not override this method, the default
implementation is called, which returns null.  With this patch, the web
application classes and lib directory will be searched, as I would
assume correct behaivor to be.

This patch is against the 3.2.3 source tarball I downloaded when it was
first released a couple of days ago.

Also -- as I stated in a previous post there was a patch for this
submitted awhile back, but it did not get committed and I could find no
explanation why.  My patch does the same thing, although it is a bit
simplier, and only changes this one file.  If this cannot be committed I
would appreciate knowing the reason why, and also would like any
suggestions on what to do with a jndi.properties file in my
WEB-INF/classes directory.

Thanks,
David

-- 
David Haraburda - [EMAIL PROTECTED]
Everest - Helping You Manage Outsourcing
972-980-0013 x736

--- AdaptiveClassLoader.java.orig   Sat Mar  3 21:47:58 2001
+++ AdaptiveClassLoader.javaFri Jul 20 01:31:24 2001
@@ -15,24 +15,24 @@
  *
  * 3. All advertising materials mentioning features or use of this
  *software must display the following acknowledgment:
- *This product includes software developed by the Java Apache 
+ *This product includes software developed by the Java Apache
  *Project for use in the Apache JServ servlet engine project
  *http://java.apache.org/.
  *
- * 4. The names Apache JServ, Apache JServ Servlet Engine and 
- *Java Apache Project must not be used to endorse or promote products 
+ * 4. The names Apache JServ, Apache JServ Servlet Engine and
+ *Java Apache Project must not be used to endorse or promote products
  *derived from this software without prior written permission.
  *
  * 5. Products derived from this software may not be called Apache JServ
- *nor may Apache nor Apache JServ appear in their names without 
+ *nor may Apache nor Apache JServ appear in their names without
  *prior written permission of the Java Apache Project.
  *
  * 6. Redistributions of any form whatsoever must retain the following
  *acknowledgment:
- *This product includes software developed by the Java Apache 
+ *This product includes software developed by the Java Apache
  *Project for use in the Apache JServ servlet engine project
  *http://java.apache.org/.
- *
+ *
  * THIS SOFTWARE IS PROVIDED BY THE JAVA APACHE PROJECT AS IS AND ANY
  * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
@@ -123,7 +123,7 @@
  */
 public class AdaptiveClassLoader extends ClassLoader {
 private static final int debug=0;
-
+
 /**
  * Instance of the SecurityManager installed.
  */
@@ -163,7 +163,7 @@
  * compatibility, we'll duplicate the 1.2 private member var.
  */
 protected ClassLoader parent;
-
+
 /**
  * Private class used to maintain information about the classes that
  * we loaded.
@@ -194,7 +194,7 @@
 return origin == null;
 }
 }
-
+
 //--- Constructors
 
 /**
@@ -215,7 +215,7 @@
cache = new Hashtable();
 }
 
-public void setRepository( Vector classRepository ) 
+public void setRepository( Vector classRepository )
throws IllegalArgumentException
 {
// Verify that all the repository are valid.
@@ -275,7 +275,7 @@
 void log( String s ) {
System.out.println(AdaptiveClassLoader:  + s );
 }
-
+
 //--- Methods
 
 /**
@@ -326,7 +326,7 @@
 return false;
 } else {
 return (entry.origin.lastModified() != entry.lastModified);
-
+
 }
 }
 
@@ -348,7 +348,7 @@
if( debug5 )
log( cache entry:  + entry.loadedClass.getName());
if (entry.isSystemClass()) continue;
-   
+
 // XXX: Because we want the classloader to be an accurate
 // reflection of the contents of the repository, we also
 // reload if a class origin file is now missing.  This
@@ -381,7 +381,7 @@
  */
 public AdaptiveClassLoader reinstantiate() {
 AdaptiveClassLoader cl=new AdaptiveClassLoader();
-   cl.setParent(parent

Re: PATCH - AdaptiveClassLoader.java (oops!)

[David Haraburda]

Oops.  Accidentally attached the file with output from multiple runs of
diff:  Here is the correct (smaller) patch, with my apologies...

David
-- 
David Haraburda - [EMAIL PROTECTED]
Everest - Helping You Manage Outsourcing
972-980-0013 x736

--- AdaptiveClassLoader.java.orig   Sat Mar  3 21:47:58 2001
+++ AdaptiveClassLoader.javaFri Jul 20 01:34:57 2001
@@ -15,24 +15,24 @@
  *
  * 3. All advertising materials mentioning features or use of this
  *software must display the following acknowledgment:
- *This product includes software developed by the Java Apache 
+ *This product includes software developed by the Java Apache
  *Project for use in the Apache JServ servlet engine project
  *http://java.apache.org/.
  *
- * 4. The names Apache JServ, Apache JServ Servlet Engine and 
- *Java Apache Project must not be used to endorse or promote products 
+ * 4. The names Apache JServ, Apache JServ Servlet Engine and
+ *Java Apache Project must not be used to endorse or promote products
  *derived from this software without prior written permission.
  *
  * 5. Products derived from this software may not be called Apache JServ
- *nor may Apache nor Apache JServ appear in their names without 
+ *nor may Apache nor Apache JServ appear in their names without
  *prior written permission of the Java Apache Project.
  *
  * 6. Redistributions of any form whatsoever must retain the following
  *acknowledgment:
- *This product includes software developed by the Java Apache 
+ *This product includes software developed by the Java Apache
  *Project for use in the Apache JServ servlet engine project
  *http://java.apache.org/.
- *
+ *
  * THIS SOFTWARE IS PROVIDED BY THE JAVA APACHE PROJECT AS IS AND ANY
  * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
@@ -123,7 +123,7 @@
  */
 public class AdaptiveClassLoader extends ClassLoader {
 private static final int debug=0;
-
+
 /**
  * Instance of the SecurityManager installed.
  */
@@ -163,7 +163,7 @@
  * compatibility, we'll duplicate the 1.2 private member var.
  */
 protected ClassLoader parent;
-
+
 /**
  * Private class used to maintain information about the classes that
  * we loaded.
@@ -194,7 +194,7 @@
 return origin == null;
 }
 }
-
+
 //--- Constructors
 
 /**
@@ -215,7 +215,7 @@
cache = new Hashtable();
 }
 
-public void setRepository( Vector classRepository ) 
+public void setRepository( Vector classRepository )
throws IllegalArgumentException
 {
// Verify that all the repository are valid.
@@ -275,7 +275,7 @@
 void log( String s ) {
System.out.println(AdaptiveClassLoader:  + s );
 }
-
+
 //--- Methods
 
 /**
@@ -326,7 +326,7 @@
 return false;
 } else {
 return (entry.origin.lastModified() != entry.lastModified);
-
+
 }
 }
 
@@ -348,7 +348,7 @@
if( debug5 )
log( cache entry:  + entry.loadedClass.getName());
if (entry.isSystemClass()) continue;
-   
+
 // XXX: Because we want the classloader to be an accurate
 // reflection of the contents of the repository, we also
 // reload if a class origin file is now missing.  This
@@ -381,7 +381,7 @@
  */
 public AdaptiveClassLoader reinstantiate() {
 AdaptiveClassLoader cl=new AdaptiveClassLoader();
-   cl.setParent(parent); 
+   cl.setParent(parent);
cl.setRepository(repository);
return cl;
 }
@@ -435,7 +435,7 @@
 if (sm != null) {
 int i = name.lastIndexOf('.');
 if (i = 0) {
-sm.checkPackageAccess(name.substring(0,i)); 
+sm.checkPackageAccess(name.substring(0,i));
 sm.checkPackageDefinition(name.substring(0,i));
}
}
@@ -502,10 +502,10 @@
 classCache.lastModified = classCache.origin.lastModified();
if( debug0) log( Add to cache()  + name +   + classCache);
cache.put(name, classCache);
-   
+
if( debug0) log( Before define class  + name);
try {
-   classCache.loadedClass = 
+   classCache.loadedClass =
doDefineClass(name, classData,
  cp.getProtectionDomain());
} catch(Throwable t ) {
@@ -529,7 +529,7 @@
 {
return  defineClass(name, classData, 0, classData.length);
 }
-
+
 /**
  * Load a class using the system classloader.
  *
@@ -782,54 +782,76 @@
 }
 
 // Third, check our own

Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/classes

[David Haraburda]

Oops,

That's right, you can read any file you want from WEB-INF/classes using
getResource() (which is probably what you are doing) -- that is implemented
correctly in AdaptiveClassLoader.  If you want to find all resources of a
specified name (for example, you have a properties file of the same name at
the web-application level and the system level, and you want to concatenate
values from both places together), the ClassLoader class provides a
getResources() method.  (This method in turn calls findResources which is
supposed to be implemented in all subclasses of ClassLoader, but isn't for
AdaptiveClassLoader)

I'm glad to know that fixed it.

David

Will England wrote:

 On Fri, 20 Jul 2001, David Haraburda wrote:

  Have you tried using the Jdk12Interceptor?  That fixed class loading
  problems for me.  In your server.xml do:
 
  RequestInterceptor
  className=org.apache.tomcat.request.Jdk12Interceptor/

 Got that, and it fixed the finding of my .conf files that I store in
 WEB-INF/classes.  I can now read any text file I want from WEB-INF/classes
 from a servlet.

  Note this will only fix the loading of CLASSES... if you have resources
  in your WEB-INF/classes directory, such as .properties files, that the
  ClassLoader is supposed to pick up, this will not happen.  I submitted a
  patch for this to the mailing list last night, but haven't heard
  anything from a developer/committer yet.

 Odd.  Worked well for me.  As soon as the admin gets the box back up, I'll
 drop you a copy of my server.xml and the code I use to read a text file.

  A good way to see what ClassLoader is being used is by sticking in a
  System.out.println( CL:  +
  Thread.currentThread().getContextClassLoader().toString() );
 
  If it says com.sun.misc.something (I forget the package name), you are
  using the System classloader... if it says AdaptiveClassLoader, you are
  using the Tomcat one which knows about stuff in the WEB-INF directory.

 Nice tip - I'll try that!

 Will

Re: [DOC] Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/class es

[David Haraburda]

I don't think unsetting your CLASSPATH is necessary, especially since other
applications may rely on it.  I would guess that most problems occur when:

1) You add things you have in your WEB-INF/classes to your CLASSPATH (thus causing them
to be loaded by the system class loader, not the Tomcat web app class loader, which
causes problems)

or, as the case would appear to be with the POET sdk referred to before,

2) Your web application requires a certain JAR that you have placed in your WEB-INF/lib
directory, but unbeknownst to you, there is actually another JAR (perhaps an older
version of the software) sitting in your classpath, which gets loaded first.

Remember, a classloader always asks it's parent classloader to load a resource first,
and then only loads it itself if the parent cannot find it.

Just make sure things your web application requires are in your WEB-INF/libs directory,
and not in your classpath.

Craig McClanahan has two good posts about this:

http://mikal.org/interests/java/tomcat/archive/view?mesg=22444
http://mikal.org/interests/java/tomcat/archive/view?mesg=8512

As far as logging goes, you may want to check out the Logger elements is your
server.xml file. They provide a good way to keep your terminal un-cluttered. :-)

David

David Rees wrote:

 On Fri, Jul 20, 2001 at 06:22:21AM -0700, Rob S. wrote:
  A, maybe I should add this to the INSTALL.txt file - unset your
  CLASSPATH before starting TC?  I've logged into my fair share of *nix boxes
  where the admins have conveniently set a system-wide CLASSPATH containing an
  XML parser, etc.

 I think it's the safe thing to do.  I think Tomcat 3.3 and Tomcat 4 both do this by
 default.  For Tomcat 3.2.X, I do this in custom startup scripts which make
 startup/shutdown a lot easier if you're maintaining multiple copies of Tomcat per
 host.  I also modify bin/tomcat.sh to redirect stdout/err to log files instead of
 cluttering the terminal.  If anyone is interested, I can send copies of the scripts
 and the patch to tomcat.sh...

 I would at least like to see the stdout/err patch integrated into Tomcat, I just
 don't know if there's much interest in including it into Tomcat 3.2.

 -Dave

AdaptiveClassLoader, getResources, jndi.properties (Tomcat bug?)

[David Haraburda]

Hi,

I got no response to this message on the tomcat-user list, so I am
trying here.  I could find nothing in the archives except the message I
refer to below -- I apologize if this issue has been addressed and I
just couldn't find the info...

I am having problems with jndi.properties being read from my
WEB-INF/classes directory.  I have seen this problem referenced once on
the tomcat-dev mailing list -- someone submitted a patch, but apparently

it did not get committed.  (I couldn't find a reason why, so I am not
sure if that was the real solution to the problem or not).  The original

message is here:
http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg06588.html

I have verified that the same behaivor he refers to is going on with my
application -- InitialContext is using getResources(), which doesn't
return anything becuase AdaptiveClassLoader doesn't implement
findResource or findResources.

Has anyone else having this problem found a solution/work-around?  Is
there a Tomcat guru/developer out there who can explain why
AdaptiveClassLoader doesn't implement findResources()?

Thanks,

David

Re: AdaptiveClassLoader, getResources, jndi.properties (Tomcat bug?)

[David Haraburda]

Hi,

Thanks for responding.  As far as I can tell this is a problem with Tomcat...
AdaptiveClassLoader doesn't override findResources, which is causing the
problem.  I am digging through the source, and here is what happens when you
instantiate an InitialContext object:

InitialContext.init(null) is called, which calls
ResourceManager.getInitialEnvironment(null)

At this point, ResourceManager is going to load any JNDI properties it can
find.  After getInitialEnvironment checks the system properties, it then
attempts to load application resources, by calling

ResourceManager.getApplicationResources()

This method will load resources with a ClassLoader of course, and it gets the
class loader from the current thread by calling
VersionHelper12.getContextClassLoader().  Because I am using Jdk12Interceptor,
it will return AdaptiveClassLoader.  This is where the important stuff
happens.  It will look for the JNDI properties file by calling getResources().
This is a final method on java.lang.ClassLoader that calls findResources()...

The JavaDoc states that ClassLoader implementations should override this method
to load resources.  AdaptiveClassLoader doesn't.  Why not? :)

I can submit a patch, but it looks like someone else already did awhile back...
I wondered why it wasn't applied, and thought maybe I missed something?  If I
patch is needed, let me know, I can get one to this list tonight...

Thanks again,
David

Rob S. wrote:

 If this is what I'm remembering, your ContextFactory class can't be found.
 This is cuz the JNDI code is broken in that it doesn't rely on its parent
 classloader (in our case, the one that knows about WEB-INF/classes and lib)
 to load the context factory.

 You have to implement your own InitialContextFactoryBuilder.  Check the Sun
 messages boards.  I ran into the same problem last month.

 - r

  -Original Message-
  From: David Haraburda [mailto:[EMAIL PROTECTED]]
  Sent: Thursday, July 19, 2001 10:51 AM
  To: [EMAIL PROTECTED]
  Subject: AdaptiveClassLoader, getResources, jndi.properties (Tomcat
  bug?)
 
 
  Hi,
 
  I got no response to this message on the tomcat-user list, so I am
  trying here.  I could find nothing in the archives except the message I
  refer to below -- I apologize if this issue has been addressed and I
  just couldn't find the info...
 
  I am having problems with jndi.properties being read from my
  WEB-INF/classes directory.  I have seen this problem referenced once on
  the tomcat-dev mailing list -- someone submitted a patch, but apparently
 
  it did not get committed.  (I couldn't find a reason why, so I am not
  sure if that was the real solution to the problem or not).  The original
 
  message is here:
  http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg06588.html
 
  I have verified that the same behaivor he refers to is going on with my
  application -- InitialContext is using getResources(), which doesn't
  return anything becuase AdaptiveClassLoader doesn't implement
  findResource or findResources.
 
  Has anyone else having this problem found a solution/work-around?  Is
  there a Tomcat guru/developer out there who can explain why
  AdaptiveClassLoader doesn't implement findResources()?
 
  Thanks,
 
  David