Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
To: tomcat-dev@jakarta.apache.org
From: Costin Manolache <cmanolache@yahoo.com>
Subject: RE: jakarta-tomcat-connectors tag ?
Date: Sat, 03 May 2003 07:07:23 -0700
Lines: 64
Message-ID: <b90ic4$jg2$1@main.gmane.org>
References: <b8vp9k$nl5$2@main.gmane.org>
 <000301c31150$72e545f0$9a89bfd5@GISDATA.ZG>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
User-Agent: KNode/0.7.2
Sender: news <news@main.gmane.org>

Mladen Turk wrote:

> Fom Costin Manolache
>> > 
>> > What about JNI in JK2?
>> > The tomcat-jni is now dependant to commons-modeler, jmx, etc..., so
>> > we'll need to either change that or document as so.
>> 
>> What would you preffer ?
>>
> Nice blonde ;-)

Not sure you'll find her on tomcat-dev, but keep looking :-)

>> IMO JMX is the best way to load the components - so I would
>> rather have ( long term ) the jni code load jmx + modeler + a
>> mlet.xml file, with no
>> dep on tomcat/jtc. It seems much cleaner and consistent with the way
>> tomcat5 should be embeded ( again, IMHO ).
> 
> Agreed. I was thinking to make something lightweight in front, instead
> TomcatStarter.
> The name would be JNIClassLoader, and will be as LauncherBootsrap (the
> single class file).
> This way we'll be able to use the TC even from 'dirty' jvm.

+1 - TomcatStarter started as a hack. 

My long-term preference would be for the startup ( in all cases: JNI,
standalone, embeded  ) to be driven by JMX + modeler + MLET-like file.
A small Launcher that adds JMX, modeler and other jars to a common loader
would be nice for all cases ( it doesn't need to be JNI specific ).


> Also we'll not need the tomcat-jni any more, cause the Jk will be used
> from tomcat-jk2.

Big +1, I had only problems with tomcat-jni. The sooner we remove it, the 
better. ( it duplicate classes, creates weird endorsed problems, etc ).

( I still remember I wrote tomcat-jni trying to simplify the startup - big
mistake :-)


> The current 'classpath' vm options would be used as URLClassLoader and
> URL[]'s will be set by calling
> native methods (instead of parsing properties file as LauncherBootsrap
> does).

I think requiring the user to place a real CLASSPATH would be acceptable.
Or just using a very small .jar with a ClassPath attribute and a main that
just calls the real startup.

 
> The only problem I had to solve I _when_ to register the natives for
> AprImpl.

The other problem is _when_ will this happen - I was hoping to tag j-t-c 
at about the same time with 5.0.2 - so it can get more testing and get us
a consistent connector, regardless of tomcat version. 

Does adding modeler, jmx to the classpath work ? 

Costin


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org