Jean-Francois Arcand a écrit :
Henri Gomez wrote:
I traced TC 5.0 and Digester and suspect what could be the problem
with external entities when only SYTEM is defined ie :
!ENTITY appset1 SYSTEM appset1.xml
!ENTITY appset2 SYSTEM appset2.xml
In Digester.java, at least in the 1.5 release,
As described above, you're trying to use an illegal URL, which goes
above the top of the webapp's namespace. You'll need to use absolute
file: or http: type URLs, or provide your own EntityResolver that
does whatever you want it to do.
The only way to developpers and admins to have it works
I traced TC 5.0 and Digester and suspect what could be the problem
with external entities when only SYTEM is defined ie :
!ENTITY appset1 SYSTEM appset1.xml
!ENTITY appset2 SYSTEM appset2.xml
In Digester.java, at least in the 1.5 release, resolveEntity return
null if publicId is null even if
Craig R. McClanahan a écrit :
Henri Gomez wrote:
CF w3c.org
... relative URIs are relative to the location of the resource within
which the entity declaration occurs.
http://www.w3.org/TR/REC-xml#sec-external-ent
As long as Tomcat uses the Digester.parse() entry point that takes an
[EMAIL PROTECTED]
Sent: Tuesday, October 14, 2003 12:29 AM
Subject: Digester and external entities with systemId only : Was: Important
requirement : Re: [next] What's next ?
I traced TC 5.0 and Digester and suspect what could be the problem
with external entities when only SYTEM is defined ie
Bill Barker a écrit :
You will probably get more traction by posting to commons-dev. While
tomcat-dev still has a couple of commons committers (and, no, I'm not one of
them) that hang out here, its not like the old days :(.
Sure but Remy has written the Digester so it must still be commiter :-)
- Original Message -
From: Henri Gomez [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Tuesday, October 14, 2003 12:42 AM
Subject: Re: Digester and external entities with systemId only : Was:
Important requirement : Re: [next] What's next ?
Bill Barker a écrit
Bill Barker a écrit :
- Original Message -
From: Henri Gomez [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Tuesday, October 14, 2003 12:42 AM
Subject: Re: Digester and external entities with systemId only : Was:
Important requirement : Re: [next] What's next
Henri Gomez wrote:
I traced TC 5.0 and Digester and suspect what could be the problem
with external entities when only SYTEM is defined ie :
!ENTITY appset1 SYSTEM appset1.xml
!ENTITY appset2 SYSTEM appset2.xml
In Digester.java, at least in the 1.5 release, resolveEntity return
null if publicId
Henri Gomez wrote:
I traced TC 5.0 and Digester and suspect what could be the problem
with external entities when only SYTEM is defined ie :
!ENTITY appset1 SYSTEM appset1.xml
!ENTITY appset2 SYSTEM appset2.xml
In Digester.java, at least in the 1.5 release, resolveEntity return
null if publicId
Henri Gomez a écrit :
Remy Maucherat a écrit :
Henri Gomez wrote:
Henri Gomez a écrit :
Note: I really love Xerces' error messages.
Great it seems to works with :
?xml version=1.0 encoding=ISO-8859-1?
!DOCTYPE web-app
PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN
Henri Gomez wrote:
No reply for this request ?
Should I assume I could start to work on settings the currentWorking
dir at web.xml dir location at web.xml parsing time ?
I like basing the resolution on the host appBase a lot more.
Remy
Remy Maucherat a écrit :
Henri Gomez wrote:
No reply for this request ?
Should I assume I could start to work on settings the currentWorking
dir at web.xml dir location at web.xml parsing time ?
I like basing the resolution on the host appBase a lot more.
Well it will be problematic for all
Henri Gomez wrote:
Remy Maucherat a écrit :
Henri Gomez wrote:
No reply for this request ?
Should I assume I could start to work on settings the currentWorking
dir at web.xml dir location at web.xml parsing time ?
I like basing the resolution on the host appBase a lot more.
Well it will be
Remy Maucherat a écrit :
Henri Gomez wrote:
Remy Maucherat a écrit :
Henri Gomez wrote:
No reply for this request ?
Should I assume I could start to work on settings the currentWorking
dir at web.xml dir location at web.xml parsing time ?
I like basing the resolution on the host appBase a
Henri Gomez wrote:
Remy Maucherat a écrit :
Henri Gomez wrote:
No reply for this request ?
Should I assume I could start to work on settings the currentWorking
dir at web.xml dir location at web.xml parsing time ?
I like basing the resolution on the host appBase a lot more.
Well it will be
Glenn Nielsen wrote:
Henri Gomez wrote:
Remy Maucherat a écrit :
Henri Gomez wrote:
No reply for this request ?
Should I assume I could start to work on settings the currentWorking
dir at web.xml dir location at web.xml parsing time ?
I like basing the resolution on the host appBase a lot
Remy Maucherat a écrit :
Glenn Nielsen wrote:
Henri Gomez wrote:
Remy Maucherat a écrit :
Henri Gomez wrote:
No reply for this request ?
Should I assume I could start to work on settings the currentWorking
dir at web.xml dir location at web.xml parsing time ?
I like basing the resolution
CF w3c.org
... relative URIs are relative to the location of the resource within
which the entity declaration occurs.
http://www.w3.org/TR/REC-xml#sec-external-ent
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Henri Gomez wrote:
Remy Maucherat a écrit :
Glenn Nielsen wrote:
Henri Gomez wrote:
Remy Maucherat a écrit :
Henri Gomez wrote:
No reply for this request ?
Should I assume I could start to work on settings the currentWorking
dir at web.xml dir location at web.xml parsing time ?
I
The base should be the location of web.xml (la prochaine fois j'envoie
un mail en français :---)
+1 ;-)
Time for a Tomcat Dev French Forum, to fix these language problems ? ;)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
Henri Gomez wrote:
CF w3c.org
... relative URIs are relative to the location of the resource within
which the entity declaration occurs.
http://www.w3.org/TR/REC-xml#sec-external-ent
As long as Tomcat uses the Digester.parse() entry point that takes an
InputSource, and properly specifies the
Remy Maucherat a écrit :
Henri Gomez wrote:
Henri Gomez a écrit :
Note: I really love Xerces' error messages.
Great it seems to works with :
?xml version=1.0 encoding=ISO-8859-1?
!DOCTYPE web-app
PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN
[EMAIL PROTECTED] wrote:
Glenn Nielsen wrote:
Remy Maucherat wrote:
Glenn Nielsen wrote:
I proposed a while ago to implement a custom java policy for the
SecurityManager which uses XML for configuring permissions for
the Java SecurityManager. There were a number of features which
made
Glenn Nielsen wrote:
Remy Maucherat wrote:
Glenn Nielsen wrote:
I proposed a while ago to implement a custom java policy for the
SecurityManager which uses XML for configuring permissions for
the Java SecurityManager. There were a number of features which
made configuring a strict
Henri Gomez a écrit :
Jean-Francois Arcand a écrit :
+1
The security mechanism in TC 4.x and higher (due to digester)
avoid me to use such easy configuration tuning and so we have
to stay with Tomcat 3.3.x for now.
I'm probably missing something herewhy the digester suffer from
that
Craig R. McClanahan a écrit :
Henri Gomez wrote:
Jean-Francois Arcand a écrit :
Henri Gomez wrote:
Henri Gomez a écrit :
3. Provide a complete working configuration example for a cluster of
tomcat servers with a front-end tomcat as well, i.e. a pure
tomcat-only
solution. We already have
Henri Gomez a écrit :
Henri Gomez a écrit :
Jean-Francois Arcand a écrit :
+1
The security mechanism in TC 4.x and higher (due to digester)
avoid me to use such easy configuration tuning and so we have
to stay with Tomcat 3.3.x for now.
I'm probably missing something herewhy the
Henri Gomez a écrit :
Henri Gomez a écrit :
Henri Gomez a écrit :
Jean-Francois Arcand a écrit :
+1
The security mechanism in TC 4.x and higher (due to digester)
avoid me to use such easy configuration tuning and so we have
to stay with Tomcat 3.3.x for now.
I'm probably missing
Henri Gomez wrote:
Henri Gomez a écrit :
Note: I really love Xerces' error messages.
Great it seems to works with :
?xml version=1.0 encoding=ISO-8859-1?
!DOCTYPE web-app
PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN
http://java.sun.com/dtd/web-app_2_3.dtd;
[ !ENTITY %
[EMAIL PROTECTED] wrote:
On Thu, 2 Oct 2003, Angus Mezick wrote:
2. Eliminate the shared and common classloader repositories. Unless
these are required by the spec? Force webapps to be self-contained by
putting all their classes in WEB-INF/lib or WEB-INF/classes of their
webapp. Have the
I proposed a while ago to implement a custom java policy for the
SecurityManager which uses XML for configuring permissions for
the Java SecurityManager. There were a number of features which
made configuring a strict security policy easier. You can look
back through the archives for the initial
Glenn Nielsen wrote:
I proposed a while ago to implement a custom java policy for the
SecurityManager which uses XML for configuring permissions for
the Java SecurityManager. There were a number of features which
made configuring a strict security policy easier. You can look
back through the
Costin Manolache wrote:
Jean-Francois Arcand wrote:
I would be interested to:
- implement jsr115 as an optional feature (based on a previous
discussion with Costin on this thread (that may bring Costing back :-) ).
- turn SecurityManager on by default ( already proposed by Costin
sometime ago
for some reason this didn't get through to the list yesterday. If you get
this twice, I apologize
Charlie
-Original Message-
From: Cox, Charlie
Sent: Thursday, October 02, 2003 2:12 PM
To: 'Tomcat Developers List'
Subject: RE: [next] What's next ?
-Original Message-
From
:[EMAIL PROTECTED]
Sent: Friday, October 03, 2003 9:11 AM
To: Tomcat Developers List
Subject: Re: [next] What's next ?
Costin Manolache wrote:
Jean-Francois Arcand wrote:
I would be interested to:
- implement jsr115 as an optional feature (based on a previous
discussion with Costin
Remy Maucherat wrote:
Glenn Nielsen wrote:
I proposed a while ago to implement a custom java policy for the
SecurityManager which uses XML for configuring permissions for
the Java SecurityManager. There were a number of features which
made configuring a strict security policy easier. You can
Usually, when a Tomcat branch nears its release, a new branch is created.
However, I only have a few feature ideas that make some sense, and the
problem is that they are minor evolutions (hence, they could perfectly
fit inside the 5.0 branch). This includes:
- Updating JK2 to use the JMX
The AccessLog Valves might be nice to simplify so a Logging element is a
nested inside of the Valve declaration. This way the access log valve can
just do 3 things:
- determine if it should log (conditional logging)
- format a string to be logged
- Pass it along to a logging element which can
-Original Message-
From: Tim Funk [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 6:55 AM
To: Tomcat Developers List
Subject: Re: [next] What's next ?
The AccessLog Valves might be nice to simplify so a Logging element
is a
nested inside of the Valve declaration. This way
-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 9:56 AM
To: Tomcat Developers List
Subject: RE: [next] What's next ?
Then I have other ideas, of varying degrees of radicality and I'm sure
stupidity ;) I'm proposing them
On Thu, 2 Oct 2003, Angus Mezick wrote:
2. Eliminate the shared and common classloader repositories. Unless
these are required by the spec? Force webapps to be self-contained by
putting all their classes in WEB-INF/lib or WEB-INF/classes of their
webapp. Have the WEB-INF/clases -
[mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 3:32 AM
To: Tomcat Developers List
Subject: [next] What's next ?
Usually, when a Tomcat branch nears its release, a new branch is
created.
However, I only have a few feature ideas that make some sense, and the
problem
Remy Maucherat a écrit :
Usually, when a Tomcat branch nears its release, a new branch is created.
However, I only have a few feature ideas that make some sense, and the
problem is that they are minor evolutions (hence, they could perfectly
fit inside the 5.0 branch). This includes:
-
Shapira, Yoav wrote:
Howdy,
On the subject of AccessLogValve: I hadn't thought of the things Tim
suggested, but I have a different suggestion, part of a more general
suggestion:
1. Convert AccessLogValve to be a servlet specification 2.3 filter, i.e.
something portable. We can define it in
3. Provide a complete working configuration example for a cluster of
tomcat servers with a front-end tomcat as well, i.e. a pure tomcat-only
solution. We already have the jvmRoute mechanism, but I think it needs
more examples/documentation so that people start using it.
So you want to do a
I would be interested to:
- implement jsr115 as an optional feature (based on a previous
discussion with Costin on this thread (that may bring Costing back :-) ).
- turn SecurityManager on by default ( already proposed by Costin
sometime ago if I remember).
- improve xml parsing performance
Henri Gomez wrote:
Remy Maucherat a écrit :
Usually, when a Tomcat branch nears its release, a new branch is created.
However, I only have a few feature ideas that make some sense, and the
problem is that they are minor evolutions (hence, they could perfectly
fit inside the 5.0 branch). This
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 10:50 AM
To: Tomcat Developers List
Subject: RE: [next] What's next ?
On Thu, 2 Oct 2003, Angus Mezick wrote:
2. Eliminate the shared and common classloader
Henri Gomez a écrit :
3. Provide a complete working configuration example for a cluster of
tomcat servers with a front-end tomcat as well, i.e. a pure tomcat-only
solution. We already have the jvmRoute mechanism, but I think it needs
more examples/documentation so that people start using it.
Henri Gomez wrote:
Henri Gomez a écrit :
3. Provide a complete working configuration example for a cluster of
tomcat servers with a front-end tomcat as well, i.e. a pure
tomcat-only
solution. We already have the jvmRoute mechanism, but I think it
needs
more examples/documentation so that
Jean-Francois Arcand a écrit :
Henri Gomez wrote:
Henri Gomez a écrit :
3. Provide a complete working configuration example for a cluster of
tomcat servers with a front-end tomcat as well, i.e. a pure
tomcat-only
solution. We already have the jvmRoute mechanism, but I think it
needs
more
Howdy,
2. Eliminate the shared and common classloader repositories. Unless
these are required by the spec? Force webapps to be self-contained
by
putting all their classes in WEB-INF/lib or WEB-INF/classes of their
webapp. Have the WEB-INF/clases - WEB-INF/lib - endorsed - system
Shapira, Yoav wrote:
Howdy,
I think this kind of classloading structure can be configured in TC 5
using the catalina.properties.
If it can be achieved via configuration, I'm happy ;) How can it be
done?
You can set empty contents to the repositories list in
catalina.properties, and then move
--- Shapira, Yoav [EMAIL PROTECTED] wrote:
1. Convert AccessLogValve to be a servlet
specification 2.3 filter, i.e.
something portable. We can define it in
$CATALINA_HOME/conf/web.xml,
commented out by default perhaps, and users can move
the definition
around as they need just like they
Howdy,
--- Shapira, Yoav [EMAIL PROTECTED] wrote:
1. Convert AccessLogValve to be a servlet
specification 2.3 filter, i.e.
That sounds wonderful and useful, but there are a few
problems here. Filters don't have access to all the
information that is needed to make a log entry the way
the
--- Shapira, Yoav [EMAIL PROTECTED] wrote:
That's unfortunate ;(
Yes it is. Those methods may not really belong in the
Filter interface, though. That's why I think it may
be a better idea to start thinking about a real API
for more of the core components of the server:
logging, classloading,
Howdy,
There's already an exposed API for writing tomcat loggers (just
implement org.apache.catalina.Logger and configure your logger in
server.xml). Let's get off that topic please and stick to the access
log filter I was proposing.
I think that many of those values, such as
ContentLength, are
Henri Gomez wrote:
Jean-Francois Arcand a écrit :
Henri Gomez wrote:
Henri Gomez a écrit :
3. Provide a complete working configuration example for a cluster of
tomcat servers with a front-end tomcat as well, i.e. a pure
tomcat-only
solution. We already have the jvmRoute mechanism, but I
joe user wrote:
--- Shapira, Yoav [EMAIL PROTECTED] wrote:
1. Convert AccessLogValve to be a servlet
specification 2.3 filter, i.e.
something portable. We can define it in
$CATALINA_HOME/conf/web.xml,
commented out by default perhaps, and users can move
the definition
around as they need
Shapira, Yoav wrote:
Howdy,
--- Shapira, Yoav [EMAIL PROTECTED] wrote:
1. Convert AccessLogValve to be a servlet
specification 2.3 filter, i.e.
That sounds wonderful and useful, but there are a few
problems here. Filters don't have access to all the
information that is needed to
level to be able to do TCP load balancing well.
Filip
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 1:31 AM
Subject: [next] What's next ?
Usually, when a Tomcat branch nears its release, a new
Filip Hanik wrote:
- Java or native load balancer, with session affinity support. This
could be the perfect commons project, and is not really related to Tomcat
After looking into it, writing a load balancer in Java will only cause the
load balancer to become a bottleneck nothing else, Java
-
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 10:38 AM
Subject: Re: [next] What's next ?
Filip Hanik wrote:
- Java or native load balancer, with session affinity support. This
could be the perfect commons project
-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 11:57 AM
To: Tomcat Developers List
Subject: RE: [next] What's next ?
Howdy,
2. Eliminate the shared and common classloader
repositories. Unless
these are required
On Thu, October 2, 2003 at 8:56 am, Shapira, Yoav sent the following
3. Provide a complete working configuration example for a cluster of
tomcat servers with a front-end tomcat as well, i.e. a pure
tomcat-only
solution. We already have the jvmRoute mechanism, but I think it
needs
more
in,
Load balancing belongs to hardware, and in software (native code) on nothing
but the smallest projects
Filip
- Original Message -
From: David Rees [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 11:17 AM
Subject: RE: [next] What's next
On Thu, October 2, 2003 1at 0:33 am, Filip Hanik sent the following
- Java or native load balancer, with session affinity support. This
could be the perfect commons project, and is not really related to Tomcat
After looking into it, writing a load balancer in Java will only cause the
load
-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 12:06 PM
To: Tomcat Developers List
Subject: Re: [next] What's next ?
Shapira, Yoav wrote:
Howdy,
I think this kind of classloading structure can be
configured in TC 5
Howdy,
Thanks for the response wrapper idea and skeleton -- that seems to solve
most of the problems we discussed.
For access logging in particular, I'd be concerned about a couple of
things:
* Filters don't see every request (for example, the authentication
challenges when you're using BASIC
An AccessLogFilter will not work since the filter is only valid for a single
webapplication. If you wish to log all requests for a server (or Host) to the
same log file, you could in theory have multiple Filters running at the same
time, one for each webapp - but I'd hate to see the messy file
Jean-Francois Arcand wrote:
I would be interested to:
- implement jsr115 as an optional feature (based on a previous
discussion with Costin on this thread (that may bring Costing back :-) ).
- turn SecurityManager on by default ( already proposed by Costin
sometime ago if I remember).
72 matches
Mail list logo
