You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Takashi Okamoto <to...@kun.ne.jp> on 2001/12/01 14:38:36 UTC
[PATCH] about kjc
Hi, tomcat users and developrs!
/* I have post this patch twice. This is third time. */
Do you know kjc which is one of the completely opensource Java
compiler? If not, you can see detail at http://www.dms.at/kopi.
Accoding to Edouard G. Parmelan's report
(http://rpmfind.net/tools/Kaffe/messages/1291.html), KJC HAVE BEATEN
SUN'S JAVA COMPILER since version 1.5 about JLS compatibility. It was
a grate news for Java open source community;)
I and teik-san (san means Mr. in Japanese) wrote two kjc plugin for
tomcat. One is for 3.3.x, and the other is for 4.0.x. If you take kjc
plugin, it's good advertisement and help for kjc. Do you respect
opensource? If so, could you take them?
BTW, kjc is distributed under GPL. But you can take these patch in
legal. Because you don't need to include kjc in tomcat. When you want to
use kjc, only then you have to include it. In the fact, I wrote kjc
plugin for Ant and it's really in it. So, you can also use kjc with
Ant fine:)
PS.
usage for tomcat 4.0.x:
download kjc.jar from http://www.dms.at/kopi and include it in
common/lib.
add specify jspCompilerPlugin at web.xml. For examples.
<servlet>
<servlet-name>jsp</servlet-name>
<servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
<init-param>
<param-name>logVerbosityLevel</param-name>
<param-value>WARNING</param-value>
</init-param>
<init-param>
<param-name>jspCompilerPlugin</param-name>
<param-value>org.apache.jasper.compiler.KjcJavaCompiler</param-value>
</init-param>
<load-on-startup>3</load-on-startup>
</servlet>
Cheers for opensource!!
-----
Takashi Okamoto Debian Project: http://www.debian.org/
tora@debian.org Ja-Jakarta Project: http://www.ingrid.org/jajakarta/
GnuPG: 8B37 1FE6 76B2 7BA6 D59A 9BF7 E7F4 46C8 5293 6E17
Re: [PATCH] about kjc
Posted by Peter Donald <pe...@apache.org>.
On Sun, 2 Dec 2001 08:03, Jon Stevens wrote:
> on 12/1/01 10:08 AM, "Remy Maucherat" <re...@apache.org> wrote:
> >> Hi, tomcat users and developrs!
> >>
> >> /* I have post this patch twice. This is third time. */
> >>
> >> Do you know kjc which is one of the completely opensource Java
> >> compiler? If not, you can see detail at http://www.dms.at/kopi.
> >>
> >> Accoding to Edouard G. Parmelan's report
> >> (http://rpmfind.net/tools/Kaffe/messages/1291.html), KJC HAVE BEATEN
> >> SUN'S JAVA COMPILER since version 1.5 about JLS compatibility. It was
> >> a grate news for Java open source community;)
> >>
> >> I and teik-san (san means Mr. in Japanese) wrote two kjc plugin for
> >> tomcat. One is for 3.3.x, and the other is for 4.0.x. If you take kjc
> >> plugin, it's good advertisement and help for kjc. Do you respect
> >> opensource? If so, could you take them?
> >>
> >>
> >> BTW, kjc is distributed under GPL. But you can take these patch in
> >> legal. Because you don't need to include kjc in tomcat. When you want to
> >> use kjc, only then you have to include it. In the fact, I wrote kjc
> >> plugin for Ant and it's really in it. So, you can also use kjc with
> >> Ant fine:)
> >
> > +1 for this patch as it is legal since it uses reflection.
> >
> > Remy
>
> I thought that using reflection to work with GPL code was still considered
> illegal by the FSF.
Depends on exactly it is used from my understanding. If you use reflection
but still directly integrate with the GPL work such that there is no chance
that the GPL layer could be replaced with something else or your code can not
run in GPL free mode then it is considered no different from directly linking
against it.
Note that if you use the "main()" interface that is considered okay last time
I checked. However if you need to bind against the innards of the compiler
then one option is to do the following. Create an interface layer and place
it under a GPL compatible license (MIT, BSDL or whatever) and program against
that interface. Then add some code to GPL work so that it implements
interface.
--
Cheers,
Pete
---------------------------------------------------
Murphy's law - "Anything that can go wrong, will."
(Actually, this is Finagle's law, which in itself
shows that Finagle was right.)
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] about kjc
Posted by Remy Maucherat <re...@apache.org>.
> On Sat, 1 Dec 2001, Jon Stevens wrote:
>
> > > +1 for this patch as it is legal since it uses reflection.
> > >
> > > Remy
> >
> > I thought that using reflection to work with GPL code was still
considered
> > illegal by the FSF.
>
> As long ASF/jakarta doesn't have a list of 'accepted licences' that we can
> include/bundle with our code, and most jakarta projects already
> depend/bundle lots of proprietary code, I don't see why this patch would
> be a problem. It doesn't require us to distribute GPL code.
Yes, I don't really see any problem here. If the ASF feels it's still not
OK, then I'll remove the file (it's fully independent from the rest).
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] about kjc
Posted by cm...@yahoo.com.
On Sat, 1 Dec 2001, Jon Stevens wrote:
> > +1 for this patch as it is legal since it uses reflection.
> >
> > Remy
>
> I thought that using reflection to work with GPL code was still considered
> illegal by the FSF.
As long ASF/jakarta doesn't have a list of 'accepted licences' that we can
include/bundle with our code, and most jakarta projects already
depend/bundle lots of proprietary code, I don't see why this patch would
be a problem. It doesn't require us to distribute GPL code.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] about kjc
Posted by Jon Stevens <jo...@latchkey.com>.
on 12/1/01 10:08 AM, "Remy Maucherat" <re...@apache.org> wrote:
>> Hi, tomcat users and developrs!
>>
>> /* I have post this patch twice. This is third time. */
>>
>> Do you know kjc which is one of the completely opensource Java
>> compiler? If not, you can see detail at http://www.dms.at/kopi.
>>
>> Accoding to Edouard G. Parmelan's report
>> (http://rpmfind.net/tools/Kaffe/messages/1291.html), KJC HAVE BEATEN
>> SUN'S JAVA COMPILER since version 1.5 about JLS compatibility. It was
>> a grate news for Java open source community;)
>>
>> I and teik-san (san means Mr. in Japanese) wrote two kjc plugin for
>> tomcat. One is for 3.3.x, and the other is for 4.0.x. If you take kjc
>> plugin, it's good advertisement and help for kjc. Do you respect
>> opensource? If so, could you take them?
>>
>>
>> BTW, kjc is distributed under GPL. But you can take these patch in
>> legal. Because you don't need to include kjc in tomcat. When you want to
>> use kjc, only then you have to include it. In the fact, I wrote kjc
>> plugin for Ant and it's really in it. So, you can also use kjc with
>> Ant fine:)
>
> +1 for this patch as it is legal since it uses reflection.
>
> Remy
I thought that using reflection to work with GPL code was still considered
illegal by the FSF.
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] about kjc
Posted by Remy Maucherat <re...@apache.org>.
> Hi, tomcat users and developrs!
>
> /* I have post this patch twice. This is third time. */
>
> Do you know kjc which is one of the completely opensource Java
> compiler? If not, you can see detail at http://www.dms.at/kopi.
>
> Accoding to Edouard G. Parmelan's report
> (http://rpmfind.net/tools/Kaffe/messages/1291.html), KJC HAVE BEATEN
> SUN'S JAVA COMPILER since version 1.5 about JLS compatibility. It was
> a grate news for Java open source community;)
>
> I and teik-san (san means Mr. in Japanese) wrote two kjc plugin for
> tomcat. One is for 3.3.x, and the other is for 4.0.x. If you take kjc
> plugin, it's good advertisement and help for kjc. Do you respect
> opensource? If so, could you take them?
>
>
> BTW, kjc is distributed under GPL. But you can take these patch in
> legal. Because you don't need to include kjc in tomcat. When you want to
> use kjc, only then you have to include it. In the fact, I wrote kjc
> plugin for Ant and it's really in it. So, you can also use kjc with
> Ant fine:)
+1 for this patch as it is legal since it uses reflection.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] about kjc
Posted by Takashi Okamoto <to...@kun.ne.jp>.
At Sun, 2 Dec 2001 15:19:05 -0800 (PST),
Craig R. McClanahan <cr...@apache.org> wrote:
> I looked at this option a little bit a while back, and have only one
> concern -- multiple threads trying to compile at the same time. Ant tasks
> generally assume that they don't need to worry about thread safety issues,
> so we need to review this code carefully. (Of course, this issue applies
> even more so to the "new" Javac entry point in 1.4 -- it writes error
> messages to System.out).
Well, I refered org.apache.tools.ant.taskdefs.compilers.Javac13.java
Class c = Class.forName ("com.sun.tools.javac.Main");
Object compiler = c.newInstance ();
Method compile = c.getMethod ("compile",
new Class [] {(new String [] {}).getClass ()});
int result = ((Integer) compile.invoke
(compiler, new Object[] {cmd.getArguments()})) .intVal
ue ();
So, above code shows that compiler output messages to System.out. Some
of other compilers are same as Jikes13.java. They are thread-unsafe.
They should be locked.
----
Takashi Okamoto
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AJP Todo
Posted by Bill Barker <wb...@wilshire.com>.
The ${Server}Config files are about as good as I can get them. Any
remaining improvements would require someone that knows more about Catalina
than I do. The main improvement that I can think of would require an API
change in Catalina, but this configuration method will likely be obsolete by
the time 4.1 rolls out (thanks to Costin and Henri).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AJP Todo
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Monday, December 10, 2001 8:59 PM
Subject: Re: AJP Todo
>
>
> On Mon, 10 Dec 2001, Bill Barker wrote:
>
> > Date: Mon, 10 Dec 2001 20:00:35 -0800
> > From: Bill Barker <wb...@wilshire.com>
> > Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> > To: Tomcat Developers List <to...@jakarta.apache.org>
> > Subject: Re: AJP Todo
> >
> >
> > ----- Original Message -----
> > From: "Incze Lajos" <in...@mail.matav.hu>
> > To: "Tomcat Developers List" <to...@jakarta.apache.org>
> > Sent: Monday, December 10, 2001 8:02 AM
> > Subject: Re: AJP Todo
> >
> >
> > > What's wrong with this? (ServletContext method javadoc both 2.2 and
2.3)
> >
> > Absolutely nothing. And indeed this is the route I took, since looking
at
> > the code showed that the Naming methods still didn't guarantee an
absolute
> > path and this one always returns null for non-file-based contexts.
> >
>
> That's because there *is* no such thing as an absolute path for an entry
> inside a WAR file. Talk to your favorite OS vendor about that one.
Don't get so touchy :). I'm certainly not going to criticize Tomcat 4.x
when I'm the first to admit that I don't know it very well. I was actually
referring to FileDirContext.getNameInNamespace when I was talking about
non-absolute paths. As it is now, ${Server}Config does a forwardAll if the
Context is defined by a WAR file.
>
> > Now if I can just find someone to Listen to, I'll be done :).
>
> What is it you think should be changed?
I don't know about "changed". I'll simply describe the problem I'm facing.
A lot of users simply want to include one ApacheConfig statement in the
server.xml, include that file in the httpd.conf file and forget about it.
In order to get the configuration info, I need to Listen to somebody who
fires the START_EVENT at the end of Lifecycle.start (e.g. Container and
derived). This leaves Host as the highest level I can Listen to. However,
there are some one-time-only entries in the file that can't be repeated, so
Host doesn't work so well for simple configurations. I'd really like Server
(since it is a singleton), but Server fires it's event at the beginning, so
the sub-elements aren't configured yet. At the moment, I'm thinking that if
I'm Listening to a Server, I'll write the one-time-only information. Then
you'll have to Listen to any Host or Context that you want configured as
well.
>
> Craig
>
>
> > > ----
> > > getRealPath
> > >
> > > public java.lang.String getRealPath(java.lang.String path)
> > >
> > > Returns a String containing the real path for a given virtual path.
> > > For example, the path "/index.html" returns the absolute file path
> > > on the server's filesystem would be served by a request for
> > > "http://host/contextPath/index.html", where contextPath is the context
> > > path of this ServletContext..
> > >
> > > The real path returned will be in a form appropriate to the computer
and
> > > operating system on which the servlet container is running, including
the
> > > proper path separators. This method returns null if the servlet
container
> > > cannot translate the virtual path to a real path for any reason (such
as
> > > when the content is being made available from a .war archive).
> > > -----
> > > So, getServletContext().getRealPath( "/" )
> > >
> > > incze
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AJP Todo
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 10 Dec 2001, Bill Barker wrote:
> Date: Mon, 10 Dec 2001 20:00:35 -0800
> From: Bill Barker <wb...@wilshire.com>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: Tomcat Developers List <to...@jakarta.apache.org>
> Subject: Re: AJP Todo
>
>
> ----- Original Message -----
> From: "Incze Lajos" <in...@mail.matav.hu>
> To: "Tomcat Developers List" <to...@jakarta.apache.org>
> Sent: Monday, December 10, 2001 8:02 AM
> Subject: Re: AJP Todo
>
>
> > What's wrong with this? (ServletContext method javadoc both 2.2 and 2.3)
>
> Absolutely nothing. And indeed this is the route I took, since looking at
> the code showed that the Naming methods still didn't guarantee an absolute
> path and this one always returns null for non-file-based contexts.
>
That's because there *is* no such thing as an absolute path for an entry
inside a WAR file. Talk to your favorite OS vendor about that one.
> Now if I can just find someone to Listen to, I'll be done :).
What is it you think should be changed?
Craig
> > ----
> > getRealPath
> >
> > public java.lang.String getRealPath(java.lang.String path)
> >
> > Returns a String containing the real path for a given virtual path.
> > For example, the path "/index.html" returns the absolute file path
> > on the server's filesystem would be served by a request for
> > "http://host/contextPath/index.html", where contextPath is the context
> > path of this ServletContext..
> >
> > The real path returned will be in a form appropriate to the computer and
> > operating system on which the servlet container is running, including the
> > proper path separators. This method returns null if the servlet container
> > cannot translate the virtual path to a real path for any reason (such as
> > when the content is being made available from a .war archive).
> > -----
> > So, getServletContext().getRealPath( "/" )
> >
> > incze
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AJP Todo
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Incze Lajos" <in...@mail.matav.hu>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Monday, December 10, 2001 8:02 AM
Subject: Re: AJP Todo
> What's wrong with this? (ServletContext method javadoc both 2.2 and 2.3)
Absolutely nothing. And indeed this is the route I took, since looking at
the code showed that the Naming methods still didn't guarantee an absolute
path and this one always returns null for non-file-based contexts.
Now if I can just find someone to Listen to, I'll be done :).
> ----
> getRealPath
>
> public java.lang.String getRealPath(java.lang.String path)
>
> Returns a String containing the real path for a given virtual path.
> For example, the path "/index.html" returns the absolute file path
> on the server's filesystem would be served by a request for
> "http://host/contextPath/index.html", where contextPath is the context
> path of this ServletContext..
>
> The real path returned will be in a form appropriate to the computer and
> operating system on which the servlet container is running, including the
> proper path separators. This method returns null if the servlet container
> cannot translate the virtual path to a real path for any reason (such as
> when the content is being made available from a .war archive).
> -----
> So, getServletContext().getRealPath( "/" )
>
> incze
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AJP Todo
Posted by Incze Lajos <in...@mail.matav.hu>.
On Sun, Dec 09, 2001 at 08:24:35PM -0800, Bill Barker wrote:
...
> (b) For a context defined in the server.xml, there seems to be no public way
> to determine the document base as an absolute path. This may just be my
> lack of familiarity with Catalina however. On a related note, I wasn't able
> to find any way to determine if a Context even has a document base (as
> opposed to a war file).
>
What's wrong with this? (ServletContext method javadoc both 2.2 and 2.3)
----
getRealPath
public java.lang.String getRealPath(java.lang.String path)
Returns a String containing the real path for a given virtual path.
For example, the path "/index.html" returns the absolute file path
on the server's filesystem would be served by a request for
"http://host/contextPath/index.html", where contextPath is the context
path of this ServletContext..
The real path returned will be in a form appropriate to the computer and
operating system on which the servlet container is running, including the
proper path separators. This method returns null if the servlet container
cannot translate the virtual path to a real path for any reason (such as
when the content is being made available from a .war archive).
-----
So, getServletContext().getRealPath( "/" )
incze
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AJP Todo
Posted by Remy Maucherat <re...@apache.org>.
> >
> > If the web app is deployed as a directory, you can call
> > context.getDocBase() for this. If the context is deployed as a WAR
file,
> > there is no such thing as the "document base as an absolute path". In
> > such a scenario, you need to choose one of the following options:
> Unfortunately, if the context is declared in server.xml, getDocBase
returns
> the docBase declared in server.xml (e.g. "examples" in the shipping
> server.xml). I can't see how to turn this into an absolute path.
> >
> > * Forward *all* requests to Tomcat for processing
> This is my preference. The problem is determining if it is deployed as a
> WAR file or not given the context. This one is probably just my stupidity
> however :).
You should be able to use Context.getResource and then use instanceof to see
if it's a FileDirContext, a WARDirContext or something else altogether (in
which case, you should do the same as if it was a WAR, I think).
> > * Reject a webapp that is deployed this way
Please don't do that :)
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AJP Todo
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Sunday, December 09, 2001 8:29 PM
Subject: Re: AJP Todo
>
> If the web app is deployed as a directory, you can call
> context.getDocBase() for this. If the context is deployed as a WAR file,
> there is no such thing as the "document base as an absolute path". In
> such a scenario, you need to choose one of the following options:
Unfortunately, if the context is declared in server.xml, getDocBase returns
the docBase declared in server.xml (e.g. "examples" in the shipping
server.xml). I can't see how to turn this into an absolute path.
>
> * Forward *all* requests to Tomcat for processing
This is my preference. The problem is determining if it is deployed as a
WAR file or not given the context. This one is probably just my stupidity
however :).
>
> * Reject a webapp that is deployed this way
>
> Craig
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AJP Todo
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 9 Dec 2001, Bill Barker wrote:
> Date: Sun, 9 Dec 2001 20:24:35 -0800
> From: Bill Barker <wb...@wilshire.com>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: Tomcat Developers List <to...@jakarta.apache.org>
> Subject: Re: AJP Todo
>
> I've just checked in an initial port of ${Server}Config for 4.x into j-t-c.
> The problems I'm having at the moment are:
> (a) While Container fires the start-event at the end, Server fires it at the
> beginning. As a result, I can't really have this as a Server Listener as I
> would like.
> (b) For a context defined in the server.xml, there seems to be no public way
> to determine the document base as an absolute path. This may just be my
> lack of familiarity with Catalina however. On a related note, I wasn't able
> to find any way to determine if a Context even has a document base (as
> opposed to a war file).
If the web app is deployed as a directory, you can call
context.getDocBase() for this. If the context is deployed as a WAR file,
there is no such thing as the "document base as an absolute path". In
such a scenario, you need to choose one of the following options:
* Forward *all* requests to Tomcat for processing
* Reject a webapp that is deployed this way
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AJP Todo
Posted by Bill Barker <wb...@wilshire.com>.
I've just checked in an initial port of ${Server}Config for 4.x into j-t-c.
The problems I'm having at the moment are:
(a) While Container fires the start-event at the end, Server fires it at the
beginning. As a result, I can't really have this as a Server Listener as I
would like.
(b) For a context defined in the server.xml, there seems to be no public way
to determine the document base as an absolute path. This may just be my
lack of familiarity with Catalina however. On a related note, I wasn't able
to find any way to determine if a Context even has a document base (as
opposed to a war file).
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Sunday, December 02, 2001 4:17 PM
Subject: Re: AJP Todo
>
>
> On Sat, 1 Dec 2001, Bill Barker wrote:
>
> > Date: Sat, 1 Dec 2001 17:17:31 -0800
> > From: Bill Barker <wb...@wilshire.com>
> > Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> > To: Tomcat Developers List <to...@jakarta.apache.org>
> > Subject: Re: AJP Todo
> >
> > I have no objection to help porting ${Server}Config to 4.x, but I'm
still a
> > Catalina novice. The 3.3 API is more command and control, so it is
easier
> > to get to the information.
>
> +0 on "officially" supporting AJP in tomcat 4.x, as has been discussed
> (i.e. I favor the idea, but cannot help).
>
> > It will take me a little time to find out how to
> > get the servlet-mappings in Catalina.
>
> Nearly all of the configuration-related information related to a web
> application is available via "getXxx" or "findXxx" methods on the
> org.apache.catalina.context.Context interface. For servlet mappings in
> particular, you can look up the mapping for a particular pattern with
> findServletMapping(), or get all the defined mapping patterns with
> findServletMappings().
>
> There are similar methods available to access all the other stuff that was
> configured in web.xml (or, in some cases, from server.xml).
>
> Craig
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AJP Todo
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sat, 1 Dec 2001, Bill Barker wrote:
> Date: Sat, 1 Dec 2001 17:17:31 -0800
> From: Bill Barker <wb...@wilshire.com>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: Tomcat Developers List <to...@jakarta.apache.org>
> Subject: Re: AJP Todo
>
> I have no objection to help porting ${Server}Config to 4.x, but I'm still a
> Catalina novice. The 3.3 API is more command and control, so it is easier
> to get to the information.
+0 on "officially" supporting AJP in tomcat 4.x, as has been discussed
(i.e. I favor the idea, but cannot help).
> It will take me a little time to find out how to
> get the servlet-mappings in Catalina.
Nearly all of the configuration-related information related to a web
application is available via "getXxx" or "findXxx" methods on the
org.apache.catalina.context.Context interface. For servlet mappings in
particular, you can look up the mapping for a particular pattern with
findServletMapping(), or get all the defined mapping patterns with
findServletMappings().
There are similar methods available to access all the other stuff that was
configured in web.xml (or, in some cases, from server.xml).
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AJP Todo
Posted by co...@covalent.net.
On Sat, 1 Dec 2001, Remy Maucherat wrote:
> > If you want to work on this, it would be great to make it a bit more
> > independent of the container. Right now it is very tightly coupled,
> > in order for it to work you need to start tomcat, it doesn't work very
> > well with context reloads, etc.
>
> I'd leave it being tied to the container, and getting the lifecycle /
> container events. It's (at least it should be) a simple piece of code, and
> although most of the code could be static utility methods, I'd implement the
> wrapper as a listener, instead of a webapp.
A trusted webapp can register listeners ( or should be able to ), it
should be able to register connectors, etc.
Long term we should be able to extract the information
from web.xml without having to fully start tomcat ( and use it as a parser
to extract the servlet mappings, etc ).
> > Well, if you can also port the 'trusted app' - it would be really great.
>
> I said I would, but it will require adding a few method to the Context
> interface (so please, no screaming over API breakage ;-)).
As long as you don't remove methods, I'm ok.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AJP Todo
Posted by Remy Maucherat <re...@apache.org>.
> On Sat, 1 Dec 2001, Bill Barker wrote:
>
> > I have no objection to help porting ${Server}Config to 4.x, but I'm
still a
> > Catalina novice. The 3.3 API is more command and control, so it is
easier
> > to get to the information. It will take me a little time to find out
how to
> > get the servlet-mappings in Catalina.
>
> I'm a bit unhappy with the config generator in 3.3 - I think we can do
> better.
>
> If you want to work on this, it would be great to make it a bit more
> independent of the container. Right now it is very tightly coupled,
> in order for it to work you need to start tomcat, it doesn't work very
> well with context reloads, etc.
I'd leave it being tied to the container, and getting the lifecycle /
container events. It's (at least it should be) a simple piece of code, and
although most of the code could be static utility methods, I'd implement the
wrapper as a listener, instead of a webapp.
> Of course, we don't have any way to change the mappings without restarting
> apache, but that can be fixed as we add more ajp14 features ( jk_uriMap
> can be changed at run time, we just need the protocol support to send
> update requests ).
>
> One idea was to generate a .properties file for each webapp, following the
> same style with webapps/ directory. If a webapp is reloaded we can
> regenerate the app's mappings and get jk to reload only that file.
> We could also use a bit of XSLT or a xmlmapper to do that from web.xml,
> without starting the server. This would allow the configuration to be done
> 'off line'.
> > Tomcat 4. I did bootstrap the porting of the docs already, and I've also
> > fixed the problems with compiling against the CVS HEAD, so I think I've
done
>
> Great, many thanks !
>
> > my part :) If you want to see full support for AJP in TC 4.0.2, it's up
to
> > you guys :)
>
> Well, if you can also port the 'trusted app' - it would be really great.
I said I would, but it will require adding a few method to the Context
interface (so please, no screaming over API breakage ;-)).
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AJP Todo
Posted by co...@covalent.net.
On Sat, 1 Dec 2001, Bill Barker wrote:
> I have no objection to help porting ${Server}Config to 4.x, but I'm still a
> Catalina novice. The 3.3 API is more command and control, so it is easier
> to get to the information. It will take me a little time to find out how to
> get the servlet-mappings in Catalina.
I'm a bit unhappy with the config generator in 3.3 - I think we can do
better.
If you want to work on this, it would be great to make it a bit more
independent of the container. Right now it is very tightly coupled,
in order for it to work you need to start tomcat, it doesn't work very
well with context reloads, etc.
Of course, we don't have any way to change the mappings without restarting
apache, but that can be fixed as we add more ajp14 features ( jk_uriMap
can be changed at run time, we just need the protocol support to send
update requests ).
One idea was to generate a .properties file for each webapp, following the
same style with webapps/ directory. If a webapp is reloaded we can
regenerate the app's mappings and get jk to reload only that file.
We could also use a bit of XSLT or a xmlmapper to do that from web.xml,
without starting the server. This would allow the configuration to be done
'off line'.
Costin
> ----- Original Message -----
> From: "Remy Maucherat" <re...@apache.org>
> To: "Tomcat Developers List" <to...@jakarta.apache.org>
> Sent: Saturday, December 01, 2001 4:40 PM
> Subject: AJP Todo
>
>
> > Hi,
> >
> > On the TODO list for AJP, there is:
> > - Implementing jvmroute.
> > - Adding a mechanism like there is in Tomcat 3.3 to automatically generate
> a
> > configuration file. That should be relatively easy to do using a server
> > listener (or a host listener).
> >
> > I'm not going to do either of these. I have no clue how to do the first
> one,
> > and no time to do the second one.
> > So I'm counting on all the guys who voted +1 for supporting AJP 1.3+ on
> > Tomcat 4. I did bootstrap the porting of the docs already, and I've also
> > fixed the problems with compiling against the CVS HEAD, so I think I've
> done
> > my part :) If you want to see full support for AJP in TC 4.0.2, it's up to
> > you guys :)
> >
> > If people are willing to actively support it, and if the risk for creating
> a
> > security vulnerability is low, we could also enable the AJP 1.3 connector
> > and the server listener by default (and declare it officially supported),
> so
> > that 4.0.2 behaves almost like 3.3 for AJP 1.3 related stuff.
> >
> > Thanks,
> > Remy
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> *----*
>
> This message is intended only for the use of the person(s) listed above
> as the intended recipient(s), and may contain information that is
> PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient,
> you may not read, copy, or distribute this message or any attachment.
> If you received this communication in error, please notify us immediately
> by e-mail and then delete all copies of this message and any attachments.
>
>
> In addition you should be aware that ordinary (unencrypted) e-mail sent
> through the Internet is not secure. Do not send confidential or sensitive
> information, such as social security numbers, account numbers, personal
> identification numbers and passwords, to us via ordinary (unencrypted)
> e-mail.
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AJP Todo
Posted by Bill Barker <wb...@wilshire.com>.
I have no objection to help porting ${Server}Config to 4.x, but I'm still a
Catalina novice. The 3.3 API is more command and control, so it is easier
to get to the information. It will take me a little time to find out how to
get the servlet-mappings in Catalina.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Saturday, December 01, 2001 4:40 PM
Subject: AJP Todo
> Hi,
>
> On the TODO list for AJP, there is:
> - Implementing jvmroute.
> - Adding a mechanism like there is in Tomcat 3.3 to automatically generate
a
> configuration file. That should be relatively easy to do using a server
> listener (or a host listener).
>
> I'm not going to do either of these. I have no clue how to do the first
one,
> and no time to do the second one.
> So I'm counting on all the guys who voted +1 for supporting AJP 1.3+ on
> Tomcat 4. I did bootstrap the porting of the docs already, and I've also
> fixed the problems with compiling against the CVS HEAD, so I think I've
done
> my part :) If you want to see full support for AJP in TC 4.0.2, it's up to
> you guys :)
>
> If people are willing to actively support it, and if the risk for creating
a
> security vulnerability is low, we could also enable the AJP 1.3 connector
> and the server listener by default (and declare it officially supported),
so
> that 4.0.2 behaves almost like 3.3 for AJP 1.3 related stuff.
>
> Thanks,
> Remy
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
*----*
This message is intended only for the use of the person(s) listed above
as the intended recipient(s), and may contain information that is
PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient,
you may not read, copy, or distribute this message or any attachment.
If you received this communication in error, please notify us immediately
by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent
through the Internet is not secure. Do not send confidential or sensitive
information, such as social security numbers, account numbers, personal
identification numbers and passwords, to us via ordinary (unencrypted)
e-mail.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AJP Todo
Posted by co...@covalent.net.
On Sat, 1 Dec 2001 costinm@covalent.net wrote:
> > On the TODO list for AJP, there is:
> > - Implementing jvmroute.
I think I found a way to do it without accessing the Request.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AJP Todo
Posted by co...@covalent.net.
On Sat, 1 Dec 2001, Remy Maucherat wrote:
> Hi,
>
> On the TODO list for AJP, there is:
> - Implementing jvmroute.
Unfortunately that's not that easy. Manager has no way to access the
Request, and that means no way to get the jvmRoute.
The only possible hack is to 'intercept' the cookie header in jk and
rewrite it in both directions ( to extract and insert the jvmroute ).
Pretty ugly, but I see no other way with the current API.
I'll try to do the hack, but I want to first finish the refactoring.
> - Adding a mechanism like there is in Tomcat 3.3 to automatically generate a
> configuration file. That should be relatively easy to do using a server
> listener (or a host listener).
Hmmm. That shouldn't be difficult, but I would wait with it too.
There are some major simplifications in jk2 configuration, and
I think it is possible to have a much cleaner solution to synchronize
web.xml/server.xml and httpd.conf/urimap.properties.
Porting the 3.3 config generator would be great as a temporary solution,
if anyone has the time.
> I'm not going to do either of these. I have no clue how to do the first one,
To be honest, I have no clue either ( except for the hack - which is
what I'll probably do if nobody find a better solution ).
> Tomcat 4. I did bootstrap the porting of the docs already, and I've also
> fixed the problems with compiling against the CVS HEAD, so I think I've done
Great, many thanks !
> my part :) If you want to see full support for AJP in TC 4.0.2, it's up to
> you guys :)
Well, if you can also port the 'trusted app' - it would be really great.
For 3.3 jk will be packaged as a 'trusted web application' ( i.e. a WAR
with an extra interceptors.xml ), so users can deploy it / update it /
etc as simple as with any other application.
For 4.0 we create the jar that will be put in lib/catalina/..., but
it would be nice to be able to use the same .WAR file.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
AJP Todo
Posted by Remy Maucherat <re...@apache.org>.
Hi,
On the TODO list for AJP, there is:
- Implementing jvmroute.
- Adding a mechanism like there is in Tomcat 3.3 to automatically generate a
configuration file. That should be relatively easy to do using a server
listener (or a host listener).
I'm not going to do either of these. I have no clue how to do the first one,
and no time to do the second one.
So I'm counting on all the guys who voted +1 for supporting AJP 1.3+ on
Tomcat 4. I did bootstrap the porting of the docs already, and I've also
fixed the problems with compiling against the CVS HEAD, so I think I've done
my part :) If you want to see full support for AJP in TC 4.0.2, it's up to
you guys :)
If people are willing to actively support it, and if the risk for creating a
security vulnerability is low, we could also enable the AJP 1.3 connector
and the server listener by default (and declare it officially supported), so
that 4.0.2 behaves almost like 3.3 for AJP 1.3 related stuff.
Thanks,
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] about kjc
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 2 Dec 2001, Takashi Okamoto wrote:
> Date: Sun, 02 Dec 2001 09:19:37 +0900
> From: Takashi Okamoto <to...@kun.ne.jp>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: costinm@covalent.net
> Cc: Tomcat Developers List <to...@jakarta.apache.org>
> Subject: Re: [PATCH] about kjc
>
> Hi, Costin.
>
> At Sat, 1 Dec 2001 09:24:59 -0800 (PST),
> <co...@covalent.net> wrote:
> > +1 for the patch, but there's something that bothers me - we are starting
> > to duplicate what's already present in ant. Next we'll have gcj support,
> > etc.
> > How difficult would it be to add an 'ant' compiler adapter, that will just
> > use the ant <javac> task ?
>
> Of cource, using ant is better:) It's good idea.
> It seems not so difficult. You can use Javac or CompilerAdapterFactory
> (and Compiler Adapter) class for it.
>
I looked at this option a little bit a while back, and have only one
concern -- multiple threads trying to compile at the same time. Ant tasks
generally assume that they don't need to worry about thread safety issues,
so we need to review this code carefully. (Of course, this issue applies
even more so to the "new" Javac entry point in 1.4 -- it writes error
messages to System.out).
> > And also use the same ant mechansim, a global property - it's
> > possible other tools will need a compiler ( what is cocoon doing ? )
> > ?
>
> I don't know recent Cocoon. But cocoon 1.8.x was using just tomcat's
> JavaCompiler;)
>
> > This would also allow to automatically compile servlets ( the same
> > as jsps are compiled ),
>
> Resin has it already. It's very useful:)
>
> thanks.
> ----
> Takashi Okamoto
>
Craig McClanahan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] about kjc
Posted by Takashi Okamoto <to...@kun.ne.jp>.
Hi, Costin.
At Sat, 1 Dec 2001 09:24:59 -0800 (PST),
<co...@covalent.net> wrote:
> +1 for the patch, but there's something that bothers me - we are starting
> to duplicate what's already present in ant. Next we'll have gcj support,
> etc.
> How difficult would it be to add an 'ant' compiler adapter, that will just
> use the ant <javac> task ?
Of cource, using ant is better:) It's good idea.
It seems not so difficult. You can use Javac or CompilerAdapterFactory
(and Compiler Adapter) class for it.
> And also use the same ant mechansim, a global property - it's
> possible other tools will need a compiler ( what is cocoon doing ? )
> ?
I don't know recent Cocoon. But cocoon 1.8.x was using just tomcat's
JavaCompiler;)
> This would also allow to automatically compile servlets ( the same
> as jsps are compiled ),
Resin has it already. It's very useful:)
thanks.
----
Takashi Okamoto
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] about kjc
Posted by co...@covalent.net.
Hi Takashi-san,
+1 for the patch, but there's something that bothers me - we are starting
to duplicate what's already present in ant. Next we'll have gcj support,
etc.
How difficult would it be to add an 'ant' compiler adapter, that will just
use the ant <javac> task ? And also use the same ant mechansim, a global
property - it's possible other tools will need a compiler ( what is cocoon
doing ? ) ? Given the current ant dependecy checking ( that use class
bytecode to detect dependencies ) we could simplify and generalize most of
what's ugly in jasper. This would also allow to automatically compile
servlets ( the same as jsps are compiled ), and even to automatically
recompile a webapp ( that has a build.xml in WEB-INF ).
Costin
On Sat, 1 Dec 2001, Takashi Okamoto wrote:
> Hi, tomcat users and developrs!
>
> /* I have post this patch twice. This is third time. */
>
> Do you know kjc which is one of the completely opensource Java
> compiler? If not, you can see detail at http://www.dms.at/kopi.
>
> Accoding to Edouard G. Parmelan's report
> (http://rpmfind.net/tools/Kaffe/messages/1291.html), KJC HAVE BEATEN
> SUN'S JAVA COMPILER since version 1.5 about JLS compatibility. It was
> a grate news for Java open source community;)
>
> I and teik-san (san means Mr. in Japanese) wrote two kjc plugin for
> tomcat. One is for 3.3.x, and the other is for 4.0.x. If you take kjc
> plugin, it's good advertisement and help for kjc. Do you respect
> opensource? If so, could you take them?
>
>
> BTW, kjc is distributed under GPL. But you can take these patch in
> legal. Because you don't need to include kjc in tomcat. When you want to
> use kjc, only then you have to include it. In the fact, I wrote kjc
> plugin for Ant and it's really in it. So, you can also use kjc with
> Ant fine:)
>
> PS.
> usage for tomcat 4.0.x:
> download kjc.jar from http://www.dms.at/kopi and include it in
> common/lib.
>
> add specify jspCompilerPlugin at web.xml. For examples.
>
> <servlet>
> <servlet-name>jsp</servlet-name>
> <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
> <init-param>
> <param-name>logVerbosityLevel</param-name>
> <param-value>WARNING</param-value>
> </init-param>
> <init-param>
> <param-name>jspCompilerPlugin</param-name>
> <param-value>org.apache.jasper.compiler.KjcJavaCompiler</param-value>
> </init-param>
> <load-on-startup>3</load-on-startup>
> </servlet>
>
>
> Cheers for opensource!!
> -----
> Takashi Okamoto Debian Project: http://www.debian.org/
> tora@debian.org Ja-Jakarta Project: http://www.ingrid.org/jajakarta/
> GnuPG: 8B37 1FE6 76B2 7BA6 D59A 9BF7 E7F4 46C8 5293 6E17
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>