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:   
For additional commands, e-mail: 

[PATCH] Tyrex 1.0 w/ Tomcat

[David Haraburda]

 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.
+ *
  * Tyrex is an open-source transaction manager, developed by Assaf Arkin and
  * exolab.org. See the http://tyrex.exolab.org/";>Tyrex homepage
  * 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. Redistributions of source code must retain the above copyright
 *notice, this list of conditio

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:   
> For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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:   
For additional commands, e-mail: 

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:   
> > For additional commands, e-mail: 
> > 
> > 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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:   
> For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[David Haraburda]

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.

Hope this helps others with the same problem.

Thanks,

David Haraburda



--- ContextBindings.javaFri May 10 21:30:30 2002
+++ ContextBindings.dharaburda.java Tue May 28 02:38:28 2002
@@ -345,12 +345,14 @@
  */
 public static Context getClassLoader()
 throws NamingException {
-Context context = (Context) clBindings.get
-(Thread.currentThread().getContextClassLoader());
-if (context == null)
+ClassLoader cl = Thread.currentThread().getContextClassLoader();
+Context context = null;
+do {
+  context = (Context) clBindings.get(cl);
+  if( context != null ) return context;
+} while( (cl = cl.getParent()) != null );
 throw new NamingException
 (sm.getString("contextBindings.noContextBoundToCL"));
-return context;
 }
 
 
@@ -359,12 +361,14 @@
  */
 static Object getClassLoaderName()
 throws NamingException {
-Object name = 
-clNameBindings.get(Thread.currentThread().getContextClassLoader());
-if (name == null)
+ClassLoader cl = Thread.currentThread().getContextClassLoader();
+Object name = null;
+do {
+  name = clNameBindings.get(cl);
+  if( name != null ) return name;
+} while( (cl = cl.getParent()) != null );
 throw new NamingException
 (sm.getString("contextBindings.noContextBoundToCL"));
-return name;
 }
 
 
@@ -372,8 +376,11 @@
  * Tests if current class loader is bound to a context.
  */
 public static boolean isClassLoaderBound() {
-return (clBindings.containsKey
-(Thread.currentThread().getContextClassLoader()));
+ClassLoader cl = Thread.currentThread().getContextClassLoader();
+do {
+if( clBindings.containsKey(cl) ) return true;
+} while( (cl = cl.getParent()) != null );
+return false;
 }
 
 



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

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  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

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:
> >
> >  > 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: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/classes

[David Haraburda]

Hi,

I too missed the original message, but have been dealing with these
problems myself.

Have you tried using the Jdk12Interceptor?  That fixed class loading
problems for me.  In your server.xml do:



There are some weird classloader issues w/ Java 2 that this fixes.

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.

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.

David

Will England wrote:
> 
> On Thu, 19 Jul 2001, David Rees wrote:
> 
> > (Sorry about the double-qoute, I missed the original message)
> >
> >
> > I have noticed the same problem while doing some development using
> > Tomcat 3.2.[23].  I worked around it by making sure that I unset the
> > classpath before calling startup.sh, then things seemed to work properly
> > and classes were found as expected.
> 
> Tried that.  Tried hard-coding the classpath.  If the web applications
> WEB-INF/classes directory was in the system classpath, it compiles.  If it
> is not in the system classpath, the JSP's do not compile.
> 
> So, why does Jasper not know about the web-application classpath?
> 
> Will

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

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( debug>5 )
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( debug>0) log( "Add to cache() " + name + " " + classCache);
cache.put(name, classCache);
-   
+
if( debug>0) log( "Before define class " + name);
try {
-   classCache.loadedClass = 
+   classCache.loadedClass =
doDefineClass(name, classData,
  cp.getProtectionDomain(

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( debug>5 )
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
  

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
> >
> >

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