You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Robert Marcano <ro...@promca.com> on 2001/02/20 13:11:06 UTC
[C2] Regression in classpath generation -- Someone take a look at this please
Re: [C2] Regression in classpath generation
Posted by Berin Loritsch <bl...@apache.org>.
Robert Marcano wrote:
>
> Paul Russell wrote:
>
> > We changed the way classes are loaded in Cocoon by using a custom
> > classloader. I *thought* this was working these days. Are you using the
> > latest CVS? If it is broken, I should run into the same problem some
> > time this afternoon.
> >
> > The reason we're moving away from the classpath attribute is that we
> > don't actually know the attribute for all servlet engines, and it's not
> > portable. In theory, the new code should work across nearly all servlet
> > engines. Roll on SRV2.3.
> >
> > Paul.
>
> I´m using the latest cvs, but it doesn´t work with WebSphere 3.5. The
> problem is caused because a WAR file imported inside WebSphere, is
> broken in two directories
> "web" and "servlets", all the java code that resides inside
> WEB-INF/classes and WEB-INF/lib is moved to the "servlets" directory,
> the remaining files are installed inside the "web" directory, so the
> class CocoonServlet is not able to see the jar files to generate the
> classpath. I think that a solution to this is to use the
> classpath-attribute servlet parameter as an optional one. I temporally
> duplicated the jar files inside the web directory in order to continue
> development, but it can arise a security problem in WebSphere because
> files residing in the "web" directory are exposed to web downloads.
In WebSphere you need to use the ParanoidCocoonServlet anyway, so you
will have to recopy the WEB-INF/classes and WEB-INF/lib files back to
their propper location. I have used this approach, as it is the _only_
way I can get resources out of the ClassLoaders using WebSphere. Also,
WebSphere should be upgraded to Servlet 2.2 compliance with SP2. Although
I have experienced some serious issues with it: namely the inability to
use sendRedirect() within Cocoon.
I have serious reservations about WebSphere anyways. It's very frustrating
to use after fairly painless installs like Tomcat and Resin.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] Regression in classpath generation
Posted by Robert Marcano <ro...@promca.com>.
Paul Russell wrote:
> We changed the way classes are loaded in Cocoon by using a custom
> classloader. I *thought* this was working these days. Are you using the
> latest CVS? If it is broken, I should run into the same problem some
> time this afternoon.
>
> The reason we're moving away from the classpath attribute is that we
> don't actually know the attribute for all servlet engines, and it's not
> portable. In theory, the new code should work across nearly all servlet
> engines. Roll on SRV2.3.
>
> Paul.
I´m using the latest cvs, but it doesn´t work with WebSphere 3.5. The
problem is caused because a WAR file imported inside WebSphere, is
broken in two directories
"web" and "servlets", all the java code that resides inside
WEB-INF/classes and WEB-INF/lib is moved to the "servlets" directory,
the remaining files are installed inside the "web" directory, so the
class CocoonServlet is not able to see the jar files to generate the
classpath. I think that a solution to this is to use the
classpath-attribute servlet parameter as an optional one. I temporally
duplicated the jar files inside the web directory in order to continue
development, but it can arise a security problem in WebSphere because
files residing in the "web" directory are exposed to web downloads.
Re: [C2] Regression in classpath generation -- Someone take a look at this please
Posted by Paul Russell <pa...@luminas.co.uk>.
* Robert Marcano (robmv@promca.com) wrote :
> Reading old code, i noticed that
> src/org/apache/cocoon/servlet/CocoonServlet 1.1.4.50 and
> webapp/WEB-INF/web.xml 1.1.2.12 added the same attribute (using the same
> name that i used - big conincidence) and this change was lost. Was this
> a decission to remove it or was a mistake?
We changed the way classes are loaded in Cocoon by using a custom
classloader. I *thought* this was working these days. Are you using the
latest CVS? If it is broken, I should run into the same problem some
time this afternoon.
The reason we're moving away from the classpath attribute is that we
don't actually know the attribute for all servlet engines, and it's not
portable. In theory, the new code should work across nearly all servlet
engines. Roll on SRV2.3.
Paul.
--
Paul Russell Email: paul@luminas.co.uk
Technical Director Tel: +44 (0)20 8553 6622
Luminas Internet Applications Fax: +44 (0)870 28 47489
This is not an official statement or order. Web: www.luminas.co.uk
Re: [C2] Regression in classpath generation
Posted by Berin Loritsch <bl...@apache.org>.
Robert Marcano wrote:
>
> Berin Loritsch wrote:
>
> >
> > There are other ways of implementing security....
> > Anyhoo, I added two intial parameters for you:
> >
> > class-dir
> > lib-dir
> >
> > They represent _absolute_ paths to the directory, and are _only_ available in
> > the ParanoidCocoonServlet. Please let me know if they work ok for you.
>
> I tested these parameters, and didn´t worked for two reasons
> WebSphere 3.5.2 doesn´t support yet ServletContext init
> parameters :-( (I changed it to use Servlet init parameters)
> The two "if" used to detect if the parameters were defined uses a
> bad condition
>
> I´m attaching the diff file
Thanks. I caught one more bad condition, and committed the changes.
>
> >
>
> ------------------------------------------------------------------------------------------------------------------------------------
> Index: ParanoidCocoonServlet.java
> ===================================================================
> RCS file: /home/cvspublic/xml-cocoon/src/org/apache/cocoon/servlet/Attic/ParanoidCocoonServlet.java,v
> retrieving revision 1.1.2.2
> diff -u -r1.1.2.2 ParanoidCocoonServlet.java
> --- ParanoidCocoonServlet.java 2001/02/20 21:30:30 1.1.2.2
> +++ ParanoidCocoonServlet.java 2001/02/21 13:57:49
> @@ -136,18 +136,18 @@
> private String getClassPath(final ServletContext context, RepositoryClassLoader classloader)
> throws ServletException {
> StringBuffer buildClassPath = new StringBuffer();
> - String classDirPath = context.getInitParameter("class-dir");
> - String libDirPath = context.getInitParameter("lib-dir");
> + String classDirPath = getInitParameter("class-dir");
> + String libDirPath = getInitParameter("lib-dir");
> String classDir;
> File root;
>
> - if (classDirPath != null && classDirPath.equals("")) {
> + if (classDirPath != null && !classDirPath.trim().equals("")) {
> classDir = classDirPath;
> } else {
> classDir = context.getRealPath("/WEB-INF/classes");
> }
>
> - if (libDirPath != null && classDirPath.equals("")) {
> + if (libDirPath != null && !classDirPath.trim().equals("")) {
> root = new File(libDirPath);
> } else {
> root = new File(context.getRealPath("/WEB-INF/lib"));
>
> ------------------------------------------------------------------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] Regression in classpath generation
Posted by Robert Marcano <ro...@promca.com>.
Berin Loritsch wrote:
>
> There are other ways of implementing security....
> Anyhoo, I added two intial parameters for you:
>
> class-dir
> lib-dir
>
> They represent _absolute_ paths to the directory, and are _only_ available in
> the ParanoidCocoonServlet. Please let me know if they work ok for you.
I tested these parameters, and didn´t worked for two reasons
WebSphere 3.5.2 doesn´t support yet ServletContext init
parameters :-( (I changed it to use Servlet init parameters)
The two "if" used to detect if the parameters were defined uses a
bad condition
I´m attaching the diff file
>
Re: [C2] Regression in classpath generation
Posted by Berin Loritsch <bl...@apache.org>.
Robert Marcano wrote:
>
> Berin Loritsch wrote:
>
> >
> > There are other ways of implementing security....
> > Anyhoo, I added two intial parameters for you:
> >
> > class-dir
> > lib-dir
> >
> > They represent _absolute_ paths to the directory, and are _only_ available in
> > the ParanoidCocoonServlet. Please let me know if they work ok for you.
>
> Thanks, I will update my coocon and test it right now. Probably those
> incompatibility problems in WebSphere will begin to dissapear when more
> Tomcat code is embedded in WebSphere (Fixpak 2 uses jasper as the jsp
> engine)
I use Fixpak 2, and it's still a major pain in the butt. They need
a Fixpak 3 with working ClassLoaders and redirect mechanisms.
Re: [C2] Regression in classpath generation
Posted by Robert Marcano <ro...@promca.com>.
Berin Loritsch wrote:
>
> There are other ways of implementing security....
> Anyhoo, I added two intial parameters for you:
>
> class-dir
> lib-dir
>
> They represent _absolute_ paths to the directory, and are _only_ available in
> the ParanoidCocoonServlet. Please let me know if they work ok for you.
Thanks, I will update my coocon and test it right now. Probably those
incompatibility problems in WebSphere will begin to dissapear when more
Tomcat code is embedded in WebSphere (Fixpak 2 uses jasper as the jsp
engine)
Re: [C2] Regression in classpath generation -- Someone take a look at
this please
Posted by Berin Loritsch <bl...@apache.org>.
Robert Marcano wrote:
>
> Berin Loritsch wrote:
>
> > Robert Marcano wrote:
> >
> >>
> >
> >
> > It was removed. Now, consider Servlet Engines like IBM WebSphere 3.5.2
> > (Any previous version is not guaranteed to work), that not only have
> > broken classloaders, they physically rearrange the webapp. In those cases
> > (in order for compilation to work) you will have to recopy the jars into
> > the proper location again.
> >
> > With the Servlet 2.2 spec and Servlet 2.3 spec, one would think that rearranging
> > the war file is not only too much manipulation, but that those contracts should
> > be guaranteed even if you place the jars somewhere else...
> >
> > There is much I have grown to dislike about WebSphere.
>
> The reason why it is rearranged is for security reasons, in order to
> protect the java code from improper downloads. I think that is posible
> to get a workaround until the servlet spec defines a standard way to get
> the web application classpath
There are other ways of implementing security....
Anyhoo, I added two intial parameters for you:
class-dir
lib-dir
They represent _absolute_ paths to the directory, and are _only_ available in
the ParanoidCocoonServlet. Please let me know if they work ok for you.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] Regression in classpath generation -- Someone take a look at this please
Posted by Robert Marcano <ro...@promca.com>.
Berin Loritsch wrote:
> Robert Marcano wrote:
>
>>
>
>
> It was removed. Now, consider Servlet Engines like IBM WebSphere 3.5.2
> (Any previous version is not guaranteed to work), that not only have
> broken classloaders, they physically rearrange the webapp. In those cases
> (in order for compilation to work) you will have to recopy the jars into
> the proper location again.
>
> With the Servlet 2.2 spec and Servlet 2.3 spec, one would think that rearranging
> the war file is not only too much manipulation, but that those contracts should
> be guaranteed even if you place the jars somewhere else...
>
> There is much I have grown to dislike about WebSphere.
The reason why it is rearranged is for security reasons, in order to
protect the java code from improper downloads. I think that is posible
to get a workaround until the servlet spec defines a standard way to get
the web application classpath
Re: [C2] Regression in classpath generation -- Someone take a look at
this please
Posted by Berin Loritsch <bl...@apache.org>.
Robert Marcano wrote:
>
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Subject: [C2] Regression in classpath generation
> Date: Sat, 17 Feb 2001 11:30:36 -0400
> From: Robert Marcano <ro...@promca.com>
> Reply-To: cocoon-dev@xml.apache.org
> To: cocoon-dev <co...@xml.apache.org>
>
> :-(
>
> Recently I send a patch for Cocoon2 that adds a new servlet parameter to
> specify the context attribute where the servlet engine store the web
> application classpath.
>
> Reading old code, i noticed that
> src/org/apache/cocoon/servlet/CocoonServlet 1.1.4.50 and
> webapp/WEB-INF/web.xml 1.1.2.12 added the same attribute (using the same
> name that i used - big conincidence) and this change was lost. Was this
> a decission to remove it or was a mistake?
It was removed. Now, consider Servlet Engines like IBM WebSphere 3.5.2
(Any previous version is not guaranteed to work), that not only have
broken classloaders, they physically rearrange the webapp. In those cases
(in order for compilation to work) you will have to recopy the jars into
the proper location again.
With the Servlet 2.2 spec and Servlet 2.3 spec, one would think that rearranging
the war file is not only too much manipulation, but that those contracts should
be guaranteed even if you place the jars somewhere else...
There is much I have grown to dislike about WebSphere.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
> ------------------------------------------------------------------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org