Re: JS 1.6 with Fusion Struts demo/JS1.6/ Sybase - AutoCommit failure
For reference if anyone come across this problem. You can fix this issue by modifying the repository_database.xml to have "useAutoCommit=0" added to it as shown below. Hema On Wed, 1 Dec 2004 18:35:17 -0600, Hema Menon <[EMAIL PROTECTED]> wrote: > Hi, > > I am trying to deploy the struts and jsf demo portlets on jetspeed 1.6 > with fusion. I find the following exception. It seems to be specific > to Sybase and might be related to OJB component. Also I was successful > in deploying these with Hsql database. Has anyone come across this > error? Any pointers? > > Thanks in advance, > Hema > Stack trace > INFO: Preparing to (re) deploy portlet app "jsf-demo" > INFO: Deploying portlet applicaion WAR jsf-demo > INFO: Portlet application deployment target directory is > D:\Tomcat5.0\webapps\ccportal/..//jsf-demo > INFO: Did not load extended metadata as it most likely does not > exist. java.io.FileNotFoundException: Unable to locate file or path > D:\Tomcat5.0\webapps\ccportal\..\jsf-demo\WEB-INF\jetspeed-portlet.xml > INFO: Loading web.xml into memory > INFO: Saving the portlet.xml in the registry... > [org.apache.ojb.broker.platforms.PlatformDefaultImpl] ERROR: Set > autoCommit(true) failed > SET CHAINED command not allowed within multi-statement transaction. > > com.sybase.jdbc2.jdbc.SybSQLException: SET CHAINED command not allowed > within multi-statement transaction. >at com.sybase.jdbc2.tds.Tds.processEed(Tds.java:2884) >at com.sybase.jdbc2.tds.Tds.nextResult(Tds.java:2206) >at com.sybase.jdbc2.jdbc.ResultGetter.nextResult(ResultGetter.java:69) >at com.sybase.jdbc2.jdbc.SybStatement.nextResult(SybStatement.java:220) >at com.sybase.jdbc2.jdbc.SybStatement.nextResult(SybStatement.java:203) >at > com.sybase.jdbc2.jdbc.SybStatement.updateLoop(SybStatement.java:1702) >at > com.sybase.jdbc2.jdbc.SybStatement.executeUpdate(SybStatement.java:1685) >at > com.sybase.jdbc2.jdbc.SybPreparedStatement.executeUpdate(SybPreparedStatement.java:115) >at com.sybase.jdbc2.tds.Tds.setOption(Tds.java:1206) >at > com.sybase.jdbc2.jdbc.SybConnection.setAutoCommit(SybConnection.java:986) >at > org.apache.commons.dbcp.DelegatingConnection.setAutoCommit(DelegatingConnection.java:268) >at > org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.setAutoCommit(PoolingDataSource.java:293) >at > org.apache.ojb.broker.platforms.PlatformDefaultImpl.changeAutoCommitState(PlatformDefaultImpl.java:199) >at > org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.restoreAutoCommitState(ConnectionManagerImpl.java:251) >at > org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.localCommit(ConnectionManagerImpl.java:195) >at > org.apache.ojb.broker.core.PersistenceBrokerImpl.commitTransaction(PersistenceBrokerImpl.java:434) >at > org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction(DelegatingPersistenceBroker.java:145) >at > org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction(DelegatingPersistenceBroker.java:145) >at > org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl.getSequence(SequenceManagerHighLowImpl.java:195) >at > org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl.getUniqueLong(SequenceManagerHighLowImpl.java:145) >at > org.apache.ojb.broker.util.sequence.AbstractSequenceManager.getUniqueValue(AbstractSequenceManager.java:139) >at > org.apache.ojb.broker.util.BrokerHelper.setAutoIncrementValue(BrokerHelper.java:317) >at > org.apache.ojb.broker.util.BrokerHelper.getValuesForObject(BrokerHelper.java:364) >at > org.apache.ojb.broker.util.BrokerHelper.getKeyValues(BrokerHelper.java:176) >at org.apache.ojb.broker.Identity.init(Identity.java:150) >at org.apache.ojb.broker.Identity.(Identity.java:119) >at > org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:691) >at > org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(DelegatingPersistenceBroker.java:175) >at > org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(DelegatingPersistenceBroker.java:175) >at > org.springframework.orm.ojb.PersistenceBrokerTemplate$8.doInPersistenceBroker(PersistenceBrokerTemplate.java:239) >at > org.springframework.orm.ojb.PersistenceBrokerTemplate.execute(PersistenceBrokerTemplate.java:152) >at > org.springframework.orm.ojb.PersistenceBrokerTemplate.store(PersistenceBrokerTemplate.java:237) >at > org.apache.jetspeed.components.portletregistry.PersistenceBrokerPortletRegistry.registerPortletApplication(PersistenceBrokerPortletRegistry.java:184) >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >
JS 1.6 with Fusion Struts demo/JS1.6/ Sybase - AutoCommit failure
Hi, I am trying to deploy the struts and jsf demo portlets on jetspeed 1.6 with fusion. I find the following exception. It seems to be specific to Sybase and might be related to OJB component. Also I was successful in deploying these with Hsql database. Has anyone come across this error? Any pointers? Thanks in advance, Hema Stack trace INFO: Preparing to (re) deploy portlet app "jsf-demo" INFO: Deploying portlet applicaion WAR jsf-demo INFO: Portlet application deployment target directory is D:\Tomcat5.0\webapps\ccportal/..//jsf-demo INFO: Did not load extended metadata as it most likely does not exist. java.io.FileNotFoundException: Unable to locate file or path D:\Tomcat5.0\webapps\ccportal\..\jsf-demo\WEB-INF\jetspeed-portlet.xml INFO: Loading web.xml into memory INFO: Saving the portlet.xml in the registry... [org.apache.ojb.broker.platforms.PlatformDefaultImpl] ERROR: Set autoCommit(true) failed SET CHAINED command not allowed within multi-statement transaction. com.sybase.jdbc2.jdbc.SybSQLException: SET CHAINED command not allowed within multi-statement transaction. at com.sybase.jdbc2.tds.Tds.processEed(Tds.java:2884) at com.sybase.jdbc2.tds.Tds.nextResult(Tds.java:2206) at com.sybase.jdbc2.jdbc.ResultGetter.nextResult(ResultGetter.java:69) at com.sybase.jdbc2.jdbc.SybStatement.nextResult(SybStatement.java:220) at com.sybase.jdbc2.jdbc.SybStatement.nextResult(SybStatement.java:203) at com.sybase.jdbc2.jdbc.SybStatement.updateLoop(SybStatement.java:1702) at com.sybase.jdbc2.jdbc.SybStatement.executeUpdate(SybStatement.java:1685) at com.sybase.jdbc2.jdbc.SybPreparedStatement.executeUpdate(SybPreparedStatement.java:115) at com.sybase.jdbc2.tds.Tds.setOption(Tds.java:1206) at com.sybase.jdbc2.jdbc.SybConnection.setAutoCommit(SybConnection.java:986) at org.apache.commons.dbcp.DelegatingConnection.setAutoCommit(DelegatingConnection.java:268) at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.setAutoCommit(PoolingDataSource.java:293) at org.apache.ojb.broker.platforms.PlatformDefaultImpl.changeAutoCommitState(PlatformDefaultImpl.java:199) at org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.restoreAutoCommitState(ConnectionManagerImpl.java:251) at org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.localCommit(ConnectionManagerImpl.java:195) at org.apache.ojb.broker.core.PersistenceBrokerImpl.commitTransaction(PersistenceBrokerImpl.java:434) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction(DelegatingPersistenceBroker.java:145) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction(DelegatingPersistenceBroker.java:145) at org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl.getSequence(SequenceManagerHighLowImpl.java:195) at org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl.getUniqueLong(SequenceManagerHighLowImpl.java:145) at org.apache.ojb.broker.util.sequence.AbstractSequenceManager.getUniqueValue(AbstractSequenceManager.java:139) at org.apache.ojb.broker.util.BrokerHelper.setAutoIncrementValue(BrokerHelper.java:317) at org.apache.ojb.broker.util.BrokerHelper.getValuesForObject(BrokerHelper.java:364) at org.apache.ojb.broker.util.BrokerHelper.getKeyValues(BrokerHelper.java:176) at org.apache.ojb.broker.Identity.init(Identity.java:150) at org.apache.ojb.broker.Identity.(Identity.java:119) at org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:691) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(DelegatingPersistenceBroker.java:175) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(DelegatingPersistenceBroker.java:175) at org.springframework.orm.ojb.PersistenceBrokerTemplate$8.doInPersistenceBroker(PersistenceBrokerTemplate.java:239) at org.springframework.orm.ojb.PersistenceBrokerTemplate.execute(PersistenceBrokerTemplate.java:152) at org.springframework.orm.ojb.PersistenceBrokerTemplate.store(PersistenceBrokerTemplate.java:237) at org.apache.jetspeed.components.portletregistry.PersistenceBrokerPortletRegistry.registerPortletApplication(PersistenceBrokerPortletRegistry.java:184) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.springframework.aop.framework.AopProxyUtils.invokeJoinpointUsingReflection(AopProxyUtils.java:61) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:149
Re: Fusion Struts Demo
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]
Re: Fusion Struts Demo
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]
Re: Fusion Struts Demo
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...
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 unsubs
Re: Fusion Struts Demo
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]
Re: Fusion Struts Demo
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.
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]
Re: Fusion Struts Demo
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]
Re: Fusion Struts Demo
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]
Re: Fusion Struts Demo
Well, I was able to fix the issue for Weblogic, but I'm not sure if it
is a good fix. I traced through some Weblogic classes to find that
internally they are trying to cast to a Weblogic implementation of
HttpServletResponse instead of using the interface itself. The quick
fix is to comment out these three lines (near line 170) in
StrutsPortlet that use the EmptyHttpServletResponseImpl:
if (rd != null)
{
//if (actionRequest) {
//res = new EmptyHttpServletResponseImpl();
//}
if (pageURL != null)
req.setAttribute(StrutsPortlet.PAGE_URL, pageURL);
req.setAttribute(StrutsPortlet.REQUEST_TYPE, requestType);
try
{
rd.include(new PortletServletRequestWrapper(servletContext,
req, query_string), res);
} catch (ServletException e)
I'm not sure what EmptyHttpServletResponseImpl is trying to do, so
there is probably a better fix to be found.
After this, I then got farther in the struts-demo, but came upon a jsp
compile error that was looking for a taglib class in the struts-demo.
The classes were in the Mailreader demo on the struts website, so I
just extracted the struts-example.war into the struts-demo without
overwriting any of the struts-demo files. Now the struts-demo works!
I just wanted to post my results in order to help anyone else who
tries to get the struts-demo working in Weblogic.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fusion Struts Demo
Well, this seems to be an issue with the struts-demo and Weblogic. I can hit the first page of the demo, and actually I can hit any page if I set it up as the first page in the portlet.xml. However I cannot click on a link and go to another page. When clicking on a link, weblogic throws the stack trace I showed earlier. This happens in the StrutsPortlet at: rd.include(new PortletServletRequestWrapper(servletContext, req, query_string), res); I found a post on the Weblogic website that mentions this problem, but I'm not sure that it is fully related: http://support.bea.com/application?namespace=askbea&origin=ask_bea_answer.jsp&event=link.view_answer_page_solution&answerpage=solution&page=wls/S-17206.htm Also, I haven't verified this, but I think this problem exists in Jetspeed2 as well as Fusion. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fusion Struts Demo
I'm trying get the struts-demo app working in Fusion. I have the other JSR-168 sample apps working, like the demo.war number guessing game, however the struts-demo.war is giving me some problems. I built from CVS head just two days ago. Here is the only exception trace that I can find (as generic as it might be), and any help would be greatly appreciated: 2004-11-16 10:47:47,718 [ExecuteThread: '11' for queue: 'weblogic.kernel.Default'] ERROR org.apache.portals.bridges.struts.StrutsPortlet - Include exception javax.servlet.ServletException: Original response not available at weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:470) at weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:400) at org.apache.portals.bridges.struts.StrutsPortlet.processRequest(StrutsPortlet.java:274) at org.apache.portals.bridges.struts.StrutsPortlet.processAction(StrutsPortlet.java:218) at org.apache.jetspeed.container.JetspeedContainerServlet.doGet(JetspeedContainerServlet.java:228) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:971) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:402) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305) at weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:607) at weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:400) at org.apache.jetspeed.container.invoker.ServletPortletInvoker.invoke(ServletPortletInvoker.java:213) at org.apache.jetspeed.container.invoker.ServletPortletInvoker.action(ServletPortletInvoker.java:132) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:148) at org.apache.jetspeed.container.JetspeedPortletContainerWrapper.processPortletAction(JetspeedPortletContainerWrapper.java:100) at org.apache.jetspeed.pipeline.valve.impl.ActionValveImpl.invoke(ActionValveImpl.java:75) at org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:209) at org.apache.jetspeed.container.ContainerValve.invoke(ContainerValve.java:76) at org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:209) at org.apache.jetspeed.fusion.security.impl.FusionSecurityValveImpl.invoke(FusionSecurityValveImpl.java:73) at org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:209) at org.apache.jetspeed.container.url.impl.PortalURLValveImpl.invoke(PortalURLValveImpl.java:55) at org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:209) at org.apache.jetspeed.fusion.profiler.impl.FusionProfilerValveImpl.invoke(FusionProfilerValveImpl.java:52) at org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:209) at org.apache.jetspeed.capabilities.impl.CapabilityValveImpl.invoke(CapabilityValveImpl.java:137) at org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:209) at org.apache.jetspeed.localization.impl.LocalizationValveImpl.invoke(LocalizationValveImpl.java:73) at org.apache.jetspeed.pipeline.JetspeedPipeline.invokeNext(JetspeedPipeline.java:209) at org.apache.jetspeed.pipeline.JetspeedPipeline.invoke(JetspeedPipeline.java:191) at org.apache.jetspeed.engine.AbstractEngine.service(AbstractEngine.java:251) at org.apache.jetspeed.fusion.modules.actions.FusionAccessController.doPerform(FusionAccessController.java:114) at org.apache.turbine.modules.Action.perform(Action.java:87) at org.apache.turbine.modules.ActionLoader.exec(ActionLoader.java:122) at org.apache.turbine.Turbine.doGet(Turbine.java:529) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:971) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:402) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6350) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3635) at weblogic.servlet.inter
