You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2002/01/14 13:25:47 UTC
Problems with optional components (servlet, deli)
Hi,
I'm just in the process of making as much as possible of the compilation
optional in Cocoon.
There are some problems, here are two of them:
The deli package can not be left out as the components.deli.Deli interface
directly imports hp classes. As this interface is required by the
traxtransformer,
the hp classes are required even if the DeliImpl is left out.
The second problem is the independence of the servlet api. We pray that
cocoon is independent but for compiling (and running) cocoon the servlet
classes are required even for cli. After patching some parts, there is
only one place left: the abstract sitemap class. It contains the
tryToResetResponse
method which explicitly tests against an HttpResponse class, which is
very bad! For separation concerns I would like to add a tryToResetResponse
on the environment interface. Anything against this?
Cheers
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Problems with optional components (servlet, deli)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Berin Loritsch wrote:
>
> Carsten Ziegeler wrote:
>
> > Hi,
> >
> > I'm just in the process of making as much as possible of the compilation
> > optional in Cocoon.
> >
> > There are some problems, here are two of them:
> >
> > The deli package can not be left out as the
> components.deli.Deli interface
> > directly imports hp classes. As this interface is required by the
> > traxtransformer,
> > the hp classes are required even if the DeliImpl is left out.
>
>
> Try running Cocoon without Deli (be sure to remove the definition from the
> Cocoon.roles file). It should work (I tested it before I committed my
> patch).
>
>
Yes, that works - but you need the deli.jar during compilation.
However, I have solved this problem - you don't need it anymore during
compilation. The only thing missing is removing deli from the cocoon.xconf.
Thanks,
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Problems with optional components (servlet, deli)
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
> Hi,
>
> I'm just in the process of making as much as possible of the compilation
> optional in Cocoon.
>
> There are some problems, here are two of them:
>
> The deli package can not be left out as the components.deli.Deli interface
> directly imports hp classes. As this interface is required by the
> traxtransformer,
> the hp classes are required even if the DeliImpl is left out.
Try running Cocoon without Deli (be sure to remove the definition from the
Cocoon.roles file). It should work (I tested it before I committed my
patch).
> The second problem is the independence of the servlet api. We pray that
> cocoon is independent but for compiling (and running) cocoon the servlet
> classes are required even for cli. After patching some parts, there is
> only one place left: the abstract sitemap class. It contains the
> tryToResetResponse
> method which explicitly tests against an HttpResponse class, which is
> very bad! For separation concerns I would like to add a tryToResetResponse
> on the environment interface. Anything against this?
+1. Nothing outside of the CocoonServlet API should directly use the Servlet
API.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Problems with optional components (servlet, deli)
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
>
> Hi,
>
> I'm just in the process of making as much as possible of the compilation
> optional in Cocoon.
>
> There are some problems, here are two of them:
>
> The deli package can not be left out as the components.deli.Deli interface
> directly imports hp classes. As this interface is required by the
> traxtransformer,
> the hp classes are required even if the DeliImpl is left out.
>
> The second problem is the independence of the servlet api. We pray that
> cocoon is independent but for compiling (and running) cocoon the servlet
> classes are required even for cli. After patching some parts, there is
> only one place left: the abstract sitemap class. It contains the
> tryToResetResponse
> method which explicitly tests against an HttpResponse class, which is
> very bad! For separation concerns I would like to add a tryToResetResponse
> on the environment interface. Anything against this?
if this makes it abstract from the servlet API, go for it. +1
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Problems with optional components (servlet, deli)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Carsten Ziegeler wrote:
>
> Hi,
>
> I'm just in the process of making as much as possible of the compilation
> optional in Cocoon.
>
> There are some problems, here are two of them:
>
> The deli package can not be left out as the components.deli.Deli interface
> directly imports hp classes. As this interface is required by the
> traxtransformer,
> the hp classes are required even if the DeliImpl is left out.
>
I changed the Deli interface now for this. Their is only one method
getting the capabilities for a request object directly.
Carsten
> The second problem is the independence of the servlet api. We pray that
> cocoon is independent but for compiling (and running) cocoon the servlet
> classes are required even for cli. After patching some parts, there is
> only one place left: the abstract sitemap class. It contains the
> tryToResetResponse
> method which explicitly tests against an HttpResponse class, which is
> very bad! For separation concerns I would like to add a tryToResetResponse
> on the environment interface. Anything against this?
>
> Cheers
>
> Carsten
>
>
> ---------------------------------------------------------------------
> 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