You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by David Sean Taylor <da...@b3interactive.com> on 2001/03/07 19:37:30 UTC
Servlet 2.2 Spec. and serving files from the WEB-INF directory
I've been trying to get Jetspeed to run with a particular vendor for quite a
while now.
I am not disclosing the name of the vendor, I replaced it below with
*VENDOR-PRODUCT*
I assume Websphere doesn't have a problem with serving files from the
WEB-INF directory.
Agreed that it makes it nice to have one WAR file for distribution, but any
thoughts on 'breaking' the 2.2 spec?
> I've run into a possible bug in our servlet container. Jetspeed is built
> using Model 2 which involves lots of servlets, forwards, includes,
> templates and lots of other crap that pretty much makes a webapp
> unmaintainable. Most of Jetspeed's template resources, in the form of jsp
> pages, are found in its WEB-INF directory. This is where the problem comes
> in. According to the Servlet 2.2 spec section 9.4, "No file contained in
> the WEB-INF directory may be served directly to a client." So
*VENDOR-PRODUCT*
> returns a 403 Forbidden error whenever a request is made to the container
> that results in jsp template files being requested out of the WEB-INF
> directory. Tomcat, on the other hand, does not prevent access to the
> WEB-INF directory for template files. So the question is, are we doing the
> correct thing according to the spec? Is processing a template file
> considered serving a file directly to a client?
RE: Servlet 2.2 Spec. and serving files from the WEB-INF directory
Posted by David Sean Taylor <da...@b3interactive.com>.
> Processing a template is not serving a file in the general case,
> especially
> Velocity templates sitting in WEB-INF should never cause any
> issue, however
> JSPs are a special case and I'm not sure how Turbine handles JSPs as
> templates, if you use any RequestDispatcher method, the servlet container
> may certainly treat this as if the included file has been
> forwarded directly
> to the client...
>
> I put the templates in the WEB-INF directory because for systems such as
> Velocity, they should never be accessed directly from a client so WEB-INF
> was a natural solution.
>
> Can you try to move the JSP templates to the base webapp directory
> and use ${webapp.dir}/templates/jsp as the base JSP template dir ?
Yes, I tried that several weeks ago. No luck.
The RequestDispatcher problem is a a bug in the servlet container.
Its now just a matter of waiting, and its been some time now, for it to be
fixed.
The remaining question is whether its compliant to put JSPs in the WEB-INF
directory.
Surely there is a definitive answer on this.
RE: Servlet 2.2 Spec. and serving files from the WEB-INF directory
Posted by David Sean Taylor <da...@bluesunrise.com>.
> This looks like defensive behaviour. Instead of acknowledging
> that they have
> a broken requestDispatcher, they look for counterarguments.
>
Yes, thats not surprising.
> The difference, Ingo, might be that a given app server runs
> or not. But we should not
> go too fast here. David, maybe we can think about a
> workaround for this vendor, like
> not using requestDispatcher or patching theirs. I suggest
How can JSPs work in a Model 2 without a dispather?
The bug must be fixed. Geez, its the damn servlet specification.
They must correctly implement the api.
How do they get away with that j2ee-compliant logo?
> that if they don't react fast
> enough to the issues you publish their name/version/issue
> details and we start looking for
> workarounds in their user community.
>
Im just one little person, but I do have a few ways to be heard.
You know what Im working on, what Im writing... :)
> Does the database runs correctly with this vendor's server? I
> bet yes. Let us go slowly on
> this one again.
Yes, it works.
Agreed. We have to acknowledge that many of new users don't know how to
configure a database.
It is valuable to have a configured, working db right in the war
installation
>
> A good question is:
>
> Which App servers with servlet containers out there use a
> SecurityManager, mandatory or recommended, in their setup?
>
> Can you all erase the rest of the message quote and answer this last
> question, for what you know?
>
I can do research this for the two app.servers Im working with
btw -- have you seen this
http://www.flashline.com/components/appservermatrix.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Servlet 2.2 Spec. and serving files from the WEB-INF directory
Posted by Santiago Gala <sg...@hisitech.com>.
David Sean Taylor wrote:
>> (David what did you
>> mean by "bug in the servlet container". Does this vendor
>> regard it as a bug
>> if it's not possible to forward the requests to JSPs below WEB-INF?)
>
>
> Their RequestDispatcher does not work. Simple as that.
> Regardless if forwarding/including from WEB-INF or any other directory.
> I have sent them simples examples. They have acknowledged this a bug.
>
> They are questioning whether JSPs in the WEB-INF directory should be
> accessible
This looks like defensive behaviour. Instead of acknowledging that they have
a broken requestDispatcher, they look for counterarguments.
> I understand your argument, but the simple fact is that other vendors may
> not see it this way, as this case testifies to.
> Even when they fix the bug with the dispatcher, I am not sure if they will
> allow for JSPs to be served from WEB-INF.
>
This will be the moment to look for a workaround or change in behaviour.
>
>> A second argument: if we move the templates up to the
>> web-root and protect
>> them so that they can't be requested by a client directly --
>> then where is
>> the difference to putting them in the WEB-INF??
>
>
The difference, Ingo, might be that a given app server runs or not. But we should not
go too fast here. David, maybe we can think about a workaround for this vendor, like
not using requestDispatcher or patching theirs. I suggest that if they don't react fast
enough to the issues you publish their name/version/issue details and we start looking for
workarounds in their user community.
> Im undecided on all these issues, until I understand the overhead with
> secure resources.
> Perhaps the PSML could go under the web root, but in a secure directory.
> If we start using secure resources, does this require that Tomcat starts
> with a security manager?
>
Not at all (at least with tomcat 3.2.2beta). There are two different issues here:
- container authentication (= secure resources). No resource will be served
unless the client has authenticated first (password, form, etc.). Request should
return true to isSecure(), and return us a getUserPrincipal(). This Principal
can be used for isUserInRole( role ). This is HTTP authentication.
- java security. A SecurityManager is installed. Operations like Thread.stop() or new File() are checked
for permissions, depending on code base and classloader info. This is analogue to running as nobody vs.
running as root (in the java level). This is standard java security. Having java security on is mandatory for
RMI servers (and nothing else, as far as I know, JNDI? ).
Java security will possibly be used when a provider wants to ensure that different war apps run
in the same VM without interference. For instance, without calling System.exit(), or writing the files
of the other app. Also, if you VM runs at the same time a servlet container and a RMI server. This could be
the case for some App servers.
> Also undecided on the database.
> Its obvious that in a real deployment, the database will not go there.
> Its just valuable for first time developers to easily get started with a
> default database.
Does the database runs correctly with this vendor's server? I bet yes. Let us go slowly on
this one again.
A good question is:
Which App servers with servlet containers out there use a
SecurityManager, mandatory or recommended, in their setup?
I remember Jonas required it if you were running the RMI server from the
same VM. I did this for my customer one year ago, to simplify VM
maintenance and memory footprint. (It would not run under jdk1.2.2, due
to a silly classloader bug solved in jdk1.3) But, again, the servlet
container was not included in this setup, so no problem for us. In my
setup I had on VM for the web server, and another one for the RMI server
and EJB container, both as NT services. I saved one NT service and java VM.
Can you all erase the rest of the message quote and answer this last
question, for what you know?
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
RE: Servlet 2.2 Spec. and serving files from the WEB-INF directory
Posted by David Sean Taylor <da...@bluesunrise.com>.
> (David what did you
> mean by "bug in the servlet container". Does this vendor
> regard it as a bug
> if it's not possible to forward the requests to JSPs below WEB-INF?)
Their RequestDispatcher does not work. Simple as that.
Regardless if forwarding/including from WEB-INF or any other directory.
I have sent them simples examples. They have acknowledged this a bug.
They are questioning whether JSPs in the WEB-INF directory should be
accessible
I understand your argument, but the simple fact is that other vendors may
not see it this way, as this case testifies to.
Even when they fix the bug with the dispatcher, I am not sure if they will
allow for JSPs to be served from WEB-INF.
> A second argument: if we move the templates up to the
> web-root and protect
> them so that they can't be requested by a client directly --
> then where is
> the difference to putting them in the WEB-INF??
Again, the point Im trying to make is that its up to interpretation in the
WEB-INF directory.
Your interpretation is that it is allowed. Another vendor may interpret it
differently.
The goal is to the deploy Jetspeed on all compliant servlet containers, and
to minimize deployment issues for our users.
Thats why Im not for leaving the templates in the WEB-INF directory, since
it may not work with all containers.
Im undecided on all these issues, until I understand the overhead with
secure resources.
Perhaps the PSML could go under the web root, but in a secure directory.
If we start using secure resources, does this require that Tomcat starts
with a security manager?
Also undecided on the database.
Its obvious that in a real deployment, the database will not go there.
Its just valuable for first time developers to easily get started with a
default database.
Perhaps we should have two different war files, or is that more confusing?
I guess Im not so fast with my +1s :)
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Servlet 2.2 Spec. and serving files from the WEB-INF
directory
Posted by ingo schuster <in...@web.de>.
Man, you are all quick with our +1s...
My opinion is:
The WEB-INF is the only place that is per default save in a way that *under
no circumstances* a client can request a file and gets it delivered by the
HTTP server. This is very important with respect to security, and I
wouldn't want to place any file that doesn't need to be served by the HTTP
server somewhere else - unless there is a *very* good reason for doing so.
This includes JSPs, they may contain comments and code that must not be
viewed by clients. (The same holds true for logs, nobody apart the system
administrators should be able to read them.)
"No file contained in the WEB-INF directory may be served directly to a
client." means that it is not possible to send a request
"http://myserver/myapp/WEB-INF/fileXY" and get it delivered *by the HTTP
server*. A servlet, that receives a request under a different URL is of
course allowed to read and deliver this file. It is also allowed to forward
the request to another servlet in the WEB-INF/lib directory. JSPs are
conceptually almost the same as servlets and I'd say that the servlet can
_of course_ forward the request to a JSP below WEB-INF. (David what did you
mean by "bug in the servlet container". Does this vendor regard it as a bug
if it's not possible to forward the requests to JSPs below WEB-INF?)
In short: I can't see how template processing is a _direct_ serving of a
file - don't think that's fuzzy at all. Direct serving is the HTTP server
picking up a file and delivering it, with no webapp code working inbetween.
A second argument: if we move the templates up to the web-root and protect
them so that they can't be requested by a client directly -- then where is
the difference to putting them in the WEB-INF??
So I'm -1 for moving the templates to the web root. We only risk that we
get additional problems with securing the directory there.
Writing in the WEB-INF is a problem, I can see this. I'm +1 for moving the
cache to the work area - it is temporary data anyway.
Regarding the logs and the psml, I'm not sure what to do, I can see that
they shouldn't be below WEB-INF, but I don't like to place them in a temp
directory (that's what the work area is) - for production that's
inacceptable. I agree with Santiago that a DB/LDAP would be the best place
for a serious installation, but for development, I can't think of a really
good place...
To sumarize: I'm
-1 for moving the 'templates' to the web root,
+1 for leaving them where thy are
-1 for moving the 'logs' to the web root,
+0 for moving them to the work area,
-0 for moving the 'cache' to the web root
+1 for moving them to the work area,
+1 for moving the psml out of WEB-INF
(-1 for moving them to the web root)
... no idea where to put them. A BLOB in the DB?
ingo.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Servlet 2.2 Spec. and serving files from the WEB-INF directory
Posted by Santiago Gala <sg...@hisitech.com>.
David Sean Taylor wrote:
> Have you tried starting Catalina with the -security option?
> It doesn't get very far...
> I think Santiago has some experiences that he has documented on this list a
> few weeks back.
> It would be interesting if we get could Jetspeed running with the Security
> Manager.
>
I got Jetspeed running with security and tomcat 3.2.2dev (or 3.2.2beta1).
The policy that I posted here reflected the results I got (it was rather experimental, though)
This is somehow orthogonal to the issue of allowing servlet requests (jsp are translated into
one servlet each) to servlets withing WEB-INF.
What they have clearly stated in tomcat docs (and it seems common sense, since the WEB-INF directory
contains classes and jars, and a war could be handled without expansion) is that a webapp will have
default read permission on this directory, and read-write permission only through the temp.dir
(or work.dir) attribute, whatever I said there.
So, I enter this thread looking also from a default security point of view, and mixing things together
(my speciality is to create confusion :)
>
>> I'm definitely +1 for moving the
>>
>> templates
>> cache
+1, we write it.
>> logs
+1, the same reason.
Also we should think about the psml structure, as we need to write it.
we could check if it is in the "work" area, and create it there if
it was erased. The only problem is long term persistency, since
the work area can be cleared (it is called work in tomcat, after all).
We could differenciate the "default" development/demo war, and a serious
production site.
In the first case, we could use the work directory, and warn people to "don't
delete it unless you want to loose your custom settings. For the second case,
a DB, LDAP, ... based profiling engine should be advised.
Also, we are writing hsql DB inside WEB-INF... The same solution could be applied.
>
>
> The spec. seems to be open to interpretation.
> That said, it does explicity state "No file contained in the WEB-INF
> directory may be served directly to a client."
> A template does qualify as a file, does it not? Its not a 'static' file, but
> imo, we are asking for trouble.
>
Agreed. It is too fuzzy. We can not be certain of this. I think "directly" forbids
request dispatcher accepting WEB-INF files. Not other uses. But again, the way they
choosed to enforce it can interfere with our code.
> I believe we should try to minimize the grey areas, and move 'cache' and
> 'templates' out of the WEB-INF directory.
> The 'logs' may need to be accessed by administrative users removely.
My idea of logs is that the best bet is to use a syslog type of facility. The
log4java people should take care of this problem for us :) Also, I think we can use the servlet
logging features of servlet engines. I think catalina already hooks into log4java.
For the "default" implementation, we could put them in the work area, and document
that users should move logs, when they go into production, to a more robust implementation,
using things like syslogd (or NT equivalent) remote logging, or plugging log into their favorite
app server scheme.
>
> Im trying to deploy Jetspeed on Weblogic 6.
> It deploys so easily, it was like a 'write once, deploy anywhere' dream.
> But again it fails to run. I have an open case with Weblogic.
> Im still waiting...same as it ever was
>
Keep us informed. What kind of problems?
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
RE: Servlet 2.2 Spec. and serving files from the WEB-INF directory
Posted by David Sean Taylor <da...@bluesunrise.com>.
Have you tried starting Catalina with the -security option?
It doesn't get very far...
I think Santiago has some experiences that he has documented on this list a
few weeks back.
It would be interesting if we get could Jetspeed running with the Security
Manager.
> I'm definitely +1 for moving the
>
> templates
> cache
> logs
The spec. seems to be open to interpretation.
That said, it does explicity state "No file contained in the WEB-INF
directory may be served directly to a client."
A template does qualify as a file, does it not? Its not a 'static' file, but
imo, we are asking for trouble.
I believe we should try to minimize the grey areas, and move 'cache' and
'templates' out of the WEB-INF directory.
The 'logs' may need to be accessed by administrative users removely.
Im trying to deploy Jetspeed on Weblogic 6.
It deploys so easily, it was like a 'write once, deploy anywhere' dream.
But again it fails to run. I have an open case with Weblogic.
Im still waiting...same as it ever was
- david
> -----Original Message-----
> From: Raphaël Luta [mailto:raphael.luta@networks.groupvu.com]
> Sent: Wednesday, March 07, 2001 1:21 PM
> To: jetspeed-dev@jakarta.apache.org
> Subject: Re: Servlet 2.2 Spec. and serving files from the WEB-INF
> directory
>
>
> Jon Stevens wrote:
> >
> > on 3/7/01 12:52 PM, "Raphaël Luta"
> <ra...@networks.groupvu.com>
> > wrote:
> >
> > > Yes, but then you need a configured container level
> authentication realm...
> >
> > No you don't. Only if you are going to provide web access to those
> > files...which you aren't.
> >
>
> From reading the 2.2 spec, I did not get the idea that the
> role mapping had
> to be applied by the container if no authentication realm was set up.
>
> If it's effectively the constated behavior on servlet 2.2
> containers, then
>
> I'm definitely +1 for moving the
>
> templates
> cache
> logs
>
> directory under the webapp, rather than the WEB-INF.
>
> --
> Raphaël Luta - raphael.luta@networks.groupvu.com
> Vivendi Universal Networks - Services Manager / Paris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
Re: Servlet 2.2 Spec. and serving files from the WEB-INF directory
Posted by Raphaël Luta <ra...@networks.groupvu.com>.
Jon Stevens wrote:
>
> on 3/7/01 12:52 PM, "Raphaël Luta" <ra...@networks.groupvu.com>
> wrote:
>
> > Yes, but then you need a configured container level authentication realm...
>
> No you don't. Only if you are going to provide web access to those
> files...which you aren't.
>
Re: Servlet 2.2 Spec. and serving files from the WEB-INF directory
Posted by Jon Stevens <jo...@latchkey.com>.
on 3/7/01 12:52 PM, "Raphaël Luta" <ra...@networks.groupvu.com>
wrote:
> Yes, but then you need a configured container level authentication realm...
No you don't. Only if you are going to provide web access to those
files...which you aren't.
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/ymtd/ymtd.html>
Re: Servlet 2.2 Spec. and serving files from the WEB-INF directory
Posted by Raphaël Luta <ra...@networks.groupvu.com>.
Jon Stevens wrote:
>
> on 3/7/01 12:19 PM, "Raphaël Luta" <ra...@networks.groupvu.com>
> wrote:
>
> > I put the templates in the WEB-INF directory because for systems such as
> > Velocity, they should never be accessed directly from a client so WEB-INF
> > was a natural solution.
>
> correct. or you can protect the directory with ACL's.
>
> <http://scarab.tigris.org/source/browse/scarab/src/conf/web.xml?rev=1.2&cont
> ent-type=text/x-cvsweb-markup>
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>templates</web-resource-name>
> <url-pattern>/templates/*</url-pattern>
> </web-resource-collection>
> <web-resource-collection>
> <web-resource-name>logs</web-resource-name>
> <url-pattern>/logs/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>admin</role-name>
> </auth-constraint>
> </security-constraint>
>
> That way, it is still easier for people to find the directory where the
> templates are stored.
>
Yes, but then you need a configured container level authentication realm...
What about dropping JSP ?
;-P (relax ingo, it's a joke...)
--
Raphaël Luta - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Services Manager / Paris
Re: Servlet 2.2 Spec. and serving files from the WEB-INF directory
Posted by Jon Stevens <jo...@latchkey.com>.
on 3/7/01 12:19 PM, "Raphaël Luta" <ra...@networks.groupvu.com>
wrote:
> I put the templates in the WEB-INF directory because for systems such as
> Velocity, they should never be accessed directly from a client so WEB-INF
> was a natural solution.
correct. or you can protect the directory with ACL's.
<http://scarab.tigris.org/source/browse/scarab/src/conf/web.xml?rev=1.2&cont
ent-type=text/x-cvsweb-markup>
<security-constraint>
<web-resource-collection>
<web-resource-name>templates</web-resource-name>
<url-pattern>/templates/*</url-pattern>
</web-resource-collection>
<web-resource-collection>
<web-resource-name>logs</web-resource-name>
<url-pattern>/logs/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
That way, it is still easier for people to find the directory where the
templates are stored.
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/ymtd/ymtd.html>
Re: Servlet 2.2 Spec. and serving files from the WEB-INF directory
Posted by Raphaël Luta <ra...@networks.groupvu.com>.
David Sean Taylor wrote:
>
> I've been trying to get Jetspeed to run with a particular vendor for quite a
> while now.
> I am not disclosing the name of the vendor, I replaced it below with
> *VENDOR-PRODUCT*
> I assume Websphere doesn't have a problem with serving files from the
> WEB-INF directory.
> Agreed that it makes it nice to have one WAR file for distribution, but any
> thoughts on 'breaking' the 2.2 spec?
>
> > I've run into a possible bug in our servlet container. Jetspeed is built
> > using Model 2 which involves lots of servlets, forwards, includes,
> > templates and lots of other crap that pretty much makes a webapp
> > unmaintainable. Most of Jetspeed's template resources, in the form of jsp
> > pages, are found in its WEB-INF directory. This is where the problem comes
> > in. According to the Servlet 2.2 spec section 9.4, "No file contained in
> > the WEB-INF directory may be served directly to a client." So
> *VENDOR-PRODUCT*
> > returns a 403 Forbidden error whenever a request is made to the container
> > that results in jsp template files being requested out of the WEB-INF
> > directory. Tomcat, on the other hand, does not prevent access to the
> > WEB-INF directory for template files. So the question is, are we doing the
> > correct thing according to the spec? Is processing a template file
> > considered serving a file directly to a client?
>
Processing a template is not serving a file in the general case, especially
Velocity templates sitting in WEB-INF should never cause any issue, however
JSPs are a special case and I'm not sure how Turbine handles JSPs as
templates, if you use any RequestDispatcher method, the servlet container
may certainly treat this as if the included file has been forwarded directly
to the client...
I put the templates in the WEB-INF directory because for systems such as
Velocity, they should never be accessed directly from a client so WEB-INF
was a natural solution.
Can you try to move the JSP templates to the base webapp directory
and use ${webapp.dir}/templates/jsp as the base JSP template dir ?
--
Raphaël Luta - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Services Manager / Paris
Re: JSP & Portlets
Posted by ingo schuster <in...@web.de>.
At 17:04 03/08/01, carlos beltran wrote:
>Hi,
>
>I am trying to load a jsp page with a FileServerPorlet and also from a
>WebPagePortlet...but it doesn't.
>
>The java code in the jsp page is directly copy to the final html
>source and it
>is not processed.
>Should these portlet be able to process jsp pages? If not!, is there a way
>to do
>this?
You need to use the EcsServletElement. I have a pice of code that does
this, the ServletInvokerPortlet. Seems as if I never committed it.
Just checked it into the portlets directory...
use this in the portlet registry:
<portlet-entry type="abstract" name="JSP">
<classname>org.apache.jetspeed.portal.portlets.ServletInvokerPortlet</classname>
</portlet-entry>
Note that this will have the same problems lke the customizer when used
with velocity as it uses the EcsServletElement.
ingo
>Thanks! And sorry if this question was already done.
>
>Carlos.
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
JSP & Portlets
Posted by carlos beltran <cb...@aitek.it>.
Hi,
I am trying to load a jsp page with a FileServerPorlet and also from a
WebPagePortlet...but it doesn't.
The java code in the jsp page is directly copy to the final html source and it
is not processed.
Should these portlet be able to process jsp pages? If not!, is there a way to do
this?
Thanks! And sorry if this question was already done.
Carlos.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org