Re: problem with jetspeed2 on weblogic 8.1.2
Kurt, I do have an answer for you. Look at my post here that details the resolution: http://uncommentedbytes.blogspot.com/2004/11/problem-deploying-jetspeed-2-on.html I also copied in the jetspeed mailing list, to help out anyone else that has this problem. Thanks, -- Jeff On Fri, 11 Mar 2005 10:21:39 +0800, ååè <[EMAIL PROTECTED]> wrote: > > hi, jeff. > > > http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgId=2075612 > > From the jetspeed mailing list, I saw you message about deploying jetspeed > on weblogic 8, now I have some problems when deploying jetspeed demo on > weblogic, it's not the same with yours, I just follow the jetspeed fusion > instruction, but it still can't work, do you have any idea about it ? > > Thanks in advance! > > The following is the error message when deploying: > <2005-3-11 äå10æ19å38ç CST> > > <> <> > application jetspeed.> > <2005-3-11 äå10æ19å38ç CST> > > <> <> > javax.naming.ConfigurationException. Root exception is > java.net.MalformedURLException: no protocol: > at > weblogic.rmi.spi.ServerURL.parseURL(Lweblogic.rmi.spi.ServerURL;Ljava.lang.String;)V(ServerURL.java:353) > at > weblogic.rmi.spi.ServerURL.(Ljava.lang.String;)V(ServerURL.java:115) > at weblogic.rjvm.ServerURL.(Ljava.lang.String;)V(ServerURL.java:45) > at > weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(Lweblogic.jndi.Environment;Ljava.lang.String;)Ljavax.naming.Context;(WLInitialContextFactoryDelegate.java:296) > at > weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(Ljava.util.Hashtable;)Ljavax.naming.Context;(WLInitialContextFactoryDelegate.java:239) > at > weblogic.jndi.WLInitialContextFactory.getInitialContext(Ljava.util.Hashtable;)Ljavax.naming.Context;(WLInitialContextFactory.java:135) > at > javax.naming.spi.NamingManager.getInitialContext(Ljava.util.Hashtable;)Ljavax.naming.Context;(NamingManager.java:662) > at > javax.naming.InitialContext.getDefaultInitCtx()Ljavax.naming.Context;(InitialContext.java:243) > at > javax.naming.InitialContext.init(Ljava.util.Hashtable;)V(InitialContext.java:219) > at javax.naming.InitialContext.()V(InitialContext.java:175) > at > weblogic.deployment.EnvironmentBuilder.findObject(Ljava.lang.String;)Ljava.lang.Object;(EnvironmentBuilder.java:768) > at > weblogic.deployment.EnvironmentBuilder.findObjectOrCreateLinkRef(Ljava.lang.String;)Ljava.lang.Object;(EnvironmentBuilder.java:759) > at > weblogic.deployment.EnvironmentBuilder.addUserTransaction()V(EnvironmentBuilder.java:555) > at > weblogic.deployment.EnvironmentBuilder.(Ljavax.naming.Context;Ljava.lang.String;Ljava.lang.String;)V(EnvironmentBuilder.java:94) > at > weblogic.servlet.internal.CompEnv.(Ljavax.naming.Context;Lweblogic.servlet.internal.WebAppServletContext;Ljava.util.List;)V(CompEnv.java:80) > at > weblogic.servlet.internal.WebAppServletContext.init(Ljava.lang.String;Lweblogic.management.descriptors.WebDescriptorMBean;Z)V(WebAppServletContext.java:569) > at > weblogic.servlet.internal.WebAppServletContext.(Lweblogic.servlet.internal.HttpServer;Lweblogic.management.configuration.WebAppComponentMBean;Lweblogic.servlet.internal.WebAppModule;Lweblogic.management.ApplicationContainer;Lweblogic.application.ApplicationInfo;)V(WebAppServletContext.java:493) > at > weblogic.servlet.internal.HttpServer.loadWebApp(Lweblogic.management.configuration.WebAppComponentMBean;Lweblogic.management.ApplicationContainer;Lweblogic.application.ApplicationInfo;Lweblogic.servlet.internal.WebAppModule;)Lweblogic.servlet.internal.WebAppServletContext;(HttpServer.java:628) > at > weblogic.servlet.internal.WebAppModule.prepare(Ljava.lang.ClassLoader;[Lweblogic.management.configuration.VirtualHostMBean;ZLjava.lang.String;)V(WebAppModule.java:626) > at > weblogic.j2ee.J2EEApplicationContainer.prepareWebModule(Lweblogic.utils.classloaders.GenericClassLoader;Lweblogic.j2ee.J2EEApplicationContainer$Component;Z)V(J2EEApplicationContainer.java:3011) > at > weblogic.j2ee.J2EEApplicationContainer.prepareModules([Lweblogic.j2ee.J2EEApplicationContainer$Component;Ljava.lang.String;Z)V(J2EEApplicationContainer.java:1532) > at > weblogic.j2ee.J2EEApplicationContainer.prepare([Lweblogic.j2ee.J2EEApplicationContainer$Component;[Ljava.lang.String;Ljava.lang.String;Ljava.lang.String;)V(J2EEApplicationContainer.java:1188) > at > weblogic.j2ee.J2EEApplicationContainer.prepare(Ljava.lang.String;[Lweblogic.management.configuration.ComponentMBean;[Ljava.lang.String;)V(J2EEApplicationContainer.java:1031) > at > weblogic.management.deploy.slave.SlaveDeployer$ComponentActivateTask.prepareContainer()V(SlaveDeployer.java:2602) > at > weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.createContainer()Z(SlaveDeployer.java:2552) > at > weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.prepare()V(SlaveDeployer.java:2474) > at > weblogic.management.deploy.slave.SlaveDeployer.processPrepareTask(Lweblogic.management.deploy.Oam
Re: User Attributes with Struts Portlet bridge on Fusion
Thanks Frank. Redeployment seems to take care of it. I was thinking of
getting the login name, not the user first name. Now, how can I get
the logged in user's loginname and role?
Thanks,
Hema
On Thu, 10 Mar 2005 16:36:37 -0600, Frank Villarreal
<[EMAIL PROTECTED]> wrote:
> Make sure you re-deploy your portlet application, b/c J2 "caches" the
> portlet.xml in the database and will not pick up changes to your portlet.xml
> file if you edit it directly in "${webapps}/yourapp/WEB-INF/portlet.xml"
> directly ...
>
> - Frank
>
> > -Original Message-
> > From: Hema Menon [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, March 10, 2005 04:28 PM
> > To: Jetspeed-User
> > Subject: User Attributes with Struts Portlet bridge on Fusion
> >
> >
> > I am trying to get the user attributes (user name) from a servlet
> > filter in my struts application. I have the defined
> > in portlet.xml. However when I try to get the user attributes from the
> > PortletRequest, I am getting null. Is there something I am missing?
> > The code gets the PortletRequest first and then tries to get the
> > USER_INFO attribute from the PortletRequest.
> >
> > PortletRequest portletReq =
> > (PortletRequest)request.getAttribute("javax.portlet.request");
> > Map userInfo = (Map) portletReq.getAttribute(PortletRequest.USER_INFO);
> > This returns a null for userInfo.
> >
> > Can someone suggest a better way to getting the User information from
> > the struts portlet?
> >
> > Thanks,
> > Hema
> >
> > --
> >
> >
> > ~~
> > Hema Menon
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
--
~~
Hema Menon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Document for installing on Windows?
I have been picking over the various pages on the Apache web site for installing Jetspeed-2 and its associated programs, but I have been unable to piece it all together. Does anyone know of a Windows-oriented installation guide? -- Charles Knell [EMAIL PROTECTED] - email - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maximized Window State in decorator.top
Doug Schnelzer wrote: Hi, I want to know if any portlet on my page is in the maximized window state. I used to use the JPT to do this in the decorator.top (which was probably not really correct). I want to change (minimize) the portal banner when a portlet is in the maximized window state. My previous approach no longer works. Can someone point me in the right direction? Thanks, Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] fyi -- All of the layouts in the CVS use a different template for maximized Could you set a velocity variable in the layout that the decorator could pick up? Also, you have the columns available from the power tool #set($table = $jetspeed.columns) by walking the columns, you can find the first portlet (the first portlet is the only portlet in max mode) and then check its window state -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: User Attributes with Struts Portlet bridge on Fusion
Make sure you re-deploy your portlet application, b/c J2 "caches" the
portlet.xml in the database and will not pick up changes to your portlet.xml
file if you edit it directly in "${webapps}/yourapp/WEB-INF/portlet.xml"
directly ...
- Frank
> -Original Message-
> From: Hema Menon [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 10, 2005 04:28 PM
> To: Jetspeed-User
> Subject: User Attributes with Struts Portlet bridge on Fusion
>
>
> I am trying to get the user attributes (user name) from a servlet
> filter in my struts application. I have the defined
> in portlet.xml. However when I try to get the user attributes from the
> PortletRequest, I am getting null. Is there something I am missing?
> The code gets the PortletRequest first and then tries to get the
> USER_INFO attribute from the PortletRequest.
>
> PortletRequest portletReq =
> (PortletRequest)request.getAttribute("javax.portlet.request");
> Map userInfo = (Map) portletReq.getAttribute(PortletRequest.USER_INFO);
> This returns a null for userInfo.
>
> Can someone suggest a better way to getting the User information from
> the struts portlet?
>
> Thanks,
> Hema
>
> --
>
>
> ~~
> Hema Menon
>
> -
> 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]
Maximized Window State in decorator.top
Hi, I want to know if any portlet on my page is in the maximized window state. I used to use the JPT to do this in the decorator.top (which was probably not really correct). I want to change (minimize) the portal banner when a portlet is in the maximized window state. My previous approach no longer works. Can someone point me in the right direction? Thanks, Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
User Attributes with Struts Portlet bridge on Fusion
I am trying to get the user attributes (user name) from a servlet
filter in my struts application. I have the defined
in portlet.xml. However when I try to get the user attributes from the
PortletRequest, I am getting null. Is there something I am missing?
The code gets the PortletRequest first and then tries to get the
USER_INFO attribute from the PortletRequest.
PortletRequest portletReq =
(PortletRequest)request.getAttribute("javax.portlet.request");
Map userInfo = (Map) portletReq.getAttribute(PortletRequest.USER_INFO);
This returns a null for userInfo.
Can someone suggest a better way to getting the User information from
the struts portlet?
Thanks,
Hema
--
~~
Hema Menon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed 1.6-Fusion HELP!!!!
I second Hema on this one. It would be great to have > 1.6.1 release with M2, 1.6.2 with the Final Release -- Jeff On Thu, 10 Mar 2005 15:42:28 -0600, Hema Menon <[EMAIL PROTECTED]> wrote: > If anyone's asking :) , would be great to have. > 1.6.1 release with M2, 1.6.2 with the Final Release > > Hema > > On Thu, 10 Mar 2005 13:35:12 -0800, David Sean Taylor > <[EMAIL PROTECTED]> wrote: > > We need to figure out if we want to release 1.6 with: > > > > 2.0 M1 > > 2.0 M2 > > 2.0 Final Release > > > > We could do a 1.6.1 release with M2, 1.6.2 with the Final Release > > > > > > -- > > David Sean Taylor > > Bluesunrise Software > > [EMAIL PROTECTED] > > [office] +01 707 773-4646 > > [mobile] +01 707 529 9194 > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- > > ~~ > Hema Menon > > - > 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: Jetspeed 1.6-Fusion HELP!!!!
Same here...:-). My vote +1. Regards, Archana -Original Message- From: Hema Menon [mailto:[EMAIL PROTECTED] Sent: Thursday, March 10, 2005 3:42 PM To: Jetspeed Users List Subject: Re: Jetspeed 1.6-Fusion HELP If anyone's asking :) , would be great to have. 1.6.1 release with M2, 1.6.2 with the Final Release Hema On Thu, 10 Mar 2005 13:35:12 -0800, David Sean Taylor <[EMAIL PROTECTED]> wrote: > We need to figure out if we want to release 1.6 with: > > 2.0 M1 > 2.0 M2 > 2.0 Final Release > > We could do a 1.6.1 release with M2, 1.6.2 with the Final Release > > > -- > David Sean Taylor > Bluesunrise Software > [EMAIL PROTECTED] > [office] +01 707 773-4646 > [mobile] +01 707 529 9194 > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- ~~ Hema Menon - 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: Jetspeed 1.6-Fusion HELP!!!!
If anyone's asking :) , would be great to have. 1.6.1 release with M2, 1.6.2 with the Final Release Hema On Thu, 10 Mar 2005 13:35:12 -0800, David Sean Taylor <[EMAIL PROTECTED]> wrote: > We need to figure out if we want to release 1.6 with: > > 2.0 M1 > 2.0 M2 > 2.0 Final Release > > We could do a 1.6.1 release with M2, 1.6.2 with the Final Release > > > -- > David Sean Taylor > Bluesunrise Software > [EMAIL PROTECTED] > [office] +01 707 773-4646 > [mobile] +01 707 529 9194 > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- ~~ Hema Menon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed 1.6-Fusion HELP!!!!
Ate Douma wrote: > I know and you know that I started in the new deployment branch from a clean sheet. I explicitly stated that this would *initially* result in some features gone missing. I also said these features have to be recreated once we decide this proposed new deployment model. Right now, I have had no formal acknowledgment from *anyone* yet to go ahead and commit my changes to the main branch. Here is my acknowledgement: resolve the Fusion issues before merging. Probably everybody does know though I definitely would like to see this happen, but I will be the first to acknowledge that it isn't ready for that yet. Me too And then of course the integration with the ServerManager. This will be quite easy to bring back online. Actually, I've already done so. I have the TomcatManager working again. Furthermore, I created a new (secured) ManagerServlet through which you can interact with the ApplicationManagerServer as well as the PortletApplicationManager. I've used the Tomcat ManagerServlet as example for this. Right now I can list, start, stop, unregister and undeploy a PortletApplication all from the commandline or webbrowser and working without problems. Providing the same features to Fusion will be a peace of cake. Great I'm still working on an deploy command (uploading a deployment object like a war or decorator). The basic code is already in place, the only thing left to implement is the uploading part in the new commandline tool (JetspeedConsole). I'm putting in a lot of effort to get this all working even *better* than it did before, and I'm going to provide as much effort as needed to get Fusion working again with the new deployment model, once we decided it will be the used for J2. Perhaps we should formally call a vote on the jetspeed-dev list: 1. deprecate fusion Nonsense I'll take that as a -1 on deprecating Fusion ;) -or-- 2. require developers to test fusion I do care about Fusion and, as far you *can* require that, I have no objection to make it a policy. We should think about an easier way to test fusion do though because getting J1 and J2 to build right beside each other is quite a hassle... Frankly the whole situation has led to me becoming less and less involved in Jetspeed as my contributions are devaluated. I think you are over reacting. I value your contributions very highly and I know I'm not alone ;-) You did a hell of a job (and I know it was a hell of a job) to integrate J2 with J1, AKA Fusion. I think it is one of the most important contributions to Jetspeed (as a whole, J1 and J2 together) because it not only provides a JSR-168 container but also a view of the power of J2 and a migration path for J1 users not (yet) ready to make the jump to J2. Well, we did everything except put out a release, and its long overdue. We need to figure out if we want to release 1.6 with: 2.0 M1 2.0 M2 2.0 Final Release We could do a 1.6.1 release with M2, 1.6.2 with the Final Release -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed 1.6-Fusion HELP!!!!
Scott T Weaver wrote: I'm curious, which deployment refactoring has broken Fusion? Is it the things in Ate's branch or what is currently working in HEAD? Both, although the CVS head break is pretty minimal (api signature changes), whereas the branch is missing entire dependent interfaces and extended classes. -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed 1.6-Fusion HELP!!!!
David Sean Taylor wrote: Well we now have a new complication with Fusion. The CVS head for 2.0 will soon change its deployment model. In the deployment branch, quite a few interfaces that Fusion is dependent on are now deleted. The code doesn't even compile against this branch. Once again, J2 developers have no consideration for Fusion. This is a bold statement. I know and you know that I started in the new deployment branch from a clean sheet. I explicitly stated that this would *initially* result in some features gone missing. I also said these features have to be recreated once we decide this proposed new deployment model. Right now, I have had no formal acknowledgment from *anyone* yet to go ahead and commit my changes to the main branch. Probably everybody does know though I definitely would like to see this happen, but I will be the first to acknowledge that it isn't ready for that yet. Providing support back for undeployment, unregistration, registration, ServerManager integration, *AND FUSION* absolutely is a requirement I will stand for before moving to the new deployment model (if it comes to that). Now, I *did* look at Fusion when I started my deployment refactoring and how it is dependent on the current deployment features of J2. As far as I can tell (I'm no Fusion expert, I'll admit that), the currently missing features from the deployment branch are quite easy to replace, if not easier than it was initially (alright, maybe that's a bold statement of mine). The most prominent missing functionality in the new deployment branch for Fusion is the FilesystemPAM. All of its features (as used by Fusion) are now available from the new PortletApplicationManager. Maybe at first sight the deploy and undeploy features are still missing from it, but Fusion isn't actually using these methods, other than hooking into them to synchronize the J1 Registry. The new PortletApplicationManager registerPA and unregisterPA methods provide functionally the same hooks AFAIK. And then of course the integration with the ServerManager. This will be quite easy to bring back online. Actually, I've already done so. I have the TomcatManager working again. Furthermore, I created a new (secured) ManagerServlet through which you can interact with the ApplicationManagerServer as well as the PortletApplicationManager. I've used the Tomcat ManagerServlet as example for this. Right now I can list, start, stop, unregister and undeploy a PortletApplication all from the commandline or webbrowser and working without problems. Providing the same features to Fusion will be a peace of cake. I'm still working on an deploy command (uploading a deployment object like a war or decorator). The basic code is already in place, the only thing left to implement is the uploading part in the new commandline tool (JetspeedConsole). I'm putting in a lot of effort to get this all working even *better* than it did before, and I'm going to provide as much effort as needed to get Fusion working again with the new deployment model, once we decided it will be the used for J2. Perhaps we should formally call a vote on the jetspeed-dev list: 1. deprecate fusion Nonsense -or-- 2. require developers to test fusion I do care about Fusion and, as far you *can* require that, I have no objection to make it a policy. We should think about an easier way to test fusion do though because getting J1 and J2 to build right beside each other is quite a hassle... Frankly the whole situation has led to me becoming less and less involved in Jetspeed as my contributions are devaluated. I think you are over reacting. I value your contributions very highly and I know I'm not alone ;-) You did a hell of a job (and I know it was a hell of a job) to integrate J2 with J1, AKA Fusion. I think it is one of the most important contributions to Jetspeed (as a whole, J1 and J2 together) because it not only provides a JSR-168 container but also a view of the power of J2 and a migration path for J1 users not (yet) ready to make the jump to J2. As Jeff Sheets said in another response: J1 is much more stable and complete than J2. Fusion provides JSR-168 support *now* to end users of Jetspeed. Anyway, enough of my whining. ;-) What we could do put out the 1.6 release with 2.0 M1 But since the deployment is changing in M2, this means that Fusion is stuck at M1 until someone comes along and refactors the Fusion deployment. As I said above, I'm more than willing to do so. Doing that with your help would make it much quicker and easier though. Regards, Ate Im open to suggestions - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jetspeed 1.6-Fusion HELP!!!!
I'm curious, which deployment refactoring has broken Fusion? Is it the things in Ate's branch or what is currently working in HEAD? -Scott -Original Message- From: David Sean Taylor [mailto:[EMAIL PROTECTED] Sent: Thursday, March 10, 2005 3:51 PM To: Jetspeed Users List Subject: Re: Jetspeed 1.6-Fusion HELP Archana Turaga wrote: > Thanks for the reply. > > What about the database tables those come along with Jetspeed 2.0 > deployment? Are those all needed (they are the bunch of them) or only > the 2.0 jars are enough to get fusion going? > The database tables are included in the Fusion build if you build with the Fusion option on. This is all not yet documented. Getting this documentation of course will delay the release schedule. If we (all of us interested in Fusion) decide to release Jetspeed 1.6 (which includes Fusion) with 2.0 M1, then there are going to be some new features added to Jetspeed 2.0 that will be missing, mainly some nice improvements in the Struts bridge. If we wait for the M2 release, we get all the bug fixes, but then the means a substantial bit of work to get deployment working again in Fusion. We're hoping for an M2 release by the end of this month, but its looking doubtful now. -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194 - 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: Jetspeed 1.6-Fusion HELP!!!!
I believe the struts-bridge M2 version will work on the M1 release of Jetspeed 2, but someone will have to verify this for us. On Thu, 10 Mar 2005 12:51:10 -0800, David Sean Taylor <[EMAIL PROTECTED]> wrote: > Archana Turaga wrote: > > Thanks for the reply. > > > > What about the database tables those come along with Jetspeed 2.0 > > deployment? Are those all needed (they are the bunch of them) or only > > the 2.0 jars are enough to get fusion going? > > > The database tables are included in the Fusion build if you build with > the Fusion option on. This is all not yet documented. Getting this > documentation of course will delay the release schedule. > > If we (all of us interested in Fusion) decide to release Jetspeed 1.6 > (which includes Fusion) with 2.0 M1, then there are going to be some new > features added to Jetspeed 2.0 that will be missing, mainly some nice > improvements in the Struts bridge. > > If we wait for the M2 release, we get all the bug fixes, but then the > means a substantial bit of work to get deployment working again in > Fusion. We're hoping for an M2 release by the end of this month, but its > looking doubtful now. > > > -- > David Sean Taylor > Bluesunrise Software > [EMAIL PROTECTED] > [office] +01 707 773-4646 > [mobile] +01 707 529 9194 > > - > 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: Jetspeed 1.6-Fusion HELP!!!!
Archana Turaga wrote: Thanks for the reply. What about the database tables those come along with Jetspeed 2.0 deployment? Are those all needed (they are the bunch of them) or only the 2.0 jars are enough to get fusion going? The database tables are included in the Fusion build if you build with the Fusion option on. This is all not yet documented. Getting this documentation of course will delay the release schedule. If we (all of us interested in Fusion) decide to release Jetspeed 1.6 (which includes Fusion) with 2.0 M1, then there are going to be some new features added to Jetspeed 2.0 that will be missing, mainly some nice improvements in the Struts bridge. If we wait for the M2 release, we get all the bug fixes, but then the means a substantial bit of work to get deployment working again in Fusion. We're hoping for an M2 release by the end of this month, but its looking doubtful now. -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jetspeed 1.6-Fusion HELP!!!!
Thanks for the reply. What about the database tables those come along with Jetspeed 2.0 deployment? Are those all needed (they are the bunch of them) or only the 2.0 jars are enough to get fusion going? Regards, Archana -Original Message- From: David Sean Taylor [mailto:[EMAIL PROTECTED] Sent: Thursday, March 10, 2005 12:53 PM To: Jetspeed Users List Subject: Re: Jetspeed 1.6-Fusion HELP Archana Turaga wrote: > Thanks for the reply Jeff. But I know in the past they have said that > when Jetspeed 1.6 is released you do not need to build Jetspeed 2.0. > Won't that be really convenient...if it works that way? The 1.6 release will only require jars from Jetspeed 2.0 If that is M1 or M2 is yet to be determined... -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194 - 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: Jetspeed 1.6-Fusion HELP!!!!
Hi David, I completely agree with Hema and Jeff. I for one really need this combination going since this is going to be production software...otherwise I'm hosed. My vote also would be to not deprecate Fusion. I'm all for trying anything to get Jetspeed 1 with Fusion going. The news you gave us was very disappointing and unfortunate. I have been watching the mailing list for long (since that was the lifeline for me when I was working with 1.5 and now with Fusion) and I have seen how your contribution has been and I know it was valuable to me. Based on what you said I think at least get Jetspeed 1.6 out (since that is quiet stable and we do not have to worry about building it) and then next try to get the developers to test fusion. If that is not possible then release the binaries for fusion that are in M1 which work with Jetspeed 1.6so at least we are not lost. Also list out the known issues with Fusion so that we can get them addressed...somehow. There are a lot of people who are using 1.5 /1.6 and still need support. We and those people cannot be left in a lurch. I personally would at least try appealing to the developers to test Fusion and see if they can get that going. Thanks David for your replies. At least we know where we stand. And If you want we can all vote you in to show how valuable your contribution is...;-) Regards, Archana -Original Message- From: Hema Menon [mailto:[EMAIL PROTECTED] Sent: Thursday, March 10, 2005 1:52 PM To: Jetspeed Users List; [EMAIL PROTECTED] Subject: Re: Jetspeed 1.6-Fusion HELP David, I too would like to echo what Jeff is talking about. For us too, Fusion was a must to get our struts portlet running, otherwise we were very much happy with what Jetspeed 1.5 offered. We are not yet ready to move to JS2, due to the changes from JS1.5. So Fusion is doing for us what JS2 has in the offing. My vote would be to not deprecate Fusion. P.S - Sorry to hear about your disappointment. We, the users of Jetspeed value your and the contributions of the developers here at Jetspeed, very much. Thanks. Thanks, Hema On Thu, 10 Mar 2005 13:43:04 -0600, Jeff Sheets <[EMAIL PROTECTED]> wrote: > David, > > I definitely vote to support Fusion. My reasoning is that Jetspeed 1 > is much more stable and complete than Jetspeed 2, even if the > architecture is lacking. With Jetspeed 1 and the JSR 168 capabilities > of 1.6 Fusion, we would have everything we need until 2 if finally > finished. > > And I see I was not correct about the build being ok. After checking > out the use-fusion.xml file, I see that Jetspeed 1 builds with the > Jetspeed 2 M1 files that were still cached in Maven. Switching this > to M2-dev does break the build. > > I, for one, highly value your work on Fusion. Without Fusion, we > would have found another portal to work with, because JSR-168 is a > high priority item for our portlets. > > Thank you, > -- Jeff > > On Thu, 10 Mar 2005 10:52:54 -0800, David Sean Taylor > <[EMAIL PROTECTED]> wrote: > > Archana Turaga wrote: > > > Thanks for the reply Jeff. But I know in the past they have said that > > > when Jetspeed 1.6 is released you do not need to build Jetspeed 2.0. > > > Won't that be really convenient...if it works that way? > > > > The 1.6 release will only require jars from Jetspeed 2.0 > > If that is M1 or M2 is yet to be determined... > > > > -- > > David Sean Taylor > > Bluesunrise Software > > [EMAIL PROTECTED] > > [office] +01 707 773-4646 > > [mobile] +01 707 529 9194 > > > > - > > 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] > > -- ~~ Hema Menon - 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: Jetspeed 1.6-Fusion HELP!!!!
David, I too would like to echo what Jeff is talking about. For us too, Fusion was a must to get our struts portlet running, otherwise we were very much happy with what Jetspeed 1.5 offered. We are not yet ready to move to JS2, due to the changes from JS1.5. So Fusion is doing for us what JS2 has in the offing. My vote would be to not deprecate Fusion. P.S - Sorry to hear about your disappointment. We, the users of Jetspeed value your and the contributions of the developers here at Jetspeed, very much. Thanks. Thanks, Hema On Thu, 10 Mar 2005 13:43:04 -0600, Jeff Sheets <[EMAIL PROTECTED]> wrote: > David, > > I definitely vote to support Fusion. My reasoning is that Jetspeed 1 > is much more stable and complete than Jetspeed 2, even if the > architecture is lacking. With Jetspeed 1 and the JSR 168 capabilities > of 1.6 Fusion, we would have everything we need until 2 if finally > finished. > > And I see I was not correct about the build being ok. After checking > out the use-fusion.xml file, I see that Jetspeed 1 builds with the > Jetspeed 2 M1 files that were still cached in Maven. Switching this > to M2-dev does break the build. > > I, for one, highly value your work on Fusion. Without Fusion, we > would have found another portal to work with, because JSR-168 is a > high priority item for our portlets. > > Thank you, > -- Jeff > > On Thu, 10 Mar 2005 10:52:54 -0800, David Sean Taylor > <[EMAIL PROTECTED]> wrote: > > Archana Turaga wrote: > > > Thanks for the reply Jeff. But I know in the past they have said that > > > when Jetspeed 1.6 is released you do not need to build Jetspeed 2.0. > > > Won't that be really convenient...if it works that way? > > > > The 1.6 release will only require jars from Jetspeed 2.0 > > If that is M1 or M2 is yet to be determined... > > > > -- > > David Sean Taylor > > Bluesunrise Software > > [EMAIL PROTECTED] > > [office] +01 707 773-4646 > > [mobile] +01 707 529 9194 > > > > - > > 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] > > -- ~~ Hema Menon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed 1.6-Fusion HELP!!!!
David, I definitely vote to support Fusion. My reasoning is that Jetspeed 1 is much more stable and complete than Jetspeed 2, even if the architecture is lacking. With Jetspeed 1 and the JSR 168 capabilities of 1.6 Fusion, we would have everything we need until 2 if finally finished. And I see I was not correct about the build being ok. After checking out the use-fusion.xml file, I see that Jetspeed 1 builds with the Jetspeed 2 M1 files that were still cached in Maven. Switching this to M2-dev does break the build. I, for one, highly value your work on Fusion. Without Fusion, we would have found another portal to work with, because JSR-168 is a high priority item for our portlets. Thank you, -- Jeff On Thu, 10 Mar 2005 10:52:54 -0800, David Sean Taylor <[EMAIL PROTECTED]> wrote: > Archana Turaga wrote: > > Thanks for the reply Jeff. But I know in the past they have said that > > when Jetspeed 1.6 is released you do not need to build Jetspeed 2.0. > > Won't that be really convenient...if it works that way? > > The 1.6 release will only require jars from Jetspeed 2.0 > If that is M1 or M2 is yet to be determined... > > -- > David Sean Taylor > Bluesunrise Software > [EMAIL PROTECTED] > [office] +01 707 773-4646 > [mobile] +01 707 529 9194 > > - > 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]
JetSpeed/Tomcat stress test Error
Hello to all, I have been making some stress tests on tomcat using JMeter tool and at any time the tomcat shutdown and generate the exception below. Anybody already got it or know what is it? I'm using JetSpeed 1.5 Thanks for the help Regards Carlos Torres. Unexpected Signal : EXCEPTION_ILLEGAL_INSTRUCTION (0xc01d) occurred at PC=0x804F702 Function=[Unknown.] Library=C:\j2sdk1.4.2_07\jre\bin\client\jvm.dll NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.apache.turbine.services.assemblerbroker.util.java.JavaBaseFactory.getAssembler(JavaBaseFactory.java:93) at org.apache.turbine.services.assemblerbroker.util.java.JavaPageFactory.getAssembler(JavaPageFactory.java:69) at org.apache.turbine.services.assemblerbroker.TurbineAssemblerBrokerService.getAssembler(TurbineAssemblerBrokerService.java:189) at org.apache.turbine.modules.PageLoader.getInstance(PageLoader.java:153) at org.apache.turbine.modules.PageLoader.exec(PageLoader.java:123) at org.apache.turbine.Turbine.doGet(Turbine.java:563) at org.apache.turbine.Turbine.doPost(Turbine.java:658) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) 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.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) at java.lang.Thread.run(Thread.java:534) Dynamic libraries: 0x0040 - 0x0040B000 C:\j2sdk1.4.2_07\bin\java.exe 0x77F5 - 0x77FFB000 C:\WINDOWS\System32\ntdll.dll 0x77E5 - 0x77F4 C:\WINDOWS\system32\kernel32.dll 0x77DB - 0x77E4D000 C:\WINDOWS\system32\ADVAPI32.dll 0x7800 - 0x78087000 C:\WINDOWS\system32\RPCRT4.dll 0x77BF - 0x77C43000 C:\WINDOWS\system32\MSVCRT.dll 0x0800 - 0x08138000 C:\j2sdk1.4.2_07\jre\bin\client\jvm.dll 0x77D2 - 0x77DB C:\WINDOWS\system32\USER32.dll 0x7F00 - 0x7F041000 C:\WINDOWS\system32\GDI32.dll 0x76B2 - 0x76B4D000 C:\WINDOWS\System32\WINMM.dll 0x6BD0 - 0x6BD0D000 C:\WINDOWS\System32\SYNCOR11.DLL 0x1000 - 0x10007000 C:\j2sdk1.4.2_07\jre\bin\hpi.dll 0x0039 - 0x0039E000 C:\j2sdk1.4.2_07\jre\bin\verify.dll 0x003A - 0x003B9000 C:\j2sdk1.4.2_07\jre\bin\java.dll 0x003C - 0x003CD000 C:\j2sdk1.4.2_07\jre\bin\zip.dll 0x003F - 0x003FF000 C:\j2sdk1.4.2_07\jre\bin\net.dll 0x71A7 - 0x71A85000 C:\WINDOWS\System32\WS2_32.dll 0x71A6 - 0x71A68000 C:\WINDOWS\System32\WS2HELP.dll 0x71A1 - 0x71A4C000 C:\WINDOWS\System32\mswsock.dll 0x76F0 - 0x76F25000 C:\WINDOWS\System32\DNSAPI.dll 0x76F9 - 0x76F97000 C:\WINDOWS\System32\winrnr.dll 0x76F4 - 0x76F6D000 C:\WINDOWS\system32\WLDAP32.dll 0x76FA - 0x76FA5000 C:\WINDOWS\System32\rasadhlp.dll 0x71A5 - 0x71A58000 C:\WINDOWS\System32\wshtcpip.dll 0x76C7 - 0x76C92000 C:\WINDOWS\system32\imagehlp.dll 0x6DA7 - 0x6DAED000 C:\WINDOW
Re: Jetspeed 1.6-Fusion HELP!!!!
Archana Turaga wrote: Thanks for the reply Jeff. But I know in the past they have said that when Jetspeed 1.6 is released you do not need to build Jetspeed 2.0. Won't that be really convenient...if it works that way? The 1.6 release will only require jars from Jetspeed 2.0 If that is M1 or M2 is yet to be determined... -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed 1.6-Fusion HELP!!!!
Archana Turaga wrote: Hi, We really need to know when Jetspeed 1.6 is going to be released. We need it more so because of its ability to support struts with Fusion and we are depending on it very heavily for our implementation. At the most we need to know what binaries from 2.0 are needed to get fusion going since Jetspeed 2.0 adds a whole bunch of tables to the database and we do not know which are needed and which are not. Please let us know the release date or at-least give us a list of binaries/tables that need to get fusion going on top of Jetspeed 1.6. I know David said that it will be out Feb end and I also know that you guys are all very busy but please can you let us know the status? Thanks a lot for your co-operation. Regards, Archana Well we now have a new complication with Fusion. The CVS head for 2.0 will soon change its deployment model. In the deployment branch, quite a few interfaces that Fusion is dependent on are now deleted. The code doesn't even compile against this branch. Once again, J2 developers have no consideration for Fusion. Perhaps we should formally call a vote on the jetspeed-dev list: 1. deprecate fusion -or-- 2. require developers to test fusion Frankly the whole situation has led to me becoming less and less involved in Jetspeed as my contributions are devaluated. Anyway, enough of my whining. What we could do put out the 1.6 release with 2.0 M1 But since the deployment is changing in M2, this means that Fusion is stuck at M1 until someone comes along and refactors the Fusion deployment. Im open to suggestions -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts bridge, lost request parameters
Colin, My apologies, because your fix does work for me!!! Thank you! My actual code was: actionResponse.setPortletMode(PortletMode.VIEW); return mapping.findForward(FORWARD_VIEW); As this worked before your fix to at least return me to the View page. But now we need to forward back to the edit page, so that when we return to the edit mode we get the page correctly. So my code now looks like this: actionResponse.setPortletMode(PortletMode.VIEW); return mapping.findForward(FORWARD_EDIT); Thank you very much for your help! Ate, hopefully this can be committed to the baseline soon? -- Jeff On Thu, 10 Mar 2005 16:18:14 -, Colin O'Toole <[EMAIL PROTECTED]> wrote: > Hi Jeff, > > That is similar to what I'm doing except that I don't make the portlet > automatically return to the view mode after submitting an edit page change. > I stay in edit until the user explicitly clicks the view button. > > If you enable debug logging you should get some detailed information about > what is happening when you click the edit button. I also found that remote > debugging the app and setting breakpoints in StrutsPortlet.processRequest() > made it easy to figure out what was going on. > > I will add the actionResponse.setPortletMode(PortletMode.VIEW); to my edit > action code and see if it breaks anything. Might tae me a while to get > around to it though :-) > > Cheers, > > Colin. > > -Original Message- > From: Jeff Sheets [mailto:[EMAIL PROTECTED] > Sent: 10 March 2005 15:57 > To: Jetspeed Users List > Subject: Re: Struts bridge, lost request parameters > > Colin, > > Your quick fix didn't work for me. Perhaps my flow is wrong. Here is > what I am doing. > > Displaying the View page (/myaction.do). Clicking the edit icon to go > to the Edit page (/editmyaction.do). Then after hitting save on the > edit page, I have to tell it to go back to the view page by doing this > in the action class: > actionResponse.setPortletMode(PortletMode.VIEW); > > It returns to the View page correctly (like it always has). Clicking > on the edit button simply refreshes the view page, instead of taking > me back to the edit screen. This is the same result as before I > applied you fix. > > Have I done something differently than you? > > Thanks, > -- Jeff > > On Thu, 10 Mar 2005 11:44:15 -, Colin O'Toole > <[EMAIL PROTECTED]> wrote: > > Ah! OK I will try this but it will have to wait until tomorrow. because > of > > time constraints I may stick with what I have and do a wholesale upgrade > > once M2 is released. > > > > Thanks for the help! > > > > Colin. > > > > -Original Message- > > From: Ate Douma [mailto:[EMAIL PROTECTED] > > Sent: 10 March 2005 11:30 > > To: Jetspeed Users List > > Subject: Re: Struts bridge, lost request parameters > > > > Colin O'Toole wrote: > > > Hi Ate, > > > > > > OK, I made the changes you detailed and tried this and what happens is: > > > > > > (1) Clicking on link goes to LocaleAction (ActionUrl). Using remote > > > debugging in eclipse with a breakpoint in LocaleAction.execute(), the > > > PortletServletRequestWrapper object contains an ApplicationContextFacade > > and > > > a ServletRequestImpl. The ServletRequestImpl contains an > > > ApplicationHttpRequestObject. The queryParamString member of the > > > ApplicationHttpRequestObject holds the params > > > "language=ja&forward=testredirect". (This is what I saw in my example > > also) > > > > > > (2) In LocaleAction the following code is run: > > > > > > target = request.getParameter(FORWARD); > > > > > > This returns null - the parameter "forward=testredirect" is not found in > > the > > > request. This causes the following code to be executed: > > > > > > if (isBlank(target)) target = mapping.getParameter(); > > > > > > return mapping.findForward(target); > > > > > > "target" is the default welcome global mapping from the > struts-config.xml, > > > so the WelcomeAction is called. > > > > > > So in fact for me it appears that request params are being lost > > wholesale - > > > irrespective of whether or not it is a redirect or a simple forward. I > am > > > using Tomcat 5.5.4, Windows XP, JDK 1.4.2_05, JetSpeed M1. I will try > > later > > > today with Tomcat 5.0.28 which I also have. > > Now we are getting somewhere: you are running Jetspeed 2 M1... > > > > I'm not sure but I think that will be the reason. I don't test or develop > > against > > M1 anymore. As we are approaching a M2 release very soon, I suggest you > try > > your > > application with the latest CVS HEAD if possible. > > > > > > > > If I run the above code with the old version - which expressly parses > the > > > querystring in StrutsPortlet and passes it into > > > PortletServletRequestWrapper, it works as you describe. I'm a bit > stumped > > > here. :-) > > > > > > Can you help me understand where the params go in the new > > > PortletServletRequestWrapper? In the old PortletServletRequestWrapper I > > > could see that in Dispa
RE: Jetspeed 1.6-Fusion HELP!!!!
Thanks for the reply Jeff. But I know in the past they have said that when Jetspeed 1.6 is released you do not need to build Jetspeed 2.0. Won't that be really convenient...if it works that way? Also if there is a release we do not have to setup an independent box ,only to compile Jetspeed stuff to get Jetspeed binaries. I guess it is just one of those deals where if the product is certified as released you feel more comfortable to work with and lesser concerns of how the build environment needs to be setup etc. Although I like the fact that the source is always available for use if needed (And I really needed it when I worked with Jetspeed 1.5)...helps in understanding the working of Jetspeed better. Regards, Archana -Original Message- From: Jeff Sheets [mailto:[EMAIL PROTECTED] Sent: Thursday, March 10, 2005 10:12 AM To: Jetspeed Users List Subject: Re: Jetspeed 1.6-Fusion HELP My 1.6 Fusion build required me to add the tables from Jetspeed 1 and the tables from Jetspeed 2. I didn't try to remove any tables that might not be needed, but adding all of them works. Also, I have just downloaded the latest source for Jetspeed 2 and 1, compiled and deployed Fusion, and everything is working great. So I would suggest getting the latest source for both, unless someone higher up the chain disagrees. On Thu, 10 Mar 2005 10:07:12 -0600, Archana Turaga <[EMAIL PROTECTED]> wrote: > Hi, > > We really need to know when Jetspeed 1.6 is going to be released. We > need it more so because of its ability to support struts with Fusion and > we are depending on it very heavily for our implementation. > > At the most we need to know what binaries from 2.0 are needed to get > fusion going since Jetspeed 2.0 adds a whole bunch of tables to the > database and we do not know which are needed and which are not. > > Please let us know the release date or at-least give us a list of > binaries/tables that need to get fusion going on top of Jetspeed 1.6. > > I know David said that it will be out Feb end and I also know that you > guys are all very busy but please can you let us know the status? > > Thanks a lot for your co-operation. > Regards, > Archana > > - > 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: Struts bridge, lost request parameters
Hi Jeff, That is similar to what I'm doing except that I don't make the portlet automatically return to the view mode after submitting an edit page change. I stay in edit until the user explicitly clicks the view button. If you enable debug logging you should get some detailed information about what is happening when you click the edit button. I also found that remote debugging the app and setting breakpoints in StrutsPortlet.processRequest() made it easy to figure out what was going on. I will add the actionResponse.setPortletMode(PortletMode.VIEW); to my edit action code and see if it breaks anything. Might tae me a while to get around to it though :-) Cheers, Colin. -Original Message- From: Jeff Sheets [mailto:[EMAIL PROTECTED] Sent: 10 March 2005 15:57 To: Jetspeed Users List Subject: Re: Struts bridge, lost request parameters Colin, Your quick fix didn't work for me. Perhaps my flow is wrong. Here is what I am doing. Displaying the View page (/myaction.do). Clicking the edit icon to go to the Edit page (/editmyaction.do). Then after hitting save on the edit page, I have to tell it to go back to the view page by doing this in the action class: actionResponse.setPortletMode(PortletMode.VIEW); It returns to the View page correctly (like it always has). Clicking on the edit button simply refreshes the view page, instead of taking me back to the edit screen. This is the same result as before I applied you fix. Have I done something differently than you? Thanks, -- Jeff On Thu, 10 Mar 2005 11:44:15 -, Colin O'Toole <[EMAIL PROTECTED]> wrote: > Ah! OK I will try this but it will have to wait until tomorrow. because of > time constraints I may stick with what I have and do a wholesale upgrade > once M2 is released. > > Thanks for the help! > > Colin. > > -Original Message- > From: Ate Douma [mailto:[EMAIL PROTECTED] > Sent: 10 March 2005 11:30 > To: Jetspeed Users List > Subject: Re: Struts bridge, lost request parameters > > Colin O'Toole wrote: > > Hi Ate, > > > > OK, I made the changes you detailed and tried this and what happens is: > > > > (1) Clicking on link goes to LocaleAction (ActionUrl). Using remote > > debugging in eclipse with a breakpoint in LocaleAction.execute(), the > > PortletServletRequestWrapper object contains an ApplicationContextFacade > and > > a ServletRequestImpl. The ServletRequestImpl contains an > > ApplicationHttpRequestObject. The queryParamString member of the > > ApplicationHttpRequestObject holds the params > > "language=ja&forward=testredirect". (This is what I saw in my example > also) > > > > (2) In LocaleAction the following code is run: > > > > target = request.getParameter(FORWARD); > > > > This returns null - the parameter "forward=testredirect" is not found in > the > > request. This causes the following code to be executed: > > > > if (isBlank(target)) target = mapping.getParameter(); > > > > return mapping.findForward(target); > > > > "target" is the default welcome global mapping from the struts-config.xml, > > so the WelcomeAction is called. > > > > So in fact for me it appears that request params are being lost > wholesale - > > irrespective of whether or not it is a redirect or a simple forward. I am > > using Tomcat 5.5.4, Windows XP, JDK 1.4.2_05, JetSpeed M1. I will try > later > > today with Tomcat 5.0.28 which I also have. > Now we are getting somewhere: you are running Jetspeed 2 M1... > > I'm not sure but I think that will be the reason. I don't test or develop > against > M1 anymore. As we are approaching a M2 release very soon, I suggest you try > your > application with the latest CVS HEAD if possible. > > > > > If I run the above code with the old version - which expressly parses the > > querystring in StrutsPortlet and passes it into > > PortletServletRequestWrapper, it works as you describe. I'm a bit stumped > > here. :-) > > > > Can you help me understand where the params go in the new > > PortletServletRequestWrapper? In the old PortletServletRequestWrapper I > > could see that in DispatchedHttpServletRequestWrapper they were parsed > into > > a map. I'm unsure as to where they end up now. > > > > Thanks, > > Colin. > > > > > > -Original Message- > > From: Ate Douma [mailto:[EMAIL PROTECTED] > > Sent: 09 March 2005 22:41 > > To: Jetspeed Users List > > Subject: Re: Struts bridge, lost request parameters > > > > > > Colin, > > > > I took some time to create a testcase with a similar flow as you described > > earlier. > > For this, I used the struts-demo as provided with Jetspeed-2. > > Could you please check if this is indeed a flow like you have? > > If that is the case then could you report back if it indeed doesn't work > for > > you > > (while it is for me). I've tested this out with Tomcat 5.0.28, Windows XP > > and JDK 1.4.2_04. > > > > Here is the testcase: > > > > - add a new global-forward to the struts-config.xml: > > > > > path="/Locale.do?language=ru&page=/Welco
Re: Jetspeed 1.6-Fusion HELP!!!!
My 1.6 Fusion build required me to add the tables from Jetspeed 1 and the tables from Jetspeed 2. I didn't try to remove any tables that might not be needed, but adding all of them works. Also, I have just downloaded the latest source for Jetspeed 2 and 1, compiled and deployed Fusion, and everything is working great. So I would suggest getting the latest source for both, unless someone higher up the chain disagrees. On Thu, 10 Mar 2005 10:07:12 -0600, Archana Turaga <[EMAIL PROTECTED]> wrote: > Hi, > > We really need to know when Jetspeed 1.6 is going to be released. We > need it more so because of its ability to support struts with Fusion and > we are depending on it very heavily for our implementation. > > At the most we need to know what binaries from 2.0 are needed to get > fusion going since Jetspeed 2.0 adds a whole bunch of tables to the > database and we do not know which are needed and which are not. > > Please let us know the release date or at-least give us a list of > binaries/tables that need to get fusion going on top of Jetspeed 1.6. > > I know David said that it will be out Feb end and I also know that you > guys are all very busy but please can you let us know the status? > > Thanks a lot for your co-operation. > Regards, > Archana > > - > 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]
Jetspeed 1.6-Fusion HELP!!!!
Hi, We really need to know when Jetspeed 1.6 is going to be released. We need it more so because of its ability to support struts with Fusion and we are depending on it very heavily for our implementation. At the most we need to know what binaries from 2.0 are needed to get fusion going since Jetspeed 2.0 adds a whole bunch of tables to the database and we do not know which are needed and which are not. Please let us know the release date or at-least give us a list of binaries/tables that need to get fusion going on top of Jetspeed 1.6. I know David said that it will be out Feb end and I also know that you guys are all very busy but please can you let us know the status? Thanks a lot for your co-operation. Regards, Archana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts bridge, lost request parameters
Colin, Your quick fix didn't work for me. Perhaps my flow is wrong. Here is what I am doing. Displaying the View page (/myaction.do). Clicking the edit icon to go to the Edit page (/editmyaction.do). Then after hitting save on the edit page, I have to tell it to go back to the view page by doing this in the action class: actionResponse.setPortletMode(PortletMode.VIEW); It returns to the View page correctly (like it always has). Clicking on the edit button simply refreshes the view page, instead of taking me back to the edit screen. This is the same result as before I applied you fix. Have I done something differently than you? Thanks, -- Jeff On Thu, 10 Mar 2005 11:44:15 -, Colin O'Toole <[EMAIL PROTECTED]> wrote: > Ah! OK I will try this but it will have to wait until tomorrow. because of > time constraints I may stick with what I have and do a wholesale upgrade > once M2 is released. > > Thanks for the help! > > Colin. > > -Original Message- > From: Ate Douma [mailto:[EMAIL PROTECTED] > Sent: 10 March 2005 11:30 > To: Jetspeed Users List > Subject: Re: Struts bridge, lost request parameters > > Colin O'Toole wrote: > > Hi Ate, > > > > OK, I made the changes you detailed and tried this and what happens is: > > > > (1) Clicking on link goes to LocaleAction (ActionUrl). Using remote > > debugging in eclipse with a breakpoint in LocaleAction.execute(), the > > PortletServletRequestWrapper object contains an ApplicationContextFacade > and > > a ServletRequestImpl. The ServletRequestImpl contains an > > ApplicationHttpRequestObject. The queryParamString member of the > > ApplicationHttpRequestObject holds the params > > "language=ja&forward=testredirect". (This is what I saw in my example > also) > > > > (2) In LocaleAction the following code is run: > > > > target = request.getParameter(FORWARD); > > > > This returns null - the parameter "forward=testredirect" is not found in > the > > request. This causes the following code to be executed: > > > > if (isBlank(target)) target = mapping.getParameter(); > > > > return mapping.findForward(target); > > > > "target" is the default welcome global mapping from the struts-config.xml, > > so the WelcomeAction is called. > > > > So in fact for me it appears that request params are being lost > wholesale - > > irrespective of whether or not it is a redirect or a simple forward. I am > > using Tomcat 5.5.4, Windows XP, JDK 1.4.2_05, JetSpeed M1. I will try > later > > today with Tomcat 5.0.28 which I also have. > Now we are getting somewhere: you are running Jetspeed 2 M1... > > I'm not sure but I think that will be the reason. I don't test or develop > against > M1 anymore. As we are approaching a M2 release very soon, I suggest you try > your > application with the latest CVS HEAD if possible. > > > > > If I run the above code with the old version - which expressly parses the > > querystring in StrutsPortlet and passes it into > > PortletServletRequestWrapper, it works as you describe. I'm a bit stumped > > here. :-) > > > > Can you help me understand where the params go in the new > > PortletServletRequestWrapper? In the old PortletServletRequestWrapper I > > could see that in DispatchedHttpServletRequestWrapper they were parsed > into > > a map. I'm unsure as to where they end up now. > > > > Thanks, > > Colin. > > > > > > -Original Message- > > From: Ate Douma [mailto:[EMAIL PROTECTED] > > Sent: 09 March 2005 22:41 > > To: Jetspeed Users List > > Subject: Re: Struts bridge, lost request parameters > > > > > > Colin, > > > > I took some time to create a testcase with a similar flow as you described > > earlier. > > For this, I used the struts-demo as provided with Jetspeed-2. > > Could you please check if this is indeed a flow like you have? > > If that is the case then could you report back if it indeed doesn't work > for > > you > > (while it is for me). I've tested this out with Tomcat 5.0.28, Windows XP > > and JDK 1.4.2_04. > > > > Here is the testcase: > > > > - add a new global-forward to the struts-config.xml: > > > > > path="/Locale.do?language=ru&page=/Welcome.do" redirect="true"/> > > > > - in the welcome.jsp change: > > > > > useLocalEncoding="true">Japanese > >to: > > > useLocalEncoding="true">Japanese > > > > With these changes and selecting the Japanese language on the welcome > > screen, the LocaleAction > > will be invoked (ActionURL) to set the Japanese language and than forward > to > > the new testredirect forward. > > The testredirect forward redirects (as in your case the Filter.do) back to > > the LocaleAction but now for > > setting the Russian language (using query_string parameters) and finally > > forward to the Welcome screen again. > > The end result for the user is that the Locale is set to Russian instead > of > > Japanese :-) > > > > This works without problems for me! > > I also turned on logging and to show it indeed works as expected, here is > a > > trimmed
RE: Struts bridge, lost request parameters
Ah! OK I will try this but it will have to wait until tomorrow. because of time constraints I may stick with what I have and do a wholesale upgrade once M2 is released. Thanks for the help! Colin. -Original Message- From: Ate Douma [mailto:[EMAIL PROTECTED] Sent: 10 March 2005 11:30 To: Jetspeed Users List Subject: Re: Struts bridge, lost request parameters Colin O'Toole wrote: > Hi Ate, > > OK, I made the changes you detailed and tried this and what happens is: > > (1) Clicking on link goes to LocaleAction (ActionUrl). Using remote > debugging in eclipse with a breakpoint in LocaleAction.execute(), the > PortletServletRequestWrapper object contains an ApplicationContextFacade and > a ServletRequestImpl. The ServletRequestImpl contains an > ApplicationHttpRequestObject. The queryParamString member of the > ApplicationHttpRequestObject holds the params > "language=ja&forward=testredirect". (This is what I saw in my example also) > > (2) In LocaleAction the following code is run: > > target = request.getParameter(FORWARD); > > This returns null - the parameter "forward=testredirect" is not found in the > request. This causes the following code to be executed: > > if (isBlank(target)) target = mapping.getParameter(); > > return mapping.findForward(target); > > "target" is the default welcome global mapping from the struts-config.xml, > so the WelcomeAction is called. > > So in fact for me it appears that request params are being lost wholesale - > irrespective of whether or not it is a redirect or a simple forward. I am > using Tomcat 5.5.4, Windows XP, JDK 1.4.2_05, JetSpeed M1. I will try later > today with Tomcat 5.0.28 which I also have. Now we are getting somewhere: you are running Jetspeed 2 M1... I'm not sure but I think that will be the reason. I don't test or develop against M1 anymore. As we are approaching a M2 release very soon, I suggest you try your application with the latest CVS HEAD if possible. > > If I run the above code with the old version - which expressly parses the > querystring in StrutsPortlet and passes it into > PortletServletRequestWrapper, it works as you describe. I'm a bit stumped > here. :-) > > Can you help me understand where the params go in the new > PortletServletRequestWrapper? In the old PortletServletRequestWrapper I > could see that in DispatchedHttpServletRequestWrapper they were parsed into > a map. I'm unsure as to where they end up now. > > Thanks, > Colin. > > > -Original Message- > From: Ate Douma [mailto:[EMAIL PROTECTED] > Sent: 09 March 2005 22:41 > To: Jetspeed Users List > Subject: Re: Struts bridge, lost request parameters > > > Colin, > > I took some time to create a testcase with a similar flow as you described > earlier. > For this, I used the struts-demo as provided with Jetspeed-2. > Could you please check if this is indeed a flow like you have? > If that is the case then could you report back if it indeed doesn't work for > you > (while it is for me). I've tested this out with Tomcat 5.0.28, Windows XP > and JDK 1.4.2_04. > > Here is the testcase: > > - add a new global-forward to the struts-config.xml: > > path="/Locale.do?language=ru&page=/Welcome.do" redirect="true"/> > > - in the welcome.jsp change: > > useLocalEncoding="true">Japanese >to: > useLocalEncoding="true">Japanese > > With these changes and selecting the Japanese language on the welcome > screen, the LocaleAction > will be invoked (ActionURL) to set the Japanese language and than forward to > the new testredirect forward. > The testredirect forward redirects (as in your case the Filter.do) back to > the LocaleAction but now for > setting the Russian language (using query_string parameters) and finally > forward to the Welcome screen again. > The end result for the user is that the Locale is set to Russian instead of > Japanese :-) > > This works without problems for me! > I also turned on logging and to show it indeed works as expected, here is a > trimmed part of the logging: > ... > PropertyMessageResources - loadLocale(nl) > ... > StrutsPortlet - process path: /Locale.do?language=ja&forward=testredirect, > requestType: ACTION > processForwardConfig(ForwardConfig[name=testredirect,path=/Locale.do?languag > e=ru&page=/Welcome.do,redirect=true,... > StrutsPortlet - action render redirected page: > /Locale.do?language=ru&page=/Welcome.do > navstate > decoded=[[window:15,action:true,parameters:[_spage:[/Locale.do?language=ja&f > orward=testredirect]]] > navstate > decoded=[[window:15,mode:view,state:normal,parameters:[_kra:[1],_spage:[/Loc > ale.do?language=ru&page=/Welcome.do]]] > StrutsPortlet - process path: /Locale.do?language=ru&page=/Welcome.do, > requestType: VIEW > processForwardConfig(ForwardConfig[name=null,path=/Welcome.do,redirect=false > ,... > ... > PropertyMessageResources - loadLocale(ru) > > Regards, Ate > > Colin O'Toole wrote: > >>Hi Ate, >> >>I had some time to take a look at this yesterday and the situatio
RE: Struts bridge, lost request parameters
Yep that sounds like a good idea. I'm just wondering: is it possible that
because of some action in an edit page the stored view page Url might no
longer be valid? Can't think of a good example off the top of my head
though :-)
Colin.
-Original Message-
From: Ate Douma [mailto:[EMAIL PROTECTED]
Sent: 09 March 2005 23:19
To: Jetspeed Users List
Subject: Re: Struts bridge, lost request parameters
Colin O'Toole wrote:
> Hi Jeff,
>
> You're welcome. If it causes any problems for you please post them here.
I
> think it's OK but I'm no portlet expert so it could break something! Ate
> will be able to tell us for sure.
Sure ;-)
I think your fix should do the trick indeed. And I don't think it breaks
anything!
I'm not sure I'm going to implement it (only) like this though.
One thing not possible with this solution is "remembering" the PageURL you
leave when
switching to another mode.
If you come back to the (or a) previous mode, you always re-enter with its
defaultPage.
I'm thinking of saving the last PageURL for each mode (if unequal to its
defaultPage) in
a special session scoped object and restoring it when the (or a) previously
used mode
is re-entered.
Probably this should be configurable too (using an init parameter) so your
'light' solution
can also be used.
What do you think?
And Jeff, is this indeed a/the solution for your problem?
Regards, Ate
>
> Colin.
>
>
>>-Original Message-
>>From: Jeff Sheets [mailto:[EMAIL PROTECTED]
>>Sent: 09 March 2005 14:13
>>To: Jetspeed Users List
>>Subject: Re: Struts bridge, lost request parameters
>>
>>
>>Hey Colin,
>>
>>I'll try out your "quick fix" for the edit page bug. We have really
>>needed this fixed, and I was stumped on what was wrong, so thank you
>>very much!
>>
>>-- Jeff
>>
>>On Wed, 9 Mar 2005 10:44:22 -, Colin O'Toole
>><[EMAIL PROTECTED]> wrote:
>>
>>>Hi Ate,
>>>
>>>This is OT, but there is another problem I have fixed locally.
>>
>>This is the
>>
>>>edit page problem reported originally reported by Jeff Sheets.
>>
>>The problem
>>
>>>is that when a submit is performed from an edit page, pressing
>>
>>the button to
>>
>>>change to view mode doesn't work anymore.
>>>
>>>The problem occurs in StrutsPortlet when the defaultPage (from the
>>>portlet.xml) is overridden by the pageURL value from the
>>
>>StrutsPortletURL.
>>
>>>This mechanism doesn't take into account the fact that the
>>
>>portlet mode may
>>
>>>have changed. So what happens is that clicking the icon to go
>>
>>to VIEW mode
>>
>>>issues a doView(), which calls processRequest(), which pulls
>>
>>the _edit_ url
>>
>>>from the StrutsPortletURL and uses it instead of the ViewPage
>>
>>url specified
>>
>>>in portlet.xml.
>>>
>>>I needed a fix for a demo, so what I did was:
>>>
>>>(1) In StrutsPortletURL v1.4. Add a portlet mode.
>>>
>>>public static final String PORTLETMODE = "_mode";
>>>
>>>- Line 61 changes from this:
>>>
>>>if (actionURL)
>>>{
>>>String originURL = request.getParameter(PAGE);
>>>if (originURL != null)
>>>portletURL.setParameter(ORIGIN, originURL);
>>>}
>>>return portletURL;
>>>}
>>>
>>>- To this:
>>>
>>>if (actionURL)
>>>{
>>>String originURL = request.getParameter(PAGE);
>>> if (originURL != null)
>>>portletURL.setParameter(ORIGIN, originURL);
>>>}
>>>
>>>// Add the portlet mode to the request, we will only
>>
>>use the pageURL param
>>
>>>to override the
>>>// default page if the portlet mode for this URL is the
>>
>>same as the current
>>
>>>mode when
>>>// StrutsPortlet.processRequest() is executed
>>>PortletRequest portletRequest =
>>>(PortletRequest)request.getAttribute("javax.portlet.request");
>>>String portletMode = portletRequest.getPortletMode().toString();
>>>log.debug("portletMode is: " + portletMode);
>>>portletURL.setParameter(PORTLETMODE, portletMode);
>>>
>>>return portletURL;
>>>}
>>>
>>>(2) In StrutsPortlet v1.12. If there is a pageURL in the
>>
>>request, only use
>>
>>>it if the mode associated with it is the same as the current
>>
>>portlet mode:
>>
>>>- Line 313 changes from
>>>
>>>String path = null;
>>>String pageURL = request.getParameter(StrutsPortletURL.PAGE);
>>>if (pageURL == null)
>>>path = defaultPage
>>>else
>>>{
>>>path = pageURL;
>>>}
>>>
>>>- To:
>>>
>>>String path = null;
>>>String pageURL = request.getParameter(StrutsPortletURL.PAGE);
>>>String portletModeFromURL =
>>>request.getParameter(StrutsPortletURL.PORTLETMODE);
>>>String portletModeCurrent = request.getPortletMode().toString();
>>>log.debug("portletModeFromURL: " + portletModeFromURL + ",
>>>portletModeCurrent: " + portletModeCurrent);
>>>if (pageURL == null) {
>>>log.debug("pageURL from request is null, using default page: " +
>>>defaultPage);
>>> path = defaultPage;
>>>}
>>>else {
>>>// only use the pageURL
Re: Struts bridge, lost request parameters
Colin O'Toole wrote: Hi Ate, OK, I made the changes you detailed and tried this and what happens is: (1) Clicking on link goes to LocaleAction (ActionUrl). Using remote debugging in eclipse with a breakpoint in LocaleAction.execute(), the PortletServletRequestWrapper object contains an ApplicationContextFacade and a ServletRequestImpl. The ServletRequestImpl contains an ApplicationHttpRequestObject. The queryParamString member of the ApplicationHttpRequestObject holds the params "language=ja&forward=testredirect". (This is what I saw in my example also) (2) In LocaleAction the following code is run: target = request.getParameter(FORWARD); This returns null - the parameter "forward=testredirect" is not found in the request. This causes the following code to be executed: if (isBlank(target)) target = mapping.getParameter(); return mapping.findForward(target); "target" is the default welcome global mapping from the struts-config.xml, so the WelcomeAction is called. So in fact for me it appears that request params are being lost wholesale - irrespective of whether or not it is a redirect or a simple forward. I am using Tomcat 5.5.4, Windows XP, JDK 1.4.2_05, JetSpeed M1. I will try later today with Tomcat 5.0.28 which I also have. Now we are getting somewhere: you are running Jetspeed 2 M1... I'm not sure but I think that will be the reason. I don't test or develop against M1 anymore. As we are approaching a M2 release very soon, I suggest you try your application with the latest CVS HEAD if possible. If I run the above code with the old version - which expressly parses the querystring in StrutsPortlet and passes it into PortletServletRequestWrapper, it works as you describe. I'm a bit stumped here. :-) Can you help me understand where the params go in the new PortletServletRequestWrapper? In the old PortletServletRequestWrapper I could see that in DispatchedHttpServletRequestWrapper they were parsed into a map. I'm unsure as to where they end up now. Thanks, Colin. -Original Message- From: Ate Douma [mailto:[EMAIL PROTECTED] Sent: 09 March 2005 22:41 To: Jetspeed Users List Subject: Re: Struts bridge, lost request parameters Colin, I took some time to create a testcase with a similar flow as you described earlier. For this, I used the struts-demo as provided with Jetspeed-2. Could you please check if this is indeed a flow like you have? If that is the case then could you report back if it indeed doesn't work for you (while it is for me). I've tested this out with Tomcat 5.0.28, Windows XP and JDK 1.4.2_04. Here is the testcase: - add a new global-forward to the struts-config.xml: - in the welcome.jsp change: Japanese to: Japanese With these changes and selecting the Japanese language on the welcome screen, the LocaleAction will be invoked (ActionURL) to set the Japanese language and than forward to the new testredirect forward. The testredirect forward redirects (as in your case the Filter.do) back to the LocaleAction but now for setting the Russian language (using query_string parameters) and finally forward to the Welcome screen again. The end result for the user is that the Locale is set to Russian instead of Japanese :-) This works without problems for me! I also turned on logging and to show it indeed works as expected, here is a trimmed part of the logging: ... PropertyMessageResources - loadLocale(nl) ... StrutsPortlet - process path: /Locale.do?language=ja&forward=testredirect, requestType: ACTION processForwardConfig(ForwardConfig[name=testredirect,path=/Locale.do?languag e=ru&page=/Welcome.do,redirect=true,... StrutsPortlet - action render redirected page: /Locale.do?language=ru&page=/Welcome.do navstate decoded=[[window:15,action:true,parameters:[_spage:[/Locale.do?language=ja&f orward=testredirect]]] navstate decoded=[[window:15,mode:view,state:normal,parameters:[_kra:[1],_spage:[/Loc ale.do?language=ru&page=/Welcome.do]]] StrutsPortlet - process path: /Locale.do?language=ru&page=/Welcome.do, requestType: VIEW processForwardConfig(ForwardConfig[name=null,path=/Welcome.do,redirect=false ,... ... PropertyMessageResources - loadLocale(ru) Regards, Ate Colin O'Toole wrote: Hi Ate, I had some time to take a look at this yesterday and the situation is: PortletServletRequestWrapper now extends HttpServletRequestWrapper rather than DispatchedHttpServletRequestWrapper. The DispatchedHttpServletRequestWrapper constructor accepts the queryString from the path and the parameters were parsed into a map. The params could then be retrieved by calling getParameter(), getParameterNames() etc. HttpServletRequestWrapper doesn't make the original params available in the same way. I modified the code from the head to make PortletServletRequestWrapper extend DispatchedHttpServletRequestWrapper once more (and obviously restore DispatchedHttpServletRequestWrapper to the org.apache.portals.bridges.struts.util package from where it was deleted). My app now works correctly as befo
RE: Struts bridge, lost request parameters
Hi Ate, OK, I made the changes you detailed and tried this and what happens is: (1) Clicking on link goes to LocaleAction (ActionUrl). Using remote debugging in eclipse with a breakpoint in LocaleAction.execute(), the PortletServletRequestWrapper object contains an ApplicationContextFacade and a ServletRequestImpl. The ServletRequestImpl contains an ApplicationHttpRequestObject. The queryParamString member of the ApplicationHttpRequestObject holds the params "language=ja&forward=testredirect". (This is what I saw in my example also) (2) In LocaleAction the following code is run: target = request.getParameter(FORWARD); This returns null - the parameter "forward=testredirect" is not found in the request. This causes the following code to be executed: if (isBlank(target)) target = mapping.getParameter(); return mapping.findForward(target); "target" is the default welcome global mapping from the struts-config.xml, so the WelcomeAction is called. So in fact for me it appears that request params are being lost wholesale - irrespective of whether or not it is a redirect or a simple forward. I am using Tomcat 5.5.4, Windows XP, JDK 1.4.2_05, JetSpeed M1. I will try later today with Tomcat 5.0.28 which I also have. If I run the above code with the old version - which expressly parses the querystring in StrutsPortlet and passes it into PortletServletRequestWrapper, it works as you describe. I'm a bit stumped here. :-) Can you help me understand where the params go in the new PortletServletRequestWrapper? In the old PortletServletRequestWrapper I could see that in DispatchedHttpServletRequestWrapper they were parsed into a map. I'm unsure as to where they end up now. Thanks, Colin. -Original Message- From: Ate Douma [mailto:[EMAIL PROTECTED] Sent: 09 March 2005 22:41 To: Jetspeed Users List Subject: Re: Struts bridge, lost request parameters Colin, I took some time to create a testcase with a similar flow as you described earlier. For this, I used the struts-demo as provided with Jetspeed-2. Could you please check if this is indeed a flow like you have? If that is the case then could you report back if it indeed doesn't work for you (while it is for me). I've tested this out with Tomcat 5.0.28, Windows XP and JDK 1.4.2_04. Here is the testcase: - add a new global-forward to the struts-config.xml: - in the welcome.jsp change: Japanese to: Japanese With these changes and selecting the Japanese language on the welcome screen, the LocaleAction will be invoked (ActionURL) to set the Japanese language and than forward to the new testredirect forward. The testredirect forward redirects (as in your case the Filter.do) back to the LocaleAction but now for setting the Russian language (using query_string parameters) and finally forward to the Welcome screen again. The end result for the user is that the Locale is set to Russian instead of Japanese :-) This works without problems for me! I also turned on logging and to show it indeed works as expected, here is a trimmed part of the logging: ... PropertyMessageResources - loadLocale(nl) ... StrutsPortlet - process path: /Locale.do?language=ja&forward=testredirect, requestType: ACTION processForwardConfig(ForwardConfig[name=testredirect,path=/Locale.do?languag e=ru&page=/Welcome.do,redirect=true,... StrutsPortlet - action render redirected page: /Locale.do?language=ru&page=/Welcome.do navstate decoded=[[window:15,action:true,parameters:[_spage:[/Locale.do?language=ja&f orward=testredirect]]] navstate decoded=[[window:15,mode:view,state:normal,parameters:[_kra:[1],_spage:[/Loc ale.do?language=ru&page=/Welcome.do]]] StrutsPortlet - process path: /Locale.do?language=ru&page=/Welcome.do, requestType: VIEW processForwardConfig(ForwardConfig[name=null,path=/Welcome.do,redirect=false ,... ... PropertyMessageResources - loadLocale(ru) Regards, Ate Colin O'Toole wrote: > Hi Ate, > > I had some time to take a look at this yesterday and the situation is: > > PortletServletRequestWrapper now extends HttpServletRequestWrapper rather > than DispatchedHttpServletRequestWrapper. The > DispatchedHttpServletRequestWrapper constructor accepts the queryString from > the path and the parameters were parsed into a map. The params could then > be retrieved by calling getParameter(), getParameterNames() etc. > HttpServletRequestWrapper doesn't make the original params available in the > same way. > > I modified the code from the head to make PortletServletRequestWrapper > extend DispatchedHttpServletRequestWrapper once more (and obviously restore > DispatchedHttpServletRequestWrapper to the > org.apache.portals.bridges.struts.util package from where it was deleted). > My app now works correctly as before. > > I'm sure DispatchedHttpServletRequestWrapper was removed for a reason, so > this is likely no more than a temporary solution. > > Hope this helps, > > Colin. > > >>Colin, I will try to look at you problem later this evening or >>oth
Jetspeed and SPNEGO
Has anyone tried to automate the Jetspeed login using the SPNEGO protocol? (for example, using the Windows Domain username as a username for Jetspeed) Roel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
