You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by Ate Douma <at...@douma.nu> on 2005/01/20 03:49:32 UTC
[J2] Major new version of the Struts Bridge: version 0.2 now available
I'm happy to bring the news of a major upgrade of the Struts Bridge.
A short summary of its new features:
- Based on the latest Struts-1.2.4
- Provides new struts-1.2.4-portlet-html.tld and struts-1.2.4-portlet-html-el.tld, as
well as a new struts-portlet-el.tld.
The first two tld files are full replacements for the struts-html and struts-html-el tlds.
By using these tlds instead of the struts-portlet and struts-portlet-el tlds, migrating
existing Struts applications becomes much easier (just change the taglib definition).
Furthermore, there is now full struts-el support Bridge for all the tags (including the
new onces).
- New Portlet supporting extended Struts tags ImgTag and ImageTag and largely extended
LinkTag and RewriteTag.
These tags now support relative image src paths and href link
paths (including ../ elements).
- Provides transparent (non-code based) definition of request attribute values to be saved
during ActionRequest handling which will be restored in the subsequent RenderRequest(s).
- Provides transparent (non-code based) definition of url (prefixes) which must be
rendered as Action or Render PortletURL.
This removes the need to specify the renderURL attribute for link and rewrite tags (its
still supported though, and then will override).
- xml based configuration of above two features loaded at Portlet initialization.
Default configuration file name: WEB-INF/struts-portlet-config.xml, but this is
configurable itself as well.
Example configuration (from the new JPetstore demo Portlet):
<?xml version="1.0" encoding="UTF-8"?>
<config>
<render-context>
<attribute name="errors"/>
<attribute name="message"/>
</render-context>
<portlet-url-type default="render">
<action path="/shop/add"/>
<action path="/shop/switch"/>
<action path="/shop/remove"/>
<action path="/shop/signoff"/>
<action path="/shop/viewCategory"/>
<action path="/shop/viewItem"/>
<action path="/shop/viewProduct"/>
<action path="/shop/viewCart"/>
<action path="/shop/newOrder"/>
<render path="/shop/newOrderForm"/>
<action path="/shop/listOrders"/>
</portlet-url-type>
</config>
- IMPORTANT:
Default PorletURL created by link and rewrite tag changed from ActionURL to RenderURL.
This change is made because in the most cases this turned out to be RenderURLs.
For migrating of existing Struts Bridge based Portlets to the new version there is an
very simple configuration option to revert this to the old style:
Define a WEB-INF/struts-portlet-config.xml containing (at least):
<?xml version="1.0" encoding="UTF-8"?>
<config>
<portlet-url-type default="action"/>
</config>
That'll switch the default back to the old style. For the old Struts MailReader Demo Portlet
also provided with Jetspeed-2, I've put in a configuration file just like that.
- New demo portlet application: JPetstore Portlet.
This very know example web application from iBatis (www.ibatis.com) is now also available as
Portlet and is automatically deployed in Jetspeed-2 as demo portlet: check it out.
- Deploy as Portlet or as web application!
The Struts Bridge can now be used in a non-Portlet context, and then will simply fall back to
the basic Struts functionality.
This allows the deployment of the same Portlet Application war as web application and as portlet
application. You can thus also test the application in a web server only (as long as you
don't use Portlet features specifically).
Try out the JPetstore Portlet demo and access it as Portlet from within Jetspeed-2 or
directly from the webserver (e.g. http://localhost:8080/jpetstore).
- Abstracted the access to the ServletContextProvider with protected methods in StrutsPortlet
allowing Portal Vendor specific extensions to be used (like VAP).
- Still no real documentation ;-)
I'm working on it and plan to deliver real usage documentation, as well as a tutorial and instructions
for migrating existing Struts applications, within a week.
Regards, Ate Douma
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: [J2] Major new version of the Struts Bridge: version 0.2 now
available
Posted by "Scott T. Weaver" <sc...@binary-designs.net>.
Awesome!!! Great job, Ate!!!
Ate Douma wrote:
> I'm happy to bring the news of a major upgrade of the Struts Bridge.
>
> A short summary of its new features:
> - Based on the latest Struts-1.2.4
>
> - Provides new struts-1.2.4-portlet-html.tld and
> struts-1.2.4-portlet-html-el.tld, as
> well as a new struts-portlet-el.tld.
> The first two tld files are full replacements for the struts-html
> and struts-html-el tlds.
> By using these tlds instead of the struts-portlet and
> struts-portlet-el tlds, migrating
> existing Struts applications becomes much easier (just change the
> taglib definition).
> Furthermore, there is now full struts-el support Bridge for all the
> tags (including the
> new onces).
>
> - New Portlet supporting extended Struts tags ImgTag and ImageTag and
> largely extended
> LinkTag and RewriteTag.
> These tags now support relative image src paths and href link
> paths (including ../ elements).
>
> - Provides transparent (non-code based) definition of request
> attribute values to be saved
> during ActionRequest handling which will be restored in the
> subsequent RenderRequest(s).
>
> - Provides transparent (non-code based) definition of url (prefixes)
> which must be
> rendered as Action or Render PortletURL.
> This removes the need to specify the renderURL attribute for link
> and rewrite tags (its
> still supported though, and then will override).
>
> - xml based configuration of above two features loaded at Portlet
> initialization.
> Default configuration file name: WEB-INF/struts-portlet-config.xml,
> but this is
> configurable itself as well.
> Example configuration (from the new JPetstore demo Portlet):
> <?xml version="1.0" encoding="UTF-8"?>
> <config>
> <render-context>
> <attribute name="errors"/>
> <attribute name="message"/>
> </render-context>
> <portlet-url-type default="render">
> <action path="/shop/add"/>
> <action path="/shop/switch"/>
> <action path="/shop/remove"/>
> <action path="/shop/signoff"/>
> <action path="/shop/viewCategory"/>
> <action path="/shop/viewItem"/>
> <action path="/shop/viewProduct"/>
> <action path="/shop/viewCart"/>
> <action path="/shop/newOrder"/>
> <render path="/shop/newOrderForm"/>
> <action path="/shop/listOrders"/>
> </portlet-url-type>
> </config>
>
> - IMPORTANT:
> Default PorletURL created by link and rewrite tag changed from
> ActionURL to RenderURL.
>
> This change is made because in the most cases this turned out to be
> RenderURLs.
>
> For migrating of existing Struts Bridge based Portlets to the new
> version there is an
> very simple configuration option to revert this to the old style:
>
> Define a WEB-INF/struts-portlet-config.xml containing (at least):
> <?xml version="1.0" encoding="UTF-8"?>
> <config>
> <portlet-url-type default="action"/>
> </config>
>
> That'll switch the default back to the old style. For the old Struts
> MailReader Demo Portlet
> also provided with Jetspeed-2, I've put in a configuration file just
> like that.
>
> - New demo portlet application: JPetstore Portlet.
> This very know example web application from iBatis (www.ibatis.com)
> is now also available as
> Portlet and is automatically deployed in Jetspeed-2 as demo portlet:
> check it out.
>
> - Deploy as Portlet or as web application!
> The Struts Bridge can now be used in a non-Portlet context, and then
> will simply fall back to
> the basic Struts functionality.
> This allows the deployment of the same Portlet Application war as
> web application and as portlet
> application. You can thus also test the application in a web server
> only (as long as you
> don't use Portlet features specifically).
>
> Try out the JPetstore Portlet demo and access it as Portlet from
> within Jetspeed-2 or
> directly from the webserver (e.g. http://localhost:8080/jpetstore).
>
> - Abstracted the access to the ServletContextProvider with protected
> methods in StrutsPortlet
> allowing Portal Vendor specific extensions to be used (like VAP).
>
> - Still no real documentation ;-)
> I'm working on it and plan to deliver real usage documentation, as
> well as a tutorial and instructions
> for migrating existing Struts applications, within a week.
>
> Regards, Ate Douma
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
>
--
"Great minds discuss ideas. Average minds discuss events. Small minds discuss people." - Admiral Hyman Rickover
*******************************************
* Scott T. Weaver *
* <we...@apache.org> *
* <http://www.einnovation.com> *
* -------------------------------------- *
* Apache Jetspeed Enterprise Portal *
* Apache Pluto Portlet Container *
* *
* OpenEdit, Website Content Management *
* <http://www.openedit.org> *
*******************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Deployment of context.xml in META-INF not done
Posted by Xavier Lawrence <xl...@jahia.com>.
Hello,
I am using a context.xml file in my wars. It is naturally put in the
META-INF directory and pacakged with the war file.
When Jetspeed deploys the war, it does not copy the context.xml file into
the tomcat5/conf/catalina/localhost directory, so the context I specify is
not available to my webApp. If I copy by hand that context.xml file in the
above directory, everything works fine...
Is this a known issus ? I beleive Jetspeed only has to copy the context
file once the deployment has been sucessful. (Note that in my case,
everything goes fine at deployment time, so it looks to me like that the
jetspeed deployer "forgets" to copy the files in the META-INF directory to
the appropriate tomcat folder).
Xavier
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Portlets and filters
Posted by Ate Douma <at...@douma.nu>.
No, 2.4 has a Schema definition.
Use the following:
<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">
and read Servlet 2.4 SRV.6.2.5 Filters and the RequestDispatcher.
Xavier Lawrence wrote:
> So to do that, I need to specify the DTD version 2.4 in the DOCTYPE ???
>
>
>
>>Tomcat 5 still supports Servlet 2.3 and if you don't define your web.xml
>>as requiring 2.4
>>it will behave as a 2.3 container.
>>
>>Xavier Lawrence wrote:
>>
>>>I am using Tomcat 5.0.28
>>>
>>>
>>>
>>>>I guess you are not running under Servlet 2.4?
>>>>Then it won't work.
>>>>Only since Servlet 2.4 will filters work for dispatched requests.
>>>>
>>>>Xavier Lawrence wrote:
>>>>
>>>>
>>>>>Hello,
>>>>>
>>>>>I have a working struts application that I am trying to change to a
>>>>>portlet. I was asking myself how were filters managed in the portlet
>>>>>world. I seem to have a slight problem with those, they seem to be not
>>>>>considered by the portlet.
>>>>>
>>>>>That is, the non-portlet webApp works fine, but the portlet struts app
>>>>>encounters problems because some filter methods don't seem to be
>>>>>called...
>>>>>
>>>>>Any help is appreciated on the subject. Below is a piece of my web.xml
>>>>>file
>>>>>
>>>>>
>>>>><filter>
>>>>> <filter-name>XSLT Filter</filter-name>
>>>>> <filter-class>edu.rpi.sss.util.servlets.ConfiguredXSLTFilter</filter-class>
>>>>> <init-param>
>>>>> <param-name>debug</param-name>
>>>>> <param-value>0</param-value>
>>>>> </init-param>
>>>>> <init-param>
>>>>> <param-name>directoryBrowsingDisallowed</param-name>
>>>>> <param-value>no</param-value>
>>>>> </init-param>
>>>>> </filter>
>>>>>
>>>>> <filter>
>>>>> <filter-name>SvcI Filter</filter-name>
>>>>> <filter-class>edu.rpi.cct.uwcal.webcommon.UWCalSvciFilter</filter-class>
>>>>> <init-param>
>>>>> <param-name>debug</param-name>
>>>>> <param-value>0</param-value>
>>>>> </init-param>
>>>>> </filter>
>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: Portlets and filters
Posted by Xavier Lawrence <xl...@jahia.com>.
So to do that, I need to specify the DTD version 2.4 in the DOCTYPE ???
> Tomcat 5 still supports Servlet 2.3 and if you don't define your web.xml
> as requiring 2.4
> it will behave as a 2.3 container.
>
> Xavier Lawrence wrote:
>> I am using Tomcat 5.0.28
>>
>>
>>>I guess you are not running under Servlet 2.4?
>>>Then it won't work.
>>>Only since Servlet 2.4 will filters work for dispatched requests.
>>>
>>>Xavier Lawrence wrote:
>>>
>>>>Hello,
>>>>
>>>>I have a working struts application that I am trying to change to a
>>>>portlet. I was asking myself how were filters managed in the portlet
>>>>world. I seem to have a slight problem with those, they seem to be not
>>>>considered by the portlet.
>>>>
>>>>That is, the non-portlet webApp works fine, but the portlet struts app
>>>>encounters problems because some filter methods don't seem to be
>>>>called...
>>>>
>>>>Any help is appreciated on the subject. Below is a piece of my web.xml
>>>>file
>>>>
>>>>
>>>><filter>
>>>> <filter-name>XSLT Filter</filter-name>
>>>> <filter-class>edu.rpi.sss.util.servlets.ConfiguredXSLTFilter</filter-class>
>>>> <init-param>
>>>> <param-name>debug</param-name>
>>>> <param-value>0</param-value>
>>>> </init-param>
>>>> <init-param>
>>>> <param-name>directoryBrowsingDisallowed</param-name>
>>>> <param-value>no</param-value>
>>>> </init-param>
>>>> </filter>
>>>>
>>>> <filter>
>>>> <filter-name>SvcI Filter</filter-name>
>>>> <filter-class>edu.rpi.cct.uwcal.webcommon.UWCalSvciFilter</filter-class>
>>>> <init-param>
>>>> <param-name>debug</param-name>
>>>> <param-value>0</param-value>
>>>> </init-param>
>>>> </filter>
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>>
>>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>
>
--
-------------=[ xlawrence at jahia dot com ]=-------------
Jahia : A collaborative source CMS and Portal Server
www.jahia.org Community and product web site
www.jahia.com Commercial services company
www.collaborativesource.org Jahia's collaborative license
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: Portlets and filters
Posted by Ate Douma <at...@douma.nu>.
Tomcat 5 still supports Servlet 2.3 and if you don't define your web.xml as requiring 2.4
it will behave as a 2.3 container.
Xavier Lawrence wrote:
> I am using Tomcat 5.0.28
>
>
>>I guess you are not running under Servlet 2.4?
>>Then it won't work.
>>Only since Servlet 2.4 will filters work for dispatched requests.
>>
>>Xavier Lawrence wrote:
>>
>>>Hello,
>>>
>>>I have a working struts application that I am trying to change to a
>>>portlet. I was asking myself how were filters managed in the portlet
>>>world. I seem to have a slight problem with those, they seem to be not
>>>considered by the portlet.
>>>
>>>That is, the non-portlet webApp works fine, but the portlet struts app
>>>encounters problems because some filter methods don't seem to be
>>>called...
>>>
>>>Any help is appreciated on the subject. Below is a piece of my web.xml
>>>file
>>>
>>>
>>><filter>
>>> <filter-name>XSLT Filter</filter-name>
>>> <filter-class>edu.rpi.sss.util.servlets.ConfiguredXSLTFilter</filter-class>
>>> <init-param>
>>> <param-name>debug</param-name>
>>> <param-value>0</param-value>
>>> </init-param>
>>> <init-param>
>>> <param-name>directoryBrowsingDisallowed</param-name>
>>> <param-value>no</param-value>
>>> </init-param>
>>> </filter>
>>>
>>> <filter>
>>> <filter-name>SvcI Filter</filter-name>
>>> <filter-class>edu.rpi.cct.uwcal.webcommon.UWCalSvciFilter</filter-class>
>>> <init-param>
>>> <param-name>debug</param-name>
>>> <param-value>0</param-value>
>>> </init-param>
>>> </filter>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: Portlets and filters
Posted by Xavier Lawrence <xl...@jahia.com>.
I am using Tomcat 5.0.28
> I guess you are not running under Servlet 2.4?
> Then it won't work.
> Only since Servlet 2.4 will filters work for dispatched requests.
>
> Xavier Lawrence wrote:
>> Hello,
>>
>> I have a working struts application that I am trying to change to a
>> portlet. I was asking myself how were filters managed in the portlet
>> world. I seem to have a slight problem with those, they seem to be not
>> considered by the portlet.
>>
>> That is, the non-portlet webApp works fine, but the portlet struts app
>> encounters problems because some filter methods don't seem to be
>> called...
>>
>> Any help is appreciated on the subject. Below is a piece of my web.xml
>> file
>>
>>
>> <filter>
>> <filter-name>XSLT Filter</filter-name>
>> <filter-class>edu.rpi.sss.util.servlets.ConfiguredXSLTFilter</filter-class>
>> <init-param>
>> <param-name>debug</param-name>
>> <param-value>0</param-value>
>> </init-param>
>> <init-param>
>> <param-name>directoryBrowsingDisallowed</param-name>
>> <param-value>no</param-value>
>> </init-param>
>> </filter>
>>
>> <filter>
>> <filter-name>SvcI Filter</filter-name>
>> <filter-class>edu.rpi.cct.uwcal.webcommon.UWCalSvciFilter</filter-class>
>> <init-param>
>> <param-name>debug</param-name>
>> <param-value>0</param-value>
>> </init-param>
>> </filter>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>
>
--
-------------=[ xlawrence at jahia dot com ]=-------------
Jahia : A collaborative source CMS and Portal Server
www.jahia.org Community and product web site
www.jahia.com Commercial services company
www.collaborativesource.org Jahia's collaborative license
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: Portlets and filters
Posted by Ate Douma <at...@douma.nu>.
I guess you are not running under Servlet 2.4?
Then it won't work.
Only since Servlet 2.4 will filters work for dispatched requests.
Xavier Lawrence wrote:
> Hello,
>
> I have a working struts application that I am trying to change to a
> portlet. I was asking myself how were filters managed in the portlet
> world. I seem to have a slight problem with those, they seem to be not
> considered by the portlet.
>
> That is, the non-portlet webApp works fine, but the portlet struts app
> encounters problems because some filter methods don't seem to be called...
>
> Any help is appreciated on the subject. Below is a piece of my web.xml file
>
>
> <filter>
> <filter-name>XSLT Filter</filter-name>
> <filter-class>edu.rpi.sss.util.servlets.ConfiguredXSLTFilter</filter-class>
> <init-param>
> <param-name>debug</param-name>
> <param-value>0</param-value>
> </init-param>
> <init-param>
> <param-name>directoryBrowsingDisallowed</param-name>
> <param-value>no</param-value>
> </init-param>
> </filter>
>
> <filter>
> <filter-name>SvcI Filter</filter-name>
> <filter-class>edu.rpi.cct.uwcal.webcommon.UWCalSvciFilter</filter-class>
> <init-param>
> <param-name>debug</param-name>
> <param-value>0</param-value>
> </init-param>
> </filter>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
RE: Portlets and filters
Posted by Colin O'Toole <co...@pacemetrics.com>.
I believe you need to be running a servlet2.4 - compatible container and
include the <dispatcher> tags inside your <filter-mapping> element.
See the thread below for details:
http://www.mail-archive.com/jetspeed-user@jakarta.apache.org/msg14477.html
-----Original Message-----
From: Xavier Lawrence [mailto:xlawrence@jahia.com]
Sent: 21 January 2005 15:13
To: Jetspeed Users List
Cc: Jetspeed Developers List
Subject: Portlets and filters
Hello,
I have a working struts application that I am trying to change to a
portlet. I was asking myself how were filters managed in the portlet
world. I seem to have a slight problem with those, they seem to be not
considered by the portlet.
That is, the non-portlet webApp works fine, but the portlet struts app
encounters problems because some filter methods don't seem to be called...
Any help is appreciated on the subject. Below is a piece of my web.xml file
<filter>
<filter-name>XSLT Filter</filter-name>
<filter-class>edu.rpi.sss.util.servlets.ConfiguredXSLTFilter</filter-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>directoryBrowsingDisallowed</param-name>
<param-value>no</param-value>
</init-param>
</filter>
<filter>
<filter-name>SvcI Filter</filter-name>
<filter-class>edu.rpi.cct.uwcal.webcommon.UWCalSvciFilter</filter-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
</filter>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Portlets and filters
Posted by Xavier Lawrence <xl...@jahia.com>.
Hello,
I have a working struts application that I am trying to change to a
portlet. I was asking myself how were filters managed in the portlet
world. I seem to have a slight problem with those, they seem to be not
considered by the portlet.
That is, the non-portlet webApp works fine, but the portlet struts app
encounters problems because some filter methods don't seem to be called...
Any help is appreciated on the subject. Below is a piece of my web.xml file
<filter>
<filter-name>XSLT Filter</filter-name>
<filter-class>edu.rpi.sss.util.servlets.ConfiguredXSLTFilter</filter-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>directoryBrowsingDisallowed</param-name>
<param-value>no</param-value>
</init-param>
</filter>
<filter>
<filter-name>SvcI Filter</filter-name>
<filter-class>edu.rpi.cct.uwcal.webcommon.UWCalSvciFilter</filter-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
</filter>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: J2: Tiles support in Struts Bridge
Posted by Scott Heaberlin <he...@gmail.com>.
Actually, I can probably vouch for at least that much from my own experiences -
TilesPlugin explicitly checks the configured RequestProcessor to see
if it isAssignableFrom(TilesRequestProcessor.class) - otherwise during
initialization it logs an error message proclaiming incompatibility.
My previous e-mail was backwards; I have extended
TilestRequestProcessor and wrapped a PortletRequestProcessor instance.
In any event, I can't even get to where my request processor is ever
invoked due to the absence of the pluto PortalDefinition thread local
variable defined in JetspeedPortletFactoryProxy.
-Scott Heaberlin
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: J2: Tiles support in Struts Bridge
Posted by Ate Douma <at...@douma.nu>.
Scott Heaberlin wrote:
> See comments inline.
>
>
>>A TilesPortletRequestProcessor is planned!
>
>
> Excellent news!
>
>
>>I got a report from one user who created a new TilesPortletRequestProcessor
>>by extending the TilesRequestProcessor and merged in the PortletRequestProcessor
>>behavior. This, to his report, seems to be working flawlessly!
>
>
> Could you perhaps be a little more specific? I have tried an OO
> approach as well as in desperation cloning the process() and
> processRoles() methods in a TilesRequestProcessor subclass.
I haven't seen the code yet so I'm only passing on what I've been told, but
as far I know they modified the PortletRequestProcessor to extend TilesRequestProcessor
instead of wrapping one.
Colin: could you confirm this?
>
>
>>Note: this is a different solution to the one you describe below.
>
>
> Again, perhaps I am not following you when you say "merged in the
> PortletRequestProcessor behavior" - I feel like I have done this too
> from what I can tell. In fact, to be honest, I don't even think my
> request processor is even being invoked (it doesn't appear in the
> stack trace - see original thread)
>
> I attached a debugger and stepped through one request. My assumptions
> were confirmed - the request never makes it to any code I have
> authored. In fact, it dies within 5 lines of actually invoking the
> portlet itself (I am using StrutsPortlet).
>
> In an effort to learn and perhaps to contribute what I find, (not to
> mention to conquer this beast with whom I've been wrestling - I'm sure
> you can relate) I want to at least continue to try to get this to
> work. That in mind, I have one outstanding question based on the
> stack trace I originally posted (I will repost at the end of this
> message) combined with what I saw stepping through one request with
> the debugger.
>
> Somewhere between where ServletPortletInvoker::invoke() runs and
> JetspeedContainerServlet::doGet(), the ThreadLocal data within the
> JetspeedPortletFactoryProxy class seems to disappear. I have verified
> that within ServletPortletInvoker,
> JetspeedPortletFactoryProxy::setCurrentPortletDefinition(PortletDefinition)
> is indeed called with a non-null PortletDefinition.
>
> The next 7 calls in the stack are from javax.servlet, for which I do
> not have the source. By the time we reach
> JetspeedContainerServlet::doGet() -
> JetspeedPortletFactoryProxy::getCurrentPortletDefinition() returns
> null. 2 lines of code later, the container servlet attempts to get
> the name of the pluto PortletDefinition which is presumed to exist as
> a ThreadLocal variable - resulting in my NPE.
>
> Note, I am indeed using the latest cvs head, not an M build.
>
> I appreciate any insight you may have into this. If I can get this
> working, I'd be happy to contribute documentation and/or patches
> related to Tiles-in-J2 effort!
>
> Thanks in advance,
>
>
> -Scott
>
>
> Scott Heaberlin
>
> 2005-01-21 01:13:38
> StandardContext[/tilestest]JetspeedContainerServlet: Error rendering
> JetspeedContainerServlet error page: java.lang.NullPointerException
> java.lang.NullPointerException
> at org.apache.jetspeed.container.JetspeedContainerServlet.doGet(JetspeedContainerServlet.java:217)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
> at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:704)
> at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
> at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:510)
> at org.apache.jetspeed.container.invoker.ServletPortletInvoker.invoke(ServletPortletInvoker.java:213)
> at org.apache.jetspeed.container.invoker.ServletPortletInvoker.render(ServletPortletInvoker.java:124)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: J2: Tiles support in Struts Bridge
Posted by Scott Heaberlin <he...@gmail.com>.
See comments inline.
> A TilesPortletRequestProcessor is planned!
Excellent news!
> I got a report from one user who created a new TilesPortletRequestProcessor
> by extending the TilesRequestProcessor and merged in the PortletRequestProcessor
> behavior. This, to his report, seems to be working flawlessly!
Could you perhaps be a little more specific? I have tried an OO
approach as well as in desperation cloning the process() and
processRoles() methods in a TilesRequestProcessor subclass.
> Note: this is a different solution to the one you describe below.
Again, perhaps I am not following you when you say "merged in the
PortletRequestProcessor behavior" - I feel like I have done this too
from what I can tell. In fact, to be honest, I don't even think my
request processor is even being invoked (it doesn't appear in the
stack trace - see original thread)
I attached a debugger and stepped through one request. My assumptions
were confirmed - the request never makes it to any code I have
authored. In fact, it dies within 5 lines of actually invoking the
portlet itself (I am using StrutsPortlet).
In an effort to learn and perhaps to contribute what I find, (not to
mention to conquer this beast with whom I've been wrestling - I'm sure
you can relate) I want to at least continue to try to get this to
work. That in mind, I have one outstanding question based on the
stack trace I originally posted (I will repost at the end of this
message) combined with what I saw stepping through one request with
the debugger.
Somewhere between where ServletPortletInvoker::invoke() runs and
JetspeedContainerServlet::doGet(), the ThreadLocal data within the
JetspeedPortletFactoryProxy class seems to disappear. I have verified
that within ServletPortletInvoker,
JetspeedPortletFactoryProxy::setCurrentPortletDefinition(PortletDefinition)
is indeed called with a non-null PortletDefinition.
The next 7 calls in the stack are from javax.servlet, for which I do
not have the source. By the time we reach
JetspeedContainerServlet::doGet() -
JetspeedPortletFactoryProxy::getCurrentPortletDefinition() returns
null. 2 lines of code later, the container servlet attempts to get
the name of the pluto PortletDefinition which is presumed to exist as
a ThreadLocal variable - resulting in my NPE.
Note, I am indeed using the latest cvs head, not an M build.
I appreciate any insight you may have into this. If I can get this
working, I'd be happy to contribute documentation and/or patches
related to Tiles-in-J2 effort!
Thanks in advance,
-Scott
Scott Heaberlin
2005-01-21 01:13:38
StandardContext[/tilestest]JetspeedContainerServlet: Error rendering
JetspeedContainerServlet error page: java.lang.NullPointerException
java.lang.NullPointerException
at org.apache.jetspeed.container.JetspeedContainerServlet.doGet(JetspeedContainerServlet.java:217)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:704)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:510)
at org.apache.jetspeed.container.invoker.ServletPortletInvoker.invoke(ServletPortletInvoker.java:213)
at org.apache.jetspeed.container.invoker.ServletPortletInvoker.render(ServletPortletInvoker.java:124)
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: J2: Tiles support in Struts Bridge
Posted by Ate Douma <at...@douma.nu>.
Sorry about this delayed response (I intended to reply to your earlier request
but forgot).
A TilesPortletRequestProcessor is planned!
I got a report from one user who created a new TilesPortletRequestProcessor
by extending the TilesRequestProcessor and merged in the PortletRequestProcessor
behavior. This, to his report, seems to be working flawlessly!
Note: this is a different solution to the one you describe below.
I intend to supply a TilesPortletRequestProcessor with the Struts Bridge once I
have found the time and an example Tiles Struts application I can test this out
with. I don't use Tiles myself, so it'll take some time for me to validate the
solution (which is a requirement before I commit it).
If anyone could supply me with a good test application which uses Tiles extensively
and is/should be behaving correctly within a Portlet (JSR-168) environment I would
appreciate it. It will certainly speed things up as I don't have time to look for
one myself right now.
Regards, Ate
Scott Heaberlin wrote:
> Resending this question with much more info:
>
> Any support yet for a TilesPortletRequestProcessor? Is there any
> reason why PortletRequestProcessor couldn't extend
> TilesRequestProcessor instead of the base Struts RequestProcessor? I
> ran into difficulties using the first Struts Bridge version with Tiles
> based apps because Tiles apps use TilesRequestProcessor instead of the
> default. Using the old PortletRequestProcessor in struts-config.xml
> for Tiles apps yielded exceptions.
>
> I attempted to write a derivative of TilesRequestProcessor similar to
> PortletRequestProcessor but I must have missed something and couldn't
> get it to work. What I tried was to extend the bridge's
> PortletRequestProcessor, adding a private TilesRequestProcessor
> instance and overriding in my PortletTilesRequestProcessor class the
> methods that org.apache.struts.tiles.TilesRequestProcessor overrides.
> My goal was to essentially perform the same operations as
> PortletRequetProcessor but also allow the processor to check URIs for
> requested tile defs.
>
>>>From the TilesRequestProcessor javadocs:
> <quote>
> catching is done by overloading the following methods:
> * processForwardConfig
> * internalModuleRelativeForward
> * internalModuleRelativeInclude
> </quote>
>
> So, I did the same thing in my extention of PortletRequestProcessor,
> and simply delegated the above overridden methods to my private
> TilesRequestProcessor instance.
>
> Unfortunately, no matter what I tried, I always had
> NullPointerExceptions thrown from JetspeedContainerServlet. From
> what I can tell, something just isn't right (I believe somehow some
> expected javax.portlet attribute(s) are missing in the request object
> passed to the container servlet... but as I'm neither a J2 internals
> expert nor a Struts/Tiles expert, I'm not quite sure how this
> happened.
>
> Any thoughts? Below is the top lines from the stack trace in my
> tomcat log. Note I only accessed the context from a .psml page within
> J2 (the tilestest.war was deployed within J2).
>
> Thanks in advance,
>
> -Scott Heaberlin
>
> log snippet:
>
> 2005-01-21 01:13:38
> StandardContext[/tilestest]JetspeedContainerServlet: Error rendering
> JetspeedContainerServlet error page: java.lang.NullPointerException
> java.lang.NullPointerException
> at org.apache.jetspeed.container.JetspeedContainerServlet.doGet(JetspeedContainerServlet.java:217)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
> at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:704)
> at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
> at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:510)
> at org.apache.jetspeed.container.invoker.ServletPortletInvoker.invoke(ServletPortletInvoker.java:213)
> at org.apache.jetspeed.container.invoker.ServletPortletInvoker.render(ServletPortletInvoker.java:124)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
J2: Tiles support in Struts Bridge
Posted by Scott Heaberlin <he...@gmail.com>.
Resending this question with much more info:
Any support yet for a TilesPortletRequestProcessor? Is there any
reason why PortletRequestProcessor couldn't extend
TilesRequestProcessor instead of the base Struts RequestProcessor? I
ran into difficulties using the first Struts Bridge version with Tiles
based apps because Tiles apps use TilesRequestProcessor instead of the
default. Using the old PortletRequestProcessor in struts-config.xml
for Tiles apps yielded exceptions.
I attempted to write a derivative of TilesRequestProcessor similar to
PortletRequestProcessor but I must have missed something and couldn't
get it to work. What I tried was to extend the bridge's
PortletRequestProcessor, adding a private TilesRequestProcessor
instance and overriding in my PortletTilesRequestProcessor class the
methods that org.apache.struts.tiles.TilesRequestProcessor overrides.
My goal was to essentially perform the same operations as
PortletRequetProcessor but also allow the processor to check URIs for
requested tile defs.
>From the TilesRequestProcessor javadocs:
<quote>
catching is done by overloading the following methods:
* processForwardConfig
* internalModuleRelativeForward
* internalModuleRelativeInclude
</quote>
So, I did the same thing in my extention of PortletRequestProcessor,
and simply delegated the above overridden methods to my private
TilesRequestProcessor instance.
Unfortunately, no matter what I tried, I always had
NullPointerExceptions thrown from JetspeedContainerServlet. From
what I can tell, something just isn't right (I believe somehow some
expected javax.portlet attribute(s) are missing in the request object
passed to the container servlet... but as I'm neither a J2 internals
expert nor a Struts/Tiles expert, I'm not quite sure how this
happened.
Any thoughts? Below is the top lines from the stack trace in my
tomcat log. Note I only accessed the context from a .psml page within
J2 (the tilestest.war was deployed within J2).
Thanks in advance,
-Scott Heaberlin
log snippet:
2005-01-21 01:13:38
StandardContext[/tilestest]JetspeedContainerServlet: Error rendering
JetspeedContainerServlet error page: java.lang.NullPointerException
java.lang.NullPointerException
at org.apache.jetspeed.container.JetspeedContainerServlet.doGet(JetspeedContainerServlet.java:217)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:704)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:510)
at org.apache.jetspeed.container.invoker.ServletPortletInvoker.invoke(ServletPortletInvoker.java:213)
at org.apache.jetspeed.container.invoker.ServletPortletInvoker.render(ServletPortletInvoker.java:124)
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Major new version of the Struts Bridge: version 0.2 now available
Posted by Scott Heaberlin <he...@gmail.com>.
Quick question -
Any support yet for a TilesPortletRequestProcessor? Is there any
reason why PortletRequestProcessor couldn't extend
TilesRequestProcessor instead of the base Struts RequestProcessor? I
ran into difficulties using the first Struts Bridge version with Tiles
based apps because Tiles apps use TilesRequestProcessor instead of the
default. Using the old PortletRequestProcessor in struts-config.xml
for Tiles apps yielded exceptions.
I attempted to write a derivative of TilesRequestProcessor similar to
PortletRequestProcessor but I must have missed something and couldn't
get it to work.
-Scott Heaberlin
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Major new version of the Struts Bridge: version 0.2 now
available
Posted by Ate Douma <at...@douma.nu>.
Raphaël Luta said:
> Ate Douma wrote:
>
>> I'm happy to bring the news of a major upgrade of the Struts Bridge.
>>
> Have you notified the struts and pluto communities as well ?
No, not yet. I want to have the documentation in order before I'll do that.
Hopefully I'll have enough time the next few days to complete it.
>
> --
> Raphaël Luta - raphael.luta@aptiwan.com
> Aptiwan, l'intelligence des réseaux - http://www.aptiwan.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Major new version of the Struts Bridge: version 0.2 now
available
Posted by Raphaël Luta <ra...@aptiwan.com>.
Ate Douma wrote:
> I'm happy to bring the news of a major upgrade of the Struts Bridge.
>
Have you notified the struts and pluto communities as well ?
--
Raphaël Luta - raphael.luta@aptiwan.com
Aptiwan, l'intelligence des réseaux - http://www.aptiwan.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Portlets and filters
Posted by Xavier Lawrence <xl...@jahia.com>.
Hello,
I have a working struts application that I am trying to change to a
portlet. I was asking myself how were filters managed in the portlet
world. I seem to have a slight problem with those, they seem to be not
considered by the portlet.
That is, the non-portlet webApp works fine, but the portlet struts app
encounters problems because some filter methods don't seem to be called...
Any help is appreciated on the subject. Below is a piece of my web.xml file
<filter>
<filter-name>XSLT Filter</filter-name>
<filter-class>edu.rpi.sss.util.servlets.ConfiguredXSLTFilter</filter-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>directoryBrowsingDisallowed</param-name>
<param-value>no</param-value>
</init-param>
</filter>
<filter>
<filter-name>SvcI Filter</filter-name>
<filter-class>edu.rpi.cct.uwcal.webcommon.UWCalSvciFilter</filter-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
</filter>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Major new version of the Struts Bridge: version 0.2 now
available
Posted by Ate Douma <at...@douma.nu>.
Jeff, if this problem still exists in the new Bridge could you create a
JIRA issue for this problem? I'll pick it up then from there.
Ate
Jeff Sheets wrote:
> Thanks for the quick reply.
>
> Our problem is with the EditPage when using Fusion. The problem might
> be unique to fusion, but I've been assuming it is due to a bug in the
> struts bridge. The old struts-demo didn't use an EditPage, so maybe
> you never saw the issue.
>
> When you have an EditPage, you can get to it from the first screen in
> your app from the pencil icon. After saving from the EditPage and
> telling the PortletRequest to return to the View Mode, you are
> returned to the correct page. But now every refresh of the page takes
> you to the EditPage instead of the ViewPage. Also, if you navigate
> between pages in the View Mode then the pencil icon no longer takes
> you to the ViewPage.
>
> Also, I updated from cvs yesterday and the bug still seems to exist
> using Jetspeed1 from HEAD and Jetspeed2 tagged M1.
>
> Good work, and we really like the bridge so far. We've gotten around
> our issue by leaving all portlets in the View Mode at all times, but
> I'd really like to use the Edit Mode.
>
> On Thu, 20 Jan 2005 04:40:56 +0100, Ate Douma <at...@douma.nu> wrote:
>
>>
>>Jeff Sheets wrote:
>>
>>>Wow, this is great Ate! These are many of the features that I was
>>>hoping for! I will try this out first thing tomorrow morning. Do you
>>>know if it handles the EditPage better than the last version? I'm
>>>hoping it fixes a problem that I was having.
>>
>>Actually, I don't know to which problem you are referring.
>>I don't think I "fixed" anything in that area, but if you can give me more
>>details, I'll be more than happy to so.
>>
>>Ate
>>
>>
>>>Thanks again!
>>>-- Jeff Sheets
>>>
>>>
>>>On Thu, 20 Jan 2005 03:49:32 +0100, Ate Douma <at...@douma.nu> wrote:
>>>
>>>
>>>>I'm happy to bring the news of a major upgrade of the Struts Bridge.
>>>>
>>>>A short summary of its new features:
>>>>- Based on the latest Struts-1.2.4
>>>>
>>>>- Provides new struts-1.2.4-portlet-html.tld and struts-1.2.4-portlet-html-el.tld, as
>>>> well as a new struts-portlet-el.tld.
>>>> The first two tld files are full replacements for the struts-html and struts-html-el tlds.
>>>> By using these tlds instead of the struts-portlet and struts-portlet-el tlds, migrating
>>>> existing Struts applications becomes much easier (just change the taglib definition).
>>>> Furthermore, there is now full struts-el support Bridge for all the tags (including the
>>>> new onces).
>>>>
>>>>- New Portlet supporting extended Struts tags ImgTag and ImageTag and largely extended
>>>> LinkTag and RewriteTag.
>>>> These tags now support relative image src paths and href link
>>>> paths (including ../ elements).
>>>>
>>>>- Provides transparent (non-code based) definition of request attribute values to be saved
>>>> during ActionRequest handling which will be restored in the subsequent RenderRequest(s).
>>>>
>>>>- Provides transparent (non-code based) definition of url (prefixes) which must be
>>>> rendered as Action or Render PortletURL.
>>>> This removes the need to specify the renderURL attribute for link and rewrite tags (its
>>>> still supported though, and then will override).
>>>>
>>>>- xml based configuration of above two features loaded at Portlet initialization.
>>>> Default configuration file name: WEB-INF/struts-portlet-config.xml, but this is
>>>> configurable itself as well.
>>>> Example configuration (from the new JPetstore demo Portlet):
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <config>
>>>> <render-context>
>>>> <attribute name="errors"/>
>>>> <attribute name="message"/>
>>>> </render-context>
>>>> <portlet-url-type default="render">
>>>> <action path="/shop/add"/>
>>>> <action path="/shop/switch"/>
>>>> <action path="/shop/remove"/>
>>>> <action path="/shop/signoff"/>
>>>> <action path="/shop/viewCategory"/>
>>>> <action path="/shop/viewItem"/>
>>>> <action path="/shop/viewProduct"/>
>>>> <action path="/shop/viewCart"/>
>>>> <action path="/shop/newOrder"/>
>>>> <render path="/shop/newOrderForm"/>
>>>> <action path="/shop/listOrders"/>
>>>> </portlet-url-type>
>>>> </config>
>>>>
>>>>- IMPORTANT:
>>>> Default PorletURL created by link and rewrite tag changed from ActionURL to RenderURL.
>>>>
>>>> This change is made because in the most cases this turned out to be RenderURLs.
>>>>
>>>> For migrating of existing Struts Bridge based Portlets to the new version there is an
>>>> very simple configuration option to revert this to the old style:
>>>>
>>>> Define a WEB-INF/struts-portlet-config.xml containing (at least):
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <config>
>>>> <portlet-url-type default="action"/>
>>>> </config>
>>>>
>>>> That'll switch the default back to the old style. For the old Struts MailReader Demo Portlet
>>>> also provided with Jetspeed-2, I've put in a configuration file just like that.
>>>>
>>>>- New demo portlet application: JPetstore Portlet.
>>>> This very know example web application from iBatis (www.ibatis.com) is now also available as
>>>> Portlet and is automatically deployed in Jetspeed-2 as demo portlet: check it out.
>>>>
>>>>- Deploy as Portlet or as web application!
>>>> The Struts Bridge can now be used in a non-Portlet context, and then will simply fall back to
>>>> the basic Struts functionality.
>>>> This allows the deployment of the same Portlet Application war as web application and as portlet
>>>> application. You can thus also test the application in a web server only (as long as you
>>>> don't use Portlet features specifically).
>>>>
>>>> Try out the JPetstore Portlet demo and access it as Portlet from within Jetspeed-2 or
>>>> directly from the webserver (e.g. http://localhost:8080/jpetstore).
>>>>
>>>>- Abstracted the access to the ServletContextProvider with protected methods in StrutsPortlet
>>>> allowing Portal Vendor specific extensions to be used (like VAP).
>>>>
>>>>- Still no real documentation ;-)
>>>> I'm working on it and plan to deliver real usage documentation, as well as a tutorial and instructions
>>>> for migrating existing Struts applications, within a week.
>>>>
>>>>Regards, Ate Douma
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: [J2] Major new version of the Struts Bridge: version 0.2 now available
Posted by Jeff Sheets <je...@gmail.com>.
Thanks for the quick reply.
Our problem is with the EditPage when using Fusion. The problem might
be unique to fusion, but I've been assuming it is due to a bug in the
struts bridge. The old struts-demo didn't use an EditPage, so maybe
you never saw the issue.
When you have an EditPage, you can get to it from the first screen in
your app from the pencil icon. After saving from the EditPage and
telling the PortletRequest to return to the View Mode, you are
returned to the correct page. But now every refresh of the page takes
you to the EditPage instead of the ViewPage. Also, if you navigate
between pages in the View Mode then the pencil icon no longer takes
you to the ViewPage.
Also, I updated from cvs yesterday and the bug still seems to exist
using Jetspeed1 from HEAD and Jetspeed2 tagged M1.
Good work, and we really like the bridge so far. We've gotten around
our issue by leaving all portlets in the View Mode at all times, but
I'd really like to use the Edit Mode.
On Thu, 20 Jan 2005 04:40:56 +0100, Ate Douma <at...@douma.nu> wrote:
>
>
> Jeff Sheets wrote:
> > Wow, this is great Ate! These are many of the features that I was
> > hoping for! I will try this out first thing tomorrow morning. Do you
> > know if it handles the EditPage better than the last version? I'm
> > hoping it fixes a problem that I was having.
> Actually, I don't know to which problem you are referring.
> I don't think I "fixed" anything in that area, but if you can give me more
> details, I'll be more than happy to so.
>
> Ate
>
> >
> > Thanks again!
> > -- Jeff Sheets
> >
> >
> > On Thu, 20 Jan 2005 03:49:32 +0100, Ate Douma <at...@douma.nu> wrote:
> >
> >>I'm happy to bring the news of a major upgrade of the Struts Bridge.
> >>
> >>A short summary of its new features:
> >>- Based on the latest Struts-1.2.4
> >>
> >>- Provides new struts-1.2.4-portlet-html.tld and struts-1.2.4-portlet-html-el.tld, as
> >> well as a new struts-portlet-el.tld.
> >> The first two tld files are full replacements for the struts-html and struts-html-el tlds.
> >> By using these tlds instead of the struts-portlet and struts-portlet-el tlds, migrating
> >> existing Struts applications becomes much easier (just change the taglib definition).
> >> Furthermore, there is now full struts-el support Bridge for all the tags (including the
> >> new onces).
> >>
> >>- New Portlet supporting extended Struts tags ImgTag and ImageTag and largely extended
> >> LinkTag and RewriteTag.
> >> These tags now support relative image src paths and href link
> >> paths (including ../ elements).
> >>
> >>- Provides transparent (non-code based) definition of request attribute values to be saved
> >> during ActionRequest handling which will be restored in the subsequent RenderRequest(s).
> >>
> >>- Provides transparent (non-code based) definition of url (prefixes) which must be
> >> rendered as Action or Render PortletURL.
> >> This removes the need to specify the renderURL attribute for link and rewrite tags (its
> >> still supported though, and then will override).
> >>
> >>- xml based configuration of above two features loaded at Portlet initialization.
> >> Default configuration file name: WEB-INF/struts-portlet-config.xml, but this is
> >> configurable itself as well.
> >> Example configuration (from the new JPetstore demo Portlet):
> >> <?xml version="1.0" encoding="UTF-8"?>
> >> <config>
> >> <render-context>
> >> <attribute name="errors"/>
> >> <attribute name="message"/>
> >> </render-context>
> >> <portlet-url-type default="render">
> >> <action path="/shop/add"/>
> >> <action path="/shop/switch"/>
> >> <action path="/shop/remove"/>
> >> <action path="/shop/signoff"/>
> >> <action path="/shop/viewCategory"/>
> >> <action path="/shop/viewItem"/>
> >> <action path="/shop/viewProduct"/>
> >> <action path="/shop/viewCart"/>
> >> <action path="/shop/newOrder"/>
> >> <render path="/shop/newOrderForm"/>
> >> <action path="/shop/listOrders"/>
> >> </portlet-url-type>
> >> </config>
> >>
> >>- IMPORTANT:
> >> Default PorletURL created by link and rewrite tag changed from ActionURL to RenderURL.
> >>
> >> This change is made because in the most cases this turned out to be RenderURLs.
> >>
> >> For migrating of existing Struts Bridge based Portlets to the new version there is an
> >> very simple configuration option to revert this to the old style:
> >>
> >> Define a WEB-INF/struts-portlet-config.xml containing (at least):
> >> <?xml version="1.0" encoding="UTF-8"?>
> >> <config>
> >> <portlet-url-type default="action"/>
> >> </config>
> >>
> >> That'll switch the default back to the old style. For the old Struts MailReader Demo Portlet
> >> also provided with Jetspeed-2, I've put in a configuration file just like that.
> >>
> >>- New demo portlet application: JPetstore Portlet.
> >> This very know example web application from iBatis (www.ibatis.com) is now also available as
> >> Portlet and is automatically deployed in Jetspeed-2 as demo portlet: check it out.
> >>
> >>- Deploy as Portlet or as web application!
> >> The Struts Bridge can now be used in a non-Portlet context, and then will simply fall back to
> >> the basic Struts functionality.
> >> This allows the deployment of the same Portlet Application war as web application and as portlet
> >> application. You can thus also test the application in a web server only (as long as you
> >> don't use Portlet features specifically).
> >>
> >> Try out the JPetstore Portlet demo and access it as Portlet from within Jetspeed-2 or
> >> directly from the webserver (e.g. http://localhost:8080/jpetstore).
> >>
> >>- Abstracted the access to the ServletContextProvider with protected methods in StrutsPortlet
> >> allowing Portal Vendor specific extensions to be used (like VAP).
> >>
> >>- Still no real documentation ;-)
> >> I'm working on it and plan to deliver real usage documentation, as well as a tutorial and instructions
> >> for migrating existing Struts applications, within a week.
> >>
> >>Regards, Ate Douma
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
> >
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: [J2] Major new version of the Struts Bridge: version 0.2 now
available
Posted by Ate Douma <at...@douma.nu>.
Jeff Sheets wrote:
> Wow, this is great Ate! These are many of the features that I was
> hoping for! I will try this out first thing tomorrow morning. Do you
> know if it handles the EditPage better than the last version? I'm
> hoping it fixes a problem that I was having.
Actually, I don't know to which problem you are referring.
I don't think I "fixed" anything in that area, but if you can give me more
details, I'll be more than happy to so.
Ate
>
> Thanks again!
> -- Jeff Sheets
>
>
> On Thu, 20 Jan 2005 03:49:32 +0100, Ate Douma <at...@douma.nu> wrote:
>
>>I'm happy to bring the news of a major upgrade of the Struts Bridge.
>>
>>A short summary of its new features:
>>- Based on the latest Struts-1.2.4
>>
>>- Provides new struts-1.2.4-portlet-html.tld and struts-1.2.4-portlet-html-el.tld, as
>> well as a new struts-portlet-el.tld.
>> The first two tld files are full replacements for the struts-html and struts-html-el tlds.
>> By using these tlds instead of the struts-portlet and struts-portlet-el tlds, migrating
>> existing Struts applications becomes much easier (just change the taglib definition).
>> Furthermore, there is now full struts-el support Bridge for all the tags (including the
>> new onces).
>>
>>- New Portlet supporting extended Struts tags ImgTag and ImageTag and largely extended
>> LinkTag and RewriteTag.
>> These tags now support relative image src paths and href link
>> paths (including ../ elements).
>>
>>- Provides transparent (non-code based) definition of request attribute values to be saved
>> during ActionRequest handling which will be restored in the subsequent RenderRequest(s).
>>
>>- Provides transparent (non-code based) definition of url (prefixes) which must be
>> rendered as Action or Render PortletURL.
>> This removes the need to specify the renderURL attribute for link and rewrite tags (its
>> still supported though, and then will override).
>>
>>- xml based configuration of above two features loaded at Portlet initialization.
>> Default configuration file name: WEB-INF/struts-portlet-config.xml, but this is
>> configurable itself as well.
>> Example configuration (from the new JPetstore demo Portlet):
>> <?xml version="1.0" encoding="UTF-8"?>
>> <config>
>> <render-context>
>> <attribute name="errors"/>
>> <attribute name="message"/>
>> </render-context>
>> <portlet-url-type default="render">
>> <action path="/shop/add"/>
>> <action path="/shop/switch"/>
>> <action path="/shop/remove"/>
>> <action path="/shop/signoff"/>
>> <action path="/shop/viewCategory"/>
>> <action path="/shop/viewItem"/>
>> <action path="/shop/viewProduct"/>
>> <action path="/shop/viewCart"/>
>> <action path="/shop/newOrder"/>
>> <render path="/shop/newOrderForm"/>
>> <action path="/shop/listOrders"/>
>> </portlet-url-type>
>> </config>
>>
>>- IMPORTANT:
>> Default PorletURL created by link and rewrite tag changed from ActionURL to RenderURL.
>>
>> This change is made because in the most cases this turned out to be RenderURLs.
>>
>> For migrating of existing Struts Bridge based Portlets to the new version there is an
>> very simple configuration option to revert this to the old style:
>>
>> Define a WEB-INF/struts-portlet-config.xml containing (at least):
>> <?xml version="1.0" encoding="UTF-8"?>
>> <config>
>> <portlet-url-type default="action"/>
>> </config>
>>
>> That'll switch the default back to the old style. For the old Struts MailReader Demo Portlet
>> also provided with Jetspeed-2, I've put in a configuration file just like that.
>>
>>- New demo portlet application: JPetstore Portlet.
>> This very know example web application from iBatis (www.ibatis.com) is now also available as
>> Portlet and is automatically deployed in Jetspeed-2 as demo portlet: check it out.
>>
>>- Deploy as Portlet or as web application!
>> The Struts Bridge can now be used in a non-Portlet context, and then will simply fall back to
>> the basic Struts functionality.
>> This allows the deployment of the same Portlet Application war as web application and as portlet
>> application. You can thus also test the application in a web server only (as long as you
>> don't use Portlet features specifically).
>>
>> Try out the JPetstore Portlet demo and access it as Portlet from within Jetspeed-2 or
>> directly from the webserver (e.g. http://localhost:8080/jpetstore).
>>
>>- Abstracted the access to the ServletContextProvider with protected methods in StrutsPortlet
>> allowing Portal Vendor specific extensions to be used (like VAP).
>>
>>- Still no real documentation ;-)
>> I'm working on it and plan to deliver real usage documentation, as well as a tutorial and instructions
>> for migrating existing Struts applications, within a week.
>>
>>Regards, Ate Douma
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: [J2] Major new version of the Struts Bridge: version 0.2 now available
Posted by Jeff Sheets <je...@gmail.com>.
Wow, this is great Ate! These are many of the features that I was
hoping for! I will try this out first thing tomorrow morning. Do you
know if it handles the EditPage better than the last version? I'm
hoping it fixes a problem that I was having.
Thanks again!
-- Jeff Sheets
On Thu, 20 Jan 2005 03:49:32 +0100, Ate Douma <at...@douma.nu> wrote:
> I'm happy to bring the news of a major upgrade of the Struts Bridge.
>
> A short summary of its new features:
> - Based on the latest Struts-1.2.4
>
> - Provides new struts-1.2.4-portlet-html.tld and struts-1.2.4-portlet-html-el.tld, as
> well as a new struts-portlet-el.tld.
> The first two tld files are full replacements for the struts-html and struts-html-el tlds.
> By using these tlds instead of the struts-portlet and struts-portlet-el tlds, migrating
> existing Struts applications becomes much easier (just change the taglib definition).
> Furthermore, there is now full struts-el support Bridge for all the tags (including the
> new onces).
>
> - New Portlet supporting extended Struts tags ImgTag and ImageTag and largely extended
> LinkTag and RewriteTag.
> These tags now support relative image src paths and href link
> paths (including ../ elements).
>
> - Provides transparent (non-code based) definition of request attribute values to be saved
> during ActionRequest handling which will be restored in the subsequent RenderRequest(s).
>
> - Provides transparent (non-code based) definition of url (prefixes) which must be
> rendered as Action or Render PortletURL.
> This removes the need to specify the renderURL attribute for link and rewrite tags (its
> still supported though, and then will override).
>
> - xml based configuration of above two features loaded at Portlet initialization.
> Default configuration file name: WEB-INF/struts-portlet-config.xml, but this is
> configurable itself as well.
> Example configuration (from the new JPetstore demo Portlet):
> <?xml version="1.0" encoding="UTF-8"?>
> <config>
> <render-context>
> <attribute name="errors"/>
> <attribute name="message"/>
> </render-context>
> <portlet-url-type default="render">
> <action path="/shop/add"/>
> <action path="/shop/switch"/>
> <action path="/shop/remove"/>
> <action path="/shop/signoff"/>
> <action path="/shop/viewCategory"/>
> <action path="/shop/viewItem"/>
> <action path="/shop/viewProduct"/>
> <action path="/shop/viewCart"/>
> <action path="/shop/newOrder"/>
> <render path="/shop/newOrderForm"/>
> <action path="/shop/listOrders"/>
> </portlet-url-type>
> </config>
>
> - IMPORTANT:
> Default PorletURL created by link and rewrite tag changed from ActionURL to RenderURL.
>
> This change is made because in the most cases this turned out to be RenderURLs.
>
> For migrating of existing Struts Bridge based Portlets to the new version there is an
> very simple configuration option to revert this to the old style:
>
> Define a WEB-INF/struts-portlet-config.xml containing (at least):
> <?xml version="1.0" encoding="UTF-8"?>
> <config>
> <portlet-url-type default="action"/>
> </config>
>
> That'll switch the default back to the old style. For the old Struts MailReader Demo Portlet
> also provided with Jetspeed-2, I've put in a configuration file just like that.
>
> - New demo portlet application: JPetstore Portlet.
> This very know example web application from iBatis (www.ibatis.com) is now also available as
> Portlet and is automatically deployed in Jetspeed-2 as demo portlet: check it out.
>
> - Deploy as Portlet or as web application!
> The Struts Bridge can now be used in a non-Portlet context, and then will simply fall back to
> the basic Struts functionality.
> This allows the deployment of the same Portlet Application war as web application and as portlet
> application. You can thus also test the application in a web server only (as long as you
> don't use Portlet features specifically).
>
> Try out the JPetstore Portlet demo and access it as Portlet from within Jetspeed-2 or
> directly from the webserver (e.g. http://localhost:8080/jpetstore).
>
> - Abstracted the access to the ServletContextProvider with protected methods in StrutsPortlet
> allowing Portal Vendor specific extensions to be used (like VAP).
>
> - Still no real documentation ;-)
> I'm working on it and plan to deliver real usage documentation, as well as a tutorial and instructions
> for migrating existing Struts applications, within a week.
>
> Regards, Ate Douma
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org