Jeff Sheets wrote:
Sorry for a second post, but I think I know where you are going with
this now. I deployed the struts-demo in Jetspeed on Weblogic Server. I didn't try to deploy the struts-demo in Weblogic Portal. That
hopefully answers your question...
Your previous message hasn't reached me yet (?), so no worries about second posts :-) Thanks for the answer.
Ate
On Wed, 17 Nov 2004 17:48:24 -0600, Jeff Sheets <[EMAIL PROTECTED]> wrote:
I never even looked at the ServletContextProvider spi interface. Deploying to Weblogic was nearly as easy as deploying to Tomcat or JBoss. I only needed to modify the two things that I mentioned earlier...
On Wed, 17 Nov 2004 22:58:15 +0100, Ate Douma <[EMAIL PROTECTED]> wrote:
Jeff Sheets wrote:
Ate, Actually, now that I look at it, it was only missing the src\java\org\apache\struts\webapp\example\CheckLogonTag.java file. I believe I saw the compile error when trying to access the logon screen, or possibly the register screen.
I scanned the source tree and you are right: it is still referenced from the app.tld although I stripped it usage from the sources. It seems Weblogic actually scans the tld and requires each referenced tag implementation class to be present. Tomcat/Jasper doesn't have this 'requirement' :-) I'll remove the reference from the app.tld too this evening. Thanks for the report!
Could you tell me if the ServletContextProvider spi interface implementation was easy for Weblogic? I have a report from another dev team using the Struts-Bridge on Vignette Application Portal (successfully) who needed to change the interface to be able to realize the implementation. (Guys, if you are reading this: I haven't found the time yet to see if I can incorporate your requirements but I have that still on my todo list.)
Maybe if could be interesting to create a repository of spi implementations for different portals providing a quick start for new users. Would you be allowed and willing to submit your implementation under ASF license?
Regards, Ate
Also, I suspect Weblogic might be accessing the original response anyway, although this should be a bug in their code.
And I must say, great working in writing the struts bridge! This will save us many hours when we portletize our apps!
Thanks! -- Jeff
On Wed, 17 Nov 2004 22:14:15 +0100, Ate Douma <[EMAIL PROTECTED]> wrote:
Jeff,
Thanks for providing this information.
I will look into this tonight but I expect your changes can be incorporated without harm or side-effect. I created the EmptyHttpServletResponseImpl as the lightest implementation to nullify any usage of the HttpServletResponse. Using a wrapper instead allows one to access the original response which is exactly what I wanted to prevent, but anyone doing so should be careful anyway.
You also wrote in a previous message you encountered a problem with missing taglib classes. Could you tell me which these were, and when they are accessed? I'm puzzled because I created this portlet version of the mail-reader demo and didn't have this problem yet.
Ate Douma
Jeff Sheets wrote:
I think I have a better fix now, and I would be happy to submit a patch if someone shows me how.
I changed the EmptyHttpServletResponseImpl into a EmptyHttpServletResponseWrapper. Then I modified this line in StrutsPortlet, line 269: if (actionRequest) { res = new EmptyHttpServletResponseImpl(); } to this: if (actionRequest) { res = new EmptyHttpServletResponseWrapper(res); }
Weblogic seems to be okay with it, and now I feel much better about the code itself. -- Jeff
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
