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 Ate Douma <at...@douma.nu> on 2005/01/20 17:06:26 UTC
Re: [J2] Major new version of the Struts Bridge: version 0.2 now
available
Raphaël Luta said:
> Ate Douma wrote:
>
>> I'm happy to bring the news of a major upgrade of the Struts Bridge.
>>
> Have you notified the struts and pluto communities as well ?
No, not yet. I want to have the documentation in order before I'll do that.
Hopefully I'll have enough time the next few days to complete it.
>
> --
> Raphaël Luta - raphael.luta@aptiwan.com
> Aptiwan, l'intelligence des réseaux - http://www.aptiwan.com/
>
>
> ---------------------------------------------------------------------
> 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
Re: J2: Tiles support in Struts Bridge
Posted by Scott Heaberlin <he...@gmail.com>.
Actually, I can probably vouch for at least that much from my own experiences -
TilesPlugin explicitly checks the configured RequestProcessor to see
if it isAssignableFrom(TilesRequestProcessor.class) - otherwise during
initialization it logs an error message proclaiming incompatibility.
My previous e-mail was backwards; I have extended
TilestRequestProcessor and wrapped a PortletRequestProcessor instance.
In any event, I can't even get to where my request processor is ever
invoked due to the absence of the pluto PortalDefinition thread local
variable defined in JetspeedPortletFactoryProxy.
-Scott Heaberlin
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: J2: Tiles support in Struts Bridge
Posted by Ate Douma <at...@douma.nu>.
Scott Heaberlin wrote:
> See comments inline.
>
>
>>A TilesPortletRequestProcessor is planned!
>
>
> Excellent news!
>
>
>>I got a report from one user who created a new TilesPortletRequestProcessor
>>by extending the TilesRequestProcessor and merged in the PortletRequestProcessor
>>behavior. This, to his report, seems to be working flawlessly!
>
>
> Could you perhaps be a little more specific? I have tried an OO
> approach as well as in desperation cloning the process() and
> processRoles() methods in a TilesRequestProcessor subclass.
I haven't seen the code yet so I'm only passing on what I've been told, but
as far I know they modified the PortletRequestProcessor to extend TilesRequestProcessor
instead of wrapping one.
Colin: could you confirm this?
>
>
>>Note: this is a different solution to the one you describe below.
>
>
> Again, perhaps I am not following you when you say "merged in the
> PortletRequestProcessor behavior" - I feel like I have done this too
> from what I can tell. In fact, to be honest, I don't even think my
> request processor is even being invoked (it doesn't appear in the
> stack trace - see original thread)
>
> I attached a debugger and stepped through one request. My assumptions
> were confirmed - the request never makes it to any code I have
> authored. In fact, it dies within 5 lines of actually invoking the
> portlet itself (I am using StrutsPortlet).
>
> In an effort to learn and perhaps to contribute what I find, (not to
> mention to conquer this beast with whom I've been wrestling - I'm sure
> you can relate) I want to at least continue to try to get this to
> work. That in mind, I have one outstanding question based on the
> stack trace I originally posted (I will repost at the end of this
> message) combined with what I saw stepping through one request with
> the debugger.
>
> Somewhere between where ServletPortletInvoker::invoke() runs and
> JetspeedContainerServlet::doGet(), the ThreadLocal data within the
> JetspeedPortletFactoryProxy class seems to disappear. I have verified
> that within ServletPortletInvoker,
> JetspeedPortletFactoryProxy::setCurrentPortletDefinition(PortletDefinition)
> is indeed called with a non-null PortletDefinition.
>
> The next 7 calls in the stack are from javax.servlet, for which I do
> not have the source. By the time we reach
> JetspeedContainerServlet::doGet() -
> JetspeedPortletFactoryProxy::getCurrentPortletDefinition() returns
> null. 2 lines of code later, the container servlet attempts to get
> the name of the pluto PortletDefinition which is presumed to exist as
> a ThreadLocal variable - resulting in my NPE.
>
> Note, I am indeed using the latest cvs head, not an M build.
>
> I appreciate any insight you may have into this. If I can get this
> working, I'd be happy to contribute documentation and/or patches
> related to Tiles-in-J2 effort!
>
> Thanks in advance,
>
>
> -Scott
>
>
> Scott Heaberlin
>
> 2005-01-21 01:13:38
> StandardContext[/tilestest]JetspeedContainerServlet: Error rendering
> JetspeedContainerServlet error page: java.lang.NullPointerException
> java.lang.NullPointerException
> at org.apache.jetspeed.container.JetspeedContainerServlet.doGet(JetspeedContainerServlet.java:217)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
> at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:704)
> at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
> at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:510)
> at org.apache.jetspeed.container.invoker.ServletPortletInvoker.invoke(ServletPortletInvoker.java:213)
> at org.apache.jetspeed.container.invoker.ServletPortletInvoker.render(ServletPortletInvoker.java:124)
>
> ---------------------------------------------------------------------
> 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
Re: J2: Tiles support in Struts Bridge
Posted by Scott Heaberlin <he...@gmail.com>.
See comments inline.
> A TilesPortletRequestProcessor is planned!
Excellent news!
> I got a report from one user who created a new TilesPortletRequestProcessor
> by extending the TilesRequestProcessor and merged in the PortletRequestProcessor
> behavior. This, to his report, seems to be working flawlessly!
Could you perhaps be a little more specific? I have tried an OO
approach as well as in desperation cloning the process() and
processRoles() methods in a TilesRequestProcessor subclass.
> Note: this is a different solution to the one you describe below.
Again, perhaps I am not following you when you say "merged in the
PortletRequestProcessor behavior" - I feel like I have done this too
from what I can tell. In fact, to be honest, I don't even think my
request processor is even being invoked (it doesn't appear in the
stack trace - see original thread)
I attached a debugger and stepped through one request. My assumptions
were confirmed - the request never makes it to any code I have
authored. In fact, it dies within 5 lines of actually invoking the
portlet itself (I am using StrutsPortlet).
In an effort to learn and perhaps to contribute what I find, (not to
mention to conquer this beast with whom I've been wrestling - I'm sure
you can relate) I want to at least continue to try to get this to
work. That in mind, I have one outstanding question based on the
stack trace I originally posted (I will repost at the end of this
message) combined with what I saw stepping through one request with
the debugger.
Somewhere between where ServletPortletInvoker::invoke() runs and
JetspeedContainerServlet::doGet(), the ThreadLocal data within the
JetspeedPortletFactoryProxy class seems to disappear. I have verified
that within ServletPortletInvoker,
JetspeedPortletFactoryProxy::setCurrentPortletDefinition(PortletDefinition)
is indeed called with a non-null PortletDefinition.
The next 7 calls in the stack are from javax.servlet, for which I do
not have the source. By the time we reach
JetspeedContainerServlet::doGet() -
JetspeedPortletFactoryProxy::getCurrentPortletDefinition() returns
null. 2 lines of code later, the container servlet attempts to get
the name of the pluto PortletDefinition which is presumed to exist as
a ThreadLocal variable - resulting in my NPE.
Note, I am indeed using the latest cvs head, not an M build.
I appreciate any insight you may have into this. If I can get this
working, I'd be happy to contribute documentation and/or patches
related to Tiles-in-J2 effort!
Thanks in advance,
-Scott
Scott Heaberlin
2005-01-21 01:13:38
StandardContext[/tilestest]JetspeedContainerServlet: Error rendering
JetspeedContainerServlet error page: java.lang.NullPointerException
java.lang.NullPointerException
at org.apache.jetspeed.container.JetspeedContainerServlet.doGet(JetspeedContainerServlet.java:217)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:704)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:510)
at org.apache.jetspeed.container.invoker.ServletPortletInvoker.invoke(ServletPortletInvoker.java:213)
at org.apache.jetspeed.container.invoker.ServletPortletInvoker.render(ServletPortletInvoker.java:124)
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: J2: Tiles support in Struts Bridge
Posted by Ate Douma <at...@douma.nu>.
Sorry about this delayed response (I intended to reply to your earlier request
but forgot).
A TilesPortletRequestProcessor is planned!
I got a report from one user who created a new TilesPortletRequestProcessor
by extending the TilesRequestProcessor and merged in the PortletRequestProcessor
behavior. This, to his report, seems to be working flawlessly!
Note: this is a different solution to the one you describe below.
I intend to supply a TilesPortletRequestProcessor with the Struts Bridge once I
have found the time and an example Tiles Struts application I can test this out
with. I don't use Tiles myself, so it'll take some time for me to validate the
solution (which is a requirement before I commit it).
If anyone could supply me with a good test application which uses Tiles extensively
and is/should be behaving correctly within a Portlet (JSR-168) environment I would
appreciate it. It will certainly speed things up as I don't have time to look for
one myself right now.
Regards, Ate
Scott Heaberlin wrote:
> Resending this question with much more info:
>
> Any support yet for a TilesPortletRequestProcessor? Is there any
> reason why PortletRequestProcessor couldn't extend
> TilesRequestProcessor instead of the base Struts RequestProcessor? I
> ran into difficulties using the first Struts Bridge version with Tiles
> based apps because Tiles apps use TilesRequestProcessor instead of the
> default. Using the old PortletRequestProcessor in struts-config.xml
> for Tiles apps yielded exceptions.
>
> I attempted to write a derivative of TilesRequestProcessor similar to
> PortletRequestProcessor but I must have missed something and couldn't
> get it to work. What I tried was to extend the bridge's
> PortletRequestProcessor, adding a private TilesRequestProcessor
> instance and overriding in my PortletTilesRequestProcessor class the
> methods that org.apache.struts.tiles.TilesRequestProcessor overrides.
> My goal was to essentially perform the same operations as
> PortletRequetProcessor but also allow the processor to check URIs for
> requested tile defs.
>
>>>From the TilesRequestProcessor javadocs:
> <quote>
> catching is done by overloading the following methods:
> * processForwardConfig
> * internalModuleRelativeForward
> * internalModuleRelativeInclude
> </quote>
>
> So, I did the same thing in my extention of PortletRequestProcessor,
> and simply delegated the above overridden methods to my private
> TilesRequestProcessor instance.
>
> Unfortunately, no matter what I tried, I always had
> NullPointerExceptions thrown from JetspeedContainerServlet. From
> what I can tell, something just isn't right (I believe somehow some
> expected javax.portlet attribute(s) are missing in the request object
> passed to the container servlet... but as I'm neither a J2 internals
> expert nor a Struts/Tiles expert, I'm not quite sure how this
> happened.
>
> Any thoughts? Below is the top lines from the stack trace in my
> tomcat log. Note I only accessed the context from a .psml page within
> J2 (the tilestest.war was deployed within J2).
>
> Thanks in advance,
>
> -Scott Heaberlin
>
> log snippet:
>
> 2005-01-21 01:13:38
> StandardContext[/tilestest]JetspeedContainerServlet: Error rendering
> JetspeedContainerServlet error page: java.lang.NullPointerException
> java.lang.NullPointerException
> at org.apache.jetspeed.container.JetspeedContainerServlet.doGet(JetspeedContainerServlet.java:217)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
> at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:704)
> at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
> at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:510)
> at org.apache.jetspeed.container.invoker.ServletPortletInvoker.invoke(ServletPortletInvoker.java:213)
> at org.apache.jetspeed.container.invoker.ServletPortletInvoker.render(ServletPortletInvoker.java:124)
>
> ---------------------------------------------------------------------
> 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
J2: Tiles support in Struts Bridge
Posted by Scott Heaberlin <he...@gmail.com>.
Resending this question with much more info:
Any support yet for a TilesPortletRequestProcessor? Is there any
reason why PortletRequestProcessor couldn't extend
TilesRequestProcessor instead of the base Struts RequestProcessor? I
ran into difficulties using the first Struts Bridge version with Tiles
based apps because Tiles apps use TilesRequestProcessor instead of the
default. Using the old PortletRequestProcessor in struts-config.xml
for Tiles apps yielded exceptions.
I attempted to write a derivative of TilesRequestProcessor similar to
PortletRequestProcessor but I must have missed something and couldn't
get it to work. What I tried was to extend the bridge's
PortletRequestProcessor, adding a private TilesRequestProcessor
instance and overriding in my PortletTilesRequestProcessor class the
methods that org.apache.struts.tiles.TilesRequestProcessor overrides.
My goal was to essentially perform the same operations as
PortletRequetProcessor but also allow the processor to check URIs for
requested tile defs.
>From the TilesRequestProcessor javadocs:
<quote>
catching is done by overloading the following methods:
* processForwardConfig
* internalModuleRelativeForward
* internalModuleRelativeInclude
</quote>
So, I did the same thing in my extention of PortletRequestProcessor,
and simply delegated the above overridden methods to my private
TilesRequestProcessor instance.
Unfortunately, no matter what I tried, I always had
NullPointerExceptions thrown from JetspeedContainerServlet. From
what I can tell, something just isn't right (I believe somehow some
expected javax.portlet attribute(s) are missing in the request object
passed to the container servlet... but as I'm neither a J2 internals
expert nor a Struts/Tiles expert, I'm not quite sure how this
happened.
Any thoughts? Below is the top lines from the stack trace in my
tomcat log. Note I only accessed the context from a .psml page within
J2 (the tilestest.war was deployed within J2).
Thanks in advance,
-Scott Heaberlin
log snippet:
2005-01-21 01:13:38
StandardContext[/tilestest]JetspeedContainerServlet: Error rendering
JetspeedContainerServlet error page: java.lang.NullPointerException
java.lang.NullPointerException
at org.apache.jetspeed.container.JetspeedContainerServlet.doGet(JetspeedContainerServlet.java:217)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:704)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:510)
at org.apache.jetspeed.container.invoker.ServletPortletInvoker.invoke(ServletPortletInvoker.java:213)
at org.apache.jetspeed.container.invoker.ServletPortletInvoker.render(ServletPortletInvoker.java:124)
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Major new version of the Struts Bridge: version 0.2 now available
Posted by Scott Heaberlin <he...@gmail.com>.
Quick question -
Any support yet for a TilesPortletRequestProcessor? Is there any
reason why PortletRequestProcessor couldn't extend
TilesRequestProcessor instead of the base Struts RequestProcessor? I
ran into difficulties using the first Struts Bridge version with Tiles
based apps because Tiles apps use TilesRequestProcessor instead of the
default. Using the old PortletRequestProcessor in struts-config.xml
for Tiles apps yielded exceptions.
I attempted to write a derivative of TilesRequestProcessor similar to
PortletRequestProcessor but I must have missed something and couldn't
get it to work.
-Scott Heaberlin
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org