Hi Fernando,
Sorry for the somewhat late response but last week I was at the ApacheCon and had more pressing
tasks at the time.
I'm also cross-posting this to the Struts dev@ list for the Struts 2 Portlet developers who
might be interested.
Further comments below.
Regards,
Ate
fernando@lozano.eti.br wrote:
> Hi there,
>
>
> I started this on the Apache Portals Bridges mailing list but had no replies so far.
I have already
> submitted a patch and an opened a ticket on Apache JIRA (PB-93) and hope someone here
can provide
> feedback on my approach to the problem, maybe even expedite it's inclusion on a new release
from
> Apache Portals.
>
> It's related to Struts 1.x (is it still in active development, or at least supported?)
but maybe the
> issues are present also in Struts 2 -- I had a similar issue with JSF and found the problem
was not
> considered either by the MyFaces developers, MyFaces Portlet Bridge developers, or the
JSR-301 and
> JSR-286 expert groups.
This issue was brought forward on (at least) the JSR-301 EG but AFAIK not yet on the JSR-286
EG (I'm an expert member on both).
I already responded on this on the JSR-301 EG, but I'll leave it up to the specification lead
if/when/what to reply.
My comments below however are similar to those I provided there.
>
> I'd also appreciate If someone can comment on the same issues regarding declarative security
and
> Struts 2.
>
> Here's the original, yet unanswered message from the apache portals bridges mailing list:
>
> ----------------------
> I some issues with Java EE declarative security and Struts 1.x Portlets, and a patch
that solves
> some of them. I just wish feedback from users and developers on those issues and my ideas
about them
> before opening a JIRA ticket abd submiting my patch.
>
> Althouth some developers perfer to ignore Java EE security completely, and use either
Acegi or some
> in-house (in-)security solution, if you do use Struts or JSF you can leverage standard
declarative
> security with ease.
>
> But, when you move from from servlets to portlets, you give up all declarative security
features,
> that is, web.xml <security-constraints> become noops. It's not so bad with Struts,
where you can
> still use roles in action mappings, but with JSF and plain servlet development you nave
no option
> but hand coded programatic security. :-(
>
> I understand portlets don't have URI so at first you would not have away to implement
declarative
> security for portlets. Actually, most frameworks use a navigation parameter (navigational
state) to
> emulate request URLs -- This is the case with both the standard JSF portelt bridge and
the Apache
> Portals struts portlet bridige from apache portals. So it would be feasible for a portlet
bridge to
> read <security-constraints> from web.xml and emulate their working as if in a servlet
container.
>
> In the general case, there could be a <security-contraint> inside portlet.xml with
subelements as
> <parameter-name> and <parameter-value> to replace <uri-pattern> from
web.xml, and the portlet
> container could enforce declarative security access control using the navigational context.
>
> I don't believe I was the first to think about this but I think this is a big omission
from all JSRs
> related to portlet development under Java EE. :-(
>
> Another, but related, issue: back to JSF (and also struts) in a servlet container we
would use a
> web.xml <error-page> element for <error-code> 403 to display a user-friendly
"access denied" page.
>
> We also loose this capability inside a portlet container, but that's another thing a
portlet bridge
> could emulate with ease. And that's another thing we could have properly implemented
in portlet.xml,
> maybe as an exception handler so portlets don't get configured for http error codes.
>
> So there are actually two issues:
>
> 1. Enforcing declarative security access controls inside a portlet container -- Struts
already
> solves that using <action-mapping> roles attribute, which is compatible with both
servlet and
> portlet containers;
>
> 2. Dsiplaying an user-friendly error page, which in a servelt container is done by the
container
> itself but not by a portlet container, and neither Struts nor the Apache Portals Portlet
Bridge
> provide an alternative.
First of all, a <security-contraint> or something like an exception handler in portlet.xml
as mentioned above is not possible with the
portlet 2.0 (or 1.0) specification which strictly defines the portlet.xml structure.
This doesn't mean such features cannot be supported in a future portlet spec, but currently
this is impossible without using portlet
container specific descriptors (e.g. vendor extensions).
However, in response to your question as it reached the JSR-301 EG, I proposed a generic (so
not Struts or other framework specific)
solution using a JSR-286 (Portlet 2.0) PortletFilter which might provide the same or similar
behavior as the servlet container.
Such a PortletFilter can do portlet request pre-processing during which it can enforce security-constraints
as well as error-pages
definitions configured either for the PortletFilter specific or possibly dynamically read
(during startup) from the accompanying web.xml
As you mentioned, portlet bridges for Struts, JSF and likewise frameworks almost all use a
predefined (render)request parameter defining the
current or target application "URL". A properly configured PortletFilter therefore could do
portlet request security pre-processing by
inspecting the current value of such parameter and enforce security constraints and if need
be error-page handling as well.
A quick (untested) portlet.xml configuration example I gave on the JSR-301 EG could be:
<filter>
<filter-name>DeclaritivePathSecurityFilter</filter-name>
<filter-class>com.acme.security.DeclaritivePathSecurityFilter</filter-class>
<lifecycle>ACTION_PHASE</lifecycle>
<lifecycle>EVENT_PHASE</lifecycle>
<lifecycle>RENDER_PHASE</lifecycle>
<lifecycle>RESOURCE_PHASE</lifecycle>
<init-param>
<name>pathParameterName</name>
<value>myPathParameterName</value>
</init-param>
<init-param>
<name>error-page:403</name>
<value>/my_403_error_page.jsp</value>
</init-param>
<init-param>
<name>secured-path:/acme/wholesale/*</name>
<value>CONTRACTOR</value>
</init-param>
<init-param>
<name>secured-path:/acme/retail/*</name>
<value>CONTRACTOR,HOMEOWNER</value>
</init-param>
</filter>
For the above example, the DeclaritivePathSecurityFilter would look for a request parameter
"myPathParameterName" and match its value
against init-parameters which name start with "secured-path:", taking the remainder of these
init-parameter names as url-pattern.
If a match is found, it will then evaluate the init-parameter value as list of role names
to enforce against the request.
If it fails, it "overrides" the request parameter "myPathParameterName" with the value for
a (required) configured "error-page:403"
init-parameter.
The filter doesn't actually *do* anything but just hand over the overridden path value to
the underlying portlet bridge/framework, making
this a completely generic solution.
And, as I indicated above, to make this more facy and less verbose, such a filter could instead
read the web.xml security configuration
(possibly using an init-param configuration which web-resource-name(s) to read) and dynamically
construct its own security configuration
based upon that.
Then, you would have an almost transparent and zero-configuration solution.
The alternative solution as you describe below and provided a patch for in http://issues.apache.org/jira/browse/PB-93
probably works fine
too (I haven't had time to look at it), but is StrutsPortlet specific and also requires action-mapping
security configuration (which is just
fine imo, but still Struts specific).
>
> My first idea at (2) was to simply subclass the StrutsPortlet and override the renderError()
method.
> But this is quite restrictive as the original method can't use a RequestDispatcher to
include a JSP
> error page or call an Struts action.
>
> Throwing an exception is also not an option, because exception thrown by StrutsPortlet
don't reach
> the error handler configured by struts-action.xml
>
> My solution is to patch StrutsPortlet so it pass the proxied ServletContext and HttpServeltRequest
> to renderError, and use either a portlet init-param or context-param to configure an
error page by
> http error code, replacing thus the web.xml <error-page> element, and leaving generic
exceptions to
> the struts error handler.
>
> It's a trivial patch and solves my issues until the portlet API provides a better solution,
or
> someone (maybe me) thinks about emulating web.xml declarative security features inside
the portlet
> bridge.
As I said above, I haven't reviewed your patch yet and might be willing to apply it for the
Struts Bridge if feasible, but if my proposal
for such a DeclaritivePathSecurityFilter actually makes sense (and is doable in practice),
I'd prefer such a more generic solution as it is
usable for many frameworks. In that case, I think we'd be more than happy to "host" such a
solution at Apache Portals Bridges, it just needs
to be written :)
However, my "solution" is something I drafted up in 5 min. without actually trying it out,
so possibly I overlooked something obvious which
might render it useless for your case.
Please let me know what you think and we can discuss it further if you like.
In addition, I'm curious to know if the Struts 2 Portlet developers might already have come
up with a solution for this problem themselves?
Any feedback on both these proposals from Fernando and myself would be very welcome.
>
>
> []s, Fernando Lozano
> 4Linux Software, Brazil
>
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[ https://issues.apache.org/jira/browse/PB-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fernando Silva Lozano updated PB-93:
------------------------------------
Attachment: error403.war
A simple CRUD portlet that needs an user with either roles 'gerente' or 'equipe' to change
data. This allows seeing the problem (if portlet init-parameter 'HttpError403Page' is commented
out) or see the patch attached to this issue working.
Sorry, test application in portuguese, but it's so simple (no db, java Map used as 'in-memory'
db) I hope no one will have problem following it. If need I can translate to english.
Configuration files and dependent jars in WEB-INF/lib reflects my development environment
using eXo Platform but there should be nothing in the code which is not JSR-168 / JSR-286
compliant and would prevent working with another portlet container.
> Allow configuring a custom error page for HTTP 403 (access denied)
> ------------------------------------------------------------------
>
> Key: PB-93
> URL: https://issues.apache.org/jira/browse/PB-93
> Project: Portals Bridges
> Issue Type: New Feature
> Components: struts
> Environment: eXo PC 2.0.5 or eXo WCM 1.0, JBoss AS 4.2.3
> Reporter: Fernando Silva Lozano
> Priority: Blocker
> Attachments: error403.war, pb-struts-error403.patch
>
>
> When using Java EE declarative security with struts we rely on web.xml <security-constraint>
and <error-page> to block access to unauthorized pages and display a friendly error
page so, if for example the user followed a bookmark to a page he doesn't have access anymore,
he can return to normal application navigational flow.
> Both elements become no-ops inside a portlet container, but Struts own action mapping
has a roles attribute that replaces the <security -constraint>. But it has no replacement
for <error-page>. Struts returns the access denied error as an HTTP 403 error and not
an exception, so Struts exception handlers cannot be used to provide the user friendly error
page.
> As a portlet cannot return HTTP errors to the user browser, the StrutsPortlet from Struts
Portlet Bridge has a method renderError that displays in a hard-coded error page information
about the error. I patched this method so, if found an the parameter "HttpError403Page", the
Struts Portlet includes the page given as the paramter value. If not, or if there's an exception
while including, continue to the hard-coded error page.
> The portlet init parameter is non-intrusive and follows the portlet bridge convention
of using those to configure default pages for edit, help and view portlet modes.
> Although my tests were made on eXo Platform, I think the issue and my fix are generic
enough to affect and work with any portlet container.
> You can see my message on the apache portals mailing list (the first one from november
2009) for a more detailed explanation.
> http://mail-archives.apache.org/mod_mbox/portals-bridges-user/200911.mbox/browser
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[ https://issues.apache.org/jira/browse/PB-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fernando Silva Lozano updated PB-93:
------------------------------------
Attachment: pb-struts-error403.patch
Adds init parameter HttpError403Page to StrutsPortlet so renderError includes an user-friendly
error page when an action mapping is configured with a roles attribute.
> Allow configuring a custom error page for HTTP 403 (access denied)
> ------------------------------------------------------------------
>
> Key: PB-93
> URL: https://issues.apache.org/jira/browse/PB-93
> Project: Portals Bridges
> Issue Type: New Feature
> Components: struts
> Environment: eXo PC 2.0.5 or eXo WCM 1.0, JBoss AS 4.2.3
> Reporter: Fernando Silva Lozano
> Priority: Blocker
> Attachments: pb-struts-error403.patch
>
>
> When using Java EE declarative security with struts we rely on web.xml <security-constraint>
and <error-page> to block access to unauthorized pages and display a friendly error
page so, if for example the user followed a bookmark to a page he doesn't have access anymore,
he can return to normal application navigational flow.
> Both elements become no-ops inside a portlet container, but Struts own action mapping
has a roles attribute that replaces the <security -constraint>. But it has no replacement
for <error-page>. Struts returns the access denied error as an HTTP 403 error and not
an exception, so Struts exception handlers cannot be used to provide the user friendly error
page.
> As a portlet cannot return HTTP errors to the user browser, the StrutsPortlet from Struts
Portlet Bridge has a method renderError that displays in a hard-coded error page information
about the error. I patched this method so, if found an the parameter "HttpError403Page", the
Struts Portlet includes the page given as the paramter value. If not, or if there's an exception
while including, continue to the hard-coded error page.
> The portlet init parameter is non-intrusive and follows the portlet bridge convention
of using those to configure default pages for edit, help and view portlet modes.
> Although my tests were made on eXo Platform, I think the issue and my fix are generic
enough to affect and work with any portlet container.
> You can see my message on the apache portals mailing list (the first one from november
2009) for a more detailed explanation.
> http://mail-archives.apache.org/mod_mbox/portals-bridges-user/200911.mbox/browser
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
Allow configuring a custom error page for HTTP 403 (access denied)
------------------------------------------------------------------
Key: PB-93
URL: https://issues.apache.org/jira/browse/PB-93
Project: Portals Bridges
Issue Type: New Feature
Components: struts
Environment: eXo PC 2.0.5 or eXo WCM 1.0, JBoss AS 4.2.3
Reporter: Fernando Silva Lozano
Priority: Blocker
When using Java EE declarative security with struts we rely on web.xml <security-constraint>
and <error-page> to block access to unauthorized pages and display a friendly error
page so, if for example the user followed a bookmark to a page he doesn't have access anymore,
he can return to normal application navigational flow.
Both elements become no-ops inside a portlet container, but Struts own action mapping has
a roles attribute that replaces the <security -constraint>. But it has no replacement
for <error-page>. Struts returns the access denied error as an HTTP 403 error and not
an exception, so Struts exception handlers cannot be used to provide the user friendly error
page.
As a portlet cannot return HTTP errors to the user browser, the StrutsPortlet from Struts
Portlet Bridge has a method renderError that displays in a hard-coded error page information
about the error. I patched this method so, if found an the parameter "HttpError403Page", the
Struts Portlet includes the page given as the paramter value. If not, or if there's an exception
while including, continue to the hard-coded error page.
The portlet init parameter is non-intrusive and follows the portlet bridge convention of using
those to configure default pages for edit, help and view portlet modes.
Although my tests were made on eXo Platform, I think the issue and my fix are generic enough
to affect and work with any portlet container.
You can see my message on the apache portals mailing list (the first one from november 2009)
for a more detailed explanation.
http://mail-archives.apache.org/mod_mbox/portals-bridges-user/200911.mbox/browser
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
Hi there, I some issuies with Java EE declarative security and Struts 1.x Portlets, and a patch that solves some of them. I just wish feedback from users and developers on those issues and my ideas about them before opening a JIRA ticket abd submiting my patch. Althouth some developers perfer to ignore Java EE security completely, and use either Acegi or some in-house (in-)security solution, if you do use Struts or JSF you can leverage standard declarative security with ease. But,when you move from from servlets to portlets, you give up all declarative security features, that is, web.xml <security-constraints> become noops. It's not so bad with Struts, where you can stilluse roles in action mappings, but with JSF and plain servlet development you nave no option but hand coded programatic security. :-( I understand portlets don't have URI so at first you would not have away to implement declarative security for portlets. Actually, most frameworks use a navigation parameter(navigational state) to emulate request URLs -- This is the case with both the standard JSF portelt bridge and the Apache Portals struts portlet bridige from apache portals. So it would be feasible for a portlet bridge to read <security-constraints> from web.xml and emulate their working as if in a servlet container. In the general case, there could be a <security-contraint> inside portlet.xml with subelements as <parameter-name> and <parameter-value> to replace <uri-pattern> from web.xml, and the portlet container could enforce declarative security access control using the navigational context. I don't believe I was the first to think about this but I think this is a big omission from all JSRs related to portlet development under Java EE. :-( Another, but related, issue: back to JSF (and also struts) in a servlet container we would use a web.xml <error-page> element for <error-code> 403 to display a user-friendly "access denied" page. We also loose this capability inside a portlet container, but that's another thing a portlet bridge could emulate with ease. And that's another thing we could have properly implemented in portlet.xml, maybe as an exception handler so portlets don't get configured for http error codes. So there are actually two issues: 1. Enforcing declarative security access controls inside a portlet container -- Struts already solves that using <action-mapping> compatible with both servlet and portlet containers; 2. Dsiplaying an user-friendly error page, which in a servelt container is done by the container itself but not by a portlet container, and neither Struts nor the Apache Portals Portlet Bridge provide an alternative. My first idea at (2) was to simply subclass the StrutsPortlet and override the renderError() method. But this is quite restrictive as the original method can't use a RequestDispatcher to include a JSP error page or call an Struts action. Throwing an exception is also not an option, because exception thrown by StrutsPortlet don't reach the error handler configured by struts-action.xml My solution is to patch StrutsPortlet so it pass the proxied ServletContext and HttpServeltRequest to renderError, and use either a portlet init-param or context-param to configure an error page by http error code, replacing thus the web.xml <error-page> element, and leaving generic exceptions to the struts error handler. It's a trivial patch and solves my issues until the portlet API provides a better solution, or someone (maybe me) thinks about emulating web.xml declarative security features inside the portlet bridge. []s, Fernando Lozano ex-Java.Net Community Manager 4Linux Software, Brazil --------------------------------------------------------------------- To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org For additional commands, e-mail: bridges-dev-help@portals.apache.org
[ https://issues.apache.org/jira/browse/PB-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Trevor Lohrbeer updated PB-92:
------------------------------
Attachment: servlet-and-portlets-side-by-side-v2.patch
Attached is an updated patch. My isPortlet() function in PortletViewHandlerImpl was not working
correctly because PortletExternalContextImpl does not implement javax.portlet.PortletContext.
Instead, now I'm testing to see if the facesContext is an instance of PortletFacesContextImpl,
which should work as long as the FacesContextFactory remains the portals bridges FacesContextFactoryImpl.
> JSF servlets don't work when used side-by-side with JSF portlets
> ----------------------------------------------------------------
>
> Key: PB-92
> URL: https://issues.apache.org/jira/browse/PB-92
> Project: Portals Bridges
> Issue Type: Bug
> Components: jsf
> Affects Versions: 1.0.4
> Environment: JBoss 4.0.5 running Apache MyFaces 1.1.5, portlet-bridges 1.0.4
> Reporter: Trevor Lohrbeer
> Attachments: servlet-and-portlets-side-by-side-v2.patch, servlet-and-portlets-side-by-side.patch
>
>
> When the portlet bridges library is included in a WAR file, JSP pages can only be accessed
through portlets, not directly from the FacesServlet. Attempting to access a JSP page through
the FacesServlet results in an IllegalArgumentException with the message "Only PortletContext
supported". The stack trace shows that this occurs when attempting to access the session map.
> Upon further investigation, the problem stems from the fact that the portlet-bridges-jsf
library includes a META-INF/faces-config.xml file which installs a custom FacesContextFactory
and ViewHandler. These are installed for the entire web application, yet are designed only
to work with portlets. Thus, running JSF portlets and servlets side-by-side results in errors.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[ https://issues.apache.org/jira/browse/PB-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Trevor Lohrbeer updated PB-92:
------------------------------
Attachment: servlet-and-portlets-side-by-side.patch
Attached is a patch that fixes the problem by allowing the various maps used by a request
to use either portlet or servlet contexts and requests. It also modifies the PortletViewHandlerImpl
to delegate to the parent view handler when processing a servlet request.
Note that I just started looking at the code today, so there may be a more efficient way to
achieve the same results. I included notes in parts that I thought might need to be reviewed
before merging into the main codebase.
> JSF servlets don't work when used side-by-side with JSF portlets
> ----------------------------------------------------------------
>
> Key: PB-92
> URL: https://issues.apache.org/jira/browse/PB-92
> Project: Portals Bridges
> Issue Type: Bug
> Components: jsf
> Affects Versions: 1.0.4
> Environment: JBoss 4.0.5 running Apache MyFaces 1.1.5, portlet-bridges 1.0.4
> Reporter: Trevor Lohrbeer
> Attachments: servlet-and-portlets-side-by-side.patch
>
>
> When the portlet bridges library is included in a WAR file, JSP pages can only be accessed
through portlets, not directly from the FacesServlet. Attempting to access a JSP page through
the FacesServlet results in an IllegalArgumentException with the message "Only PortletContext
supported". The stack trace shows that this occurs when attempting to access the session map.
> Upon further investigation, the problem stems from the fact that the portlet-bridges-jsf
library includes a META-INF/faces-config.xml file which installs a custom FacesContextFactory
and ViewHandler. These are installed for the entire web application, yet are designed only
to work with portlets. Thus, running JSF portlets and servlets side-by-side results in errors.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
JSF servlets don't work when used side-by-side with JSF portlets
----------------------------------------------------------------
Key: PB-92
URL: https://issues.apache.org/jira/browse/PB-92
Project: Portals Bridges
Issue Type: Bug
Components: jsf
Affects Versions: 1.0.4
Environment: JBoss 4.0.5 running Apache MyFaces 1.1.5, portlet-bridges 1.0.4
Reporter: Trevor Lohrbeer
When the portlet bridges library is included in a WAR file, JSP pages can only be accessed
through portlets, not directly from the FacesServlet. Attempting to access a JSP page through
the FacesServlet results in an IllegalArgumentException with the message "Only PortletContext
supported". The stack trace shows that this occurs when attempting to access the session map.
Upon further investigation, the problem stems from the fact that the portlet-bridges-jsf library
includes a META-INF/faces-config.xml file which installs a custom FacesContextFactory and
ViewHandler. These are installed for the entire web application, yet are designed only to
work with portlets. Thus, running JSF portlets and servlets side-by-side results in errors.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
Norway, camping, completely disconnected :) Happy holidays everyone! Regards, Ate --------------------------------------------------------------------- To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org For additional commands, e-mail: bridges-dev-help@portals.apache.org
[ https://issues.apache.org/jira/browse/PB-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Bosman updated PB-91:
---------------------------
Attachment: PB-91.patch
Added a new patch which handles portletMode as well.
Changing the portlet mode is a slightly harder modification than the one for window state
because it needed a change in the StrutsPortletURL class to pick the correct request parameter,
i.e. _spageview, _spageedit or _spagehelp (otherwise users would keep being sent to the
default pages as declared in portlet.xml).
> Add windowState attribute to link, form and rewrite tags
> --------------------------------------------------------
>
> Key: PB-91
> URL: https://issues.apache.org/jira/browse/PB-91
> Project: Portals Bridges
> Issue Type: Improvement
> Components: struts
> Affects Versions: 1.0.4
> Reporter: Steve Bosman
> Assignee: Ate Douma
> Priority: Minor
> Fix For: 1.0.5
>
> Attachments: PB-91.patch, PB-91.patch
>
>
> It would be useful if the link, form and rewrite tags could create links that alter the
window state.
> I have supplied a patch
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
Hi, I'm using Struts 1.2.4 with Tiles and Bridges to create portlets for Jahia. I have a page with a form using Tiles for rendering. The page is correctly displayed. When a user push the submit button, the action is correctly called. When the index.jsp is processed: any <tiles:useAttribute/> fails with: Tiles context not found any <tiles:insert/> fails with: java.lang.NullPointerException The stack is joined at the end of the mail. The problem seems to be similar to http://mail-archives.apache.org/mod_mbox/portals-bridges-dev/200601.mbox /%3C20060126111656.38148.qmail@web25808.mail.ukl.yahoo.com%3E but I can't find the patch file online. Could somebody provide me the patch for tiles or have information about this error? Thank you very much in advance, Benoit PIRONET The complete stack is: org.apache.struts.taglib.tiles.InsertTag.processAttribute(InsertTag.java :685) org.apache.struts.taglib.tiles.InsertTag.createTagHandler(InsertTag.java :476) org.apache.struts.taglib.tiles.InsertTag.doStartTag(InsertTag.java:436) org.apache.jsp.index_jsp._jspx_meth_tiles_005finsert_005f0(index_jsp.jav a:267) org.apache.jsp.index_jsp._jspService(index_jsp.java:218) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja va:374) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica tionFilterChain.java:290) org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt erChain.java:206) org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatc her.java:630) org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDisp atcher.java:535) org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispat cher.java:472) org.apache.portals.bridges.struts.PortletServletRequestDispatcher.invoke (PortletServletRequestDispatcher.java:128) org.apache.portals.bridges.struts.PortletServletRequestDispatcher.includ e(PortletServletRequestDispatcher.java:146) org.apache.portals.bridges.struts.PortletServlet.performActionRenderRequ est(PortletServlet.java:179) org.apache.portals.bridges.struts.PortletTilesRequestProcessor.processRo les(PortletTilesRequestProcessor.java:57) org.apache.struts.action.RequestProcessor.process(RequestProcessor.java: 199) org.apache.portals.bridges.struts.PortletTilesRequestProcessor.process(P ortletTilesRequestProcessor.java:50) org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164) org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:397) javax.servlet.http.HttpServlet.service(HttpServlet.java:617) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica tionFilterChain.java:290) org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt erChain.java:206) org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatc her.java:630) org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDisp atcher.java:535) org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispat cher.java:472) org.apache.portals.bridges.struts.StrutsPortlet.processRequest(StrutsPor tlet.java:375) org.apache.portals.bridges.struts.StrutsPortlet.doView(StrutsPortlet.jav a:274) javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) javax.portlet.GenericPortlet.render(GenericPortlet.java:175) org.apache.jetspeed.factory.JetspeedPortletInstance.render(JetspeedPortl etInstance.java:102) org.apache.jetspeed.container.JetspeedContainerServlet.doGet(JetspeedCon tainerServlet.java:235) javax.servlet.http.HttpServlet.service(HttpServlet.java:617) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica tionFilterChain.java:290) org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt erChain.java:206) org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatc her.java:630) org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDisp atcher.java:535) org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispat cher.java:472) org.apache.jetspeed.container.invoker.ServletPortletInvoker.invoke(Servl etPortletInvoker.java:215) org.apache.jetspeed.container.invoker.ServletPortletInvoker.render(Servl etPortletInvoker.java:126) org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl .java:119) org.apache.jetspeed.container.JetspeedPortletContainerWrapper.renderPort let(JetspeedPortletContainerWrapper.java:120) org.apache.jetspeed.aggregator.impl.RenderingJobImpl.execute(RenderingJo bImpl.java:121) org.apache.jetspeed.aggregator.impl.PortletRendererImpl.renderNow(Portle tRendererImpl.java:120) org.apache.jetspeed.aggregator.impl.PortletAggregatorImpl.build(PortletA ggregatorImpl.java:84) org.apache.jetspeed.aggregator.PortletValve.invoke(PortletValve.java:46) org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(Jets peedPipeline.java:166) org.apache.jetspeed.container.ContainerValve.invoke(ContainerValve.java: 76) org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(Jets peedPipeline.java:166) org.jahia.services.applications.JahiaSecurityValveImpl.invoke(JahiaSecur ityValveImpl.java:82) org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(Jets peedPipeline.java:166) org.apache.jetspeed.container.url.impl.PortalURLValveImpl.invoke(PortalU RLValveImpl.java:67) org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(Jets peedPipeline.java:166) org.jahia.services.applications.JahiaProfilerValveImpl.invoke(JahiaProfi lerValveImpl.java:67) org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(Jets peedPipeline.java:166) org.apache.jetspeed.capabilities.impl.CapabilityValveImpl.invoke(Capabil ityValveImpl.java:128) org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(Jets peedPipeline.java:166) org.jahia.portal.localization.LocalizationValveImpl.invoke(LocalizationV alveImpl.java:118) org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(Jets peedPipeline.java:166) org.apache.jetspeed.pipeline.JetspeedPipeline.invoke(JetspeedPipeline.ja va:145) org.apache.jetspeed.engine.JetspeedEngine.service(JetspeedEngine.java:21 4) org.jahia.bin.JahiaJetspeedServlet.doGet(JahiaJetspeedServlet.java:235) javax.servlet.http.HttpServlet.service(HttpServlet.java:617) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica tionFilterChain.java:290) org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt erChain.java:206) org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatc her.java:630) org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDisp atcher.java:535) org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispat cher.java:472) org.jahia.services.applications.JetspeedDispatchingProvider.render(Jetsp eedDispatchingProvider.java:271) org.jahia.services.applications.DispatchingServiceImpl.getAppOutput(Disp atchingServiceImpl.java:165) org.jahia.services.applications.DispatchingServiceImpl$$FastClassByCGLIB $$7271be17.invoke() net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149) org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.i nvokeJoinpoint(Cglib2AopProxy.java:661) org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Ref lectiveMethodInvocation.java:122) org.springframework.aop.interceptor.AbstractTraceInterceptor.invoke(Abst ractTraceInterceptor.java:80) org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Ref lectiveMethodInvocation.java:144) org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedIntercept or.intercept(Cglib2AopProxy.java:606) org.jahia.services.applications.DispatchingServiceImpl$$EnhancerByCGLIB$ $78f956e6.getAppOutput() org.jahia.services.fields.ContentApplicationField.getValue(ContentApplic ationField.java:110) org.jahia.services.fields.ContentField.getValue(ContentField.java:314) org.jahia.data.fields.JahiaApplicationField.load(JahiaApplicationField.j ava:133) org.jahia.services.fields.JahiaFieldBaseService.loadField(JahiaFieldBase Service.java:822) org.jahia.services.fields.JahiaFieldBaseService.loadField(JahiaFieldBase Service.java:776) org.jahia.services.fields.JahiaFieldBaseService$$FastClassByCGLIB$$a2320 0ff.invoke() net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149) org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.i nvokeJoinpoint(Cglib2AopProxy.java:661) org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Ref lectiveMethodInvocation.java:122) org.springframework.aop.interceptor.AbstractTraceInterceptor.invoke(Abst ractTraceInterceptor.java:80) org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Ref lectiveMethodInvocation.java:144) org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedIntercept or.intercept(Cglib2AopProxy.java:606) org.jahia.services.fields.JahiaFieldBaseService$$EnhancerByCGLIB$$796a97 1e.loadField() org.jahia.services.containers.ContainerFactory.fullyLoadContainer(Contai nerFactory.java:117) org.jahia.services.containers.ContainerFactoryProxy.load(ContainerFactor yProxy.java:120) org.jahia.data.containers.JahiaContainer.checkProxy(JahiaContainer.java: 884) org.jahia.data.containers.JahiaContainer.getField(JahiaContainer.java:50 0) org.jahia.taglibs.field.AbstractFieldTag.doStartTag(AbstractFieldTag.jav a:315) org.jahia.taglibs.field.ApplicationFieldTag.doStartTag(ApplicationFieldT ag.java:62) org.apache.jsp.jsp.jahia.templates.refin.REFIN_005fJahiaPE_005ftemplates .application_jsp._jspx_meth_content_005fapplicationField_005f2(applicati on_jsp.java:14482) org.apache.jsp.jsp.jahia.templates.refin.REFIN_005fJahiaPE_005ftemplates .application_jsp._jspService(application_jsp.java:5902) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja va:374) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica tionFilterChain.java:290) org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt erChain.java:206) org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatc her.java:630) org.apache.catalina.core.ApplicationDispatcher.processRequest(Applicatio nDispatcher.java:436) org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDisp atcher.java:374) org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispat cher.java:302) org.jahia.engines.EngineRenderer.renderCore(EngineRenderer.java:210) org.jahia.engines.EngineRenderer.render(EngineRenderer.java:86) org.jahia.engines.core.Core_Engine.processCore(Core_Engine.java:167) org.jahia.engines.core.Core_Engine.handleActions(Core_Engine.java:110) org.jahia.operations.valves.EngineValve.processEngineRequest(EngineValve .java:180) org.jahia.operations.valves.EngineValve.invoke(EngineValve.java:82) org.jahia.pipelines.impl.GenericPipeline.invokeNext(GenericPipeline.java :208) org.jahia.operations.valves.J2ProcessActionValve.invoke(J2ProcessActionV alve.java:144) org.jahia.pipelines.impl.GenericPipeline.invokeNext(GenericPipeline.java :208) org.jahia.operations.valves.SkeletonAggregatorValve.invoke(SkeletonAggre gatorValve.java:73) org.jahia.pipelines.impl.GenericPipeline.invokeNext(GenericPipeline.java :208) org.jahia.operations.valves.PageAccessCheckValve.invoke(PageAccessCheckV alve.java:73) org.jahia.pipelines.impl.GenericPipeline.invokeNext(GenericPipeline.java :208) org.jahia.operations.valves.OperationModeCheckValve.invoke(OperationMode CheckValve.java:83) org.jahia.pipelines.impl.GenericPipeline.invokeNext(GenericPipeline.java :208) org.jahia.operations.valves.SiteCheckValve.invoke(SiteCheckValve.java:78 ) org.jahia.pipelines.impl.GenericPipeline.invokeNext(GenericPipeline.java :208) org.jahia.operations.valves.EsiFragmentCacheReadValve.invoke(EsiFragment CacheReadValve.java:329) org.jahia.pipelines.impl.GenericPipeline.invokeNext(GenericPipeline.java :208) org.jahia.operations.valves.EsiUrlCookieCheckValve.invoke(EsiUrlCookieCh eckValve.java:311) org.jahia.pipelines.impl.GenericPipeline.invokeNext(GenericPipeline.java :208) org.jahia.pipelines.impl.GenericPipeline.invoke(GenericPipeline.java:195 ) org.jahia.operations.OperationManager.handleOperations(OperationManager. java:100) org.jahia.bin.JahiaAction.execute(JahiaAction.java:76) org.apache.struts.action.RequestProcessor.processActionPerform(RequestPr ocessor.java:421) org.apache.struts.action.RequestProcessor.process(RequestProcessor.java: 226) org.jahia.bin.JahiaRequestProcessor.process(JahiaRequestProcessor.java:8 2) org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164) org.jahia.bin.Jahia.process(Jahia.java:1659) org.jahia.bin.Jahia.service(Jahia.java:861) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica tionFilterChain.java:290) org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt erChain.java:206) org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv e.java:233) org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv e.java:191) org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authenticator Base.java:433) org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java :128) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java :102) org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve. java:109) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:2 86) org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:84 5) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process( Http11Protocol.java:583) org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) java.lang.Thread.run(Thread.java:619)
[ https://issues.apache.org/jira/browse/PB-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723974#action_12723974
]
Ate Douma commented on PB-91:
-----------------------------
Thanks for the patch!
I will review it shortly.
One enhancement I might merge in with this is also adding support for optionally setting target
PortletMode as well besides the WindowState.
> Add windowState attribute to link, form and rewrite tags
> --------------------------------------------------------
>
> Key: PB-91
> URL: https://issues.apache.org/jira/browse/PB-91
> Project: Portals Bridges
> Issue Type: Improvement
> Components: struts
> Affects Versions: 1.0.4
> Reporter: Steve Bosman
> Priority: Minor
> Fix For: 1.0.5
>
> Attachments: PB-91.patch
>
>
> It would be useful if the link, form and rewrite tags could create links that alter the
window state.
> I have supplied a patch
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[ https://issues.apache.org/jira/browse/PB-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma reassigned PB-91:
---------------------------
Assignee: Ate Douma
> Add windowState attribute to link, form and rewrite tags
> --------------------------------------------------------
>
> Key: PB-91
> URL: https://issues.apache.org/jira/browse/PB-91
> Project: Portals Bridges
> Issue Type: Improvement
> Components: struts
> Affects Versions: 1.0.4
> Reporter: Steve Bosman
> Assignee: Ate Douma
> Priority: Minor
> Fix For: 1.0.5
>
> Attachments: PB-91.patch
>
>
> It would be useful if the link, form and rewrite tags could create links that alter the
window state.
> I have supplied a patch
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[ https://issues.apache.org/jira/browse/PB-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Bosman updated PB-91:
---------------------------
Priority: Minor (was: Major)
> Add windowState attribute to link, form and rewrite tags
> --------------------------------------------------------
>
> Key: PB-91
> URL: https://issues.apache.org/jira/browse/PB-91
> Project: Portals Bridges
> Issue Type: Improvement
> Components: struts
> Affects Versions: 1.0.4
> Reporter: Steve Bosman
> Priority: Minor
> Fix For: 1.0.5
>
> Attachments: PB-91.patch
>
>
> It would be useful if the link, form and rewrite tags could create links that alter the
window state.
> I have supplied a patch
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[ https://issues.apache.org/jira/browse/PB-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Bosman updated PB-91:
---------------------------
Attachment: PB-91.patch
Patch tested locally using struts 1.2.9 and liferay 5.2.3 (although I see no reason for it
to be version dependent)
> Add windowState attribute to link, form and rewrite tags
> --------------------------------------------------------
>
> Key: PB-91
> URL: https://issues.apache.org/jira/browse/PB-91
> Project: Portals Bridges
> Issue Type: Improvement
> Components: struts
> Affects Versions: 1.0.4
> Reporter: Steve Bosman
> Fix For: 1.0.5
>
> Attachments: PB-91.patch
>
>
> It would be useful if the link, form and rewrite tags could create links that alter the
window state.
> I have supplied a patch
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
Add windowState attribute to link, form and rewrite tags
--------------------------------------------------------
Key: PB-91
URL: https://issues.apache.org/jira/browse/PB-91
Project: Portals Bridges
Issue Type: Improvement
Components: struts
Affects Versions: 1.0.4
Reporter: Steve Bosman
Fix For: 1.0.5
It would be useful if the link, form and rewrite tags could create links that alter the window
state.
I have supplied a patch
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
Dear all,
I'm having a problem when changing a Struts app to Liferay's portlet.
In Struts app, I use tag <html:link> to go to a Struts action with some
parameters.
When I run it as Struts application, the link like this:
http://localhost:8080/FirstStrutsSample/detailViewAction.do?id=05130030
In action class, I use request.getParameter("id") -> it's OK
But when run it as portlet, the link like this:
http://localhost:8080/web/guest/home?p_p_id=studentManagement_WAR_FirstStrut
sSample&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-1&p
_p_col_count=2&_studentManagement_WAR_FirstStrutsSample__spage=%2FdetailView
Action.do%3Fid%3D05130030
And it understands that the parameter is _spage and value is
/detailViewAction.do?id=05130072
In action class the method request.getParameter("id") returns null.
So what is the problem here?
Thanks for your reply
Phuc Bui
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[ https://issues.apache.org/jira/browse/PB-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Woonsan Ko updated PB-90:
-------------------------
Description: GroovyPortletHeaderPhaseSupport should be deprecated because header phase
is natively supported in JSR-286 compliant portal. (was: GroovyPortletHeaderPhaseSupport
should be deprecated because header phase is not a native support in JSR-286 compliant portal.)
> GroovyPortletHeaderPhaseSupport should be deprecated
> ----------------------------------------------------
>
> Key: PB-90
> URL: https://issues.apache.org/jira/browse/PB-90
> Project: Portals Bridges
> Issue Type: Improvement
> Reporter: Woonsan Ko
> Assignee: Woonsan Ko
>
> GroovyPortletHeaderPhaseSupport should be deprecated because header phase is natively
supported in JSR-286 compliant portal.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[ https://issues.apache.org/jira/browse/PB-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Woonsan Ko resolved PB-90.
--------------------------
Resolution: Fixed
> GroovyPortletHeaderPhaseSupport should be deprecated
> ----------------------------------------------------
>
> Key: PB-90
> URL: https://issues.apache.org/jira/browse/PB-90
> Project: Portals Bridges
> Issue Type: Improvement
> Reporter: Woonsan Ko
> Assignee: Woonsan Ko
>
> GroovyPortletHeaderPhaseSupport should be deprecated because header phase is not a native
support in JSR-286 compliant portal.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
GroovyPortletHeaderPhaseSupport should be deprecated
----------------------------------------------------
Key: PB-90
URL: https://issues.apache.org/jira/browse/PB-90
Project: Portals Bridges
Issue Type: Improvement
Reporter: Woonsan Ko
Assignee: Woonsan Ko
GroovyPortletHeaderPhaseSupport should be deprecated because header phase is not a native
support in JSR-286 compliant portal.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
Name property of a submit input not correctly set ("1" instead of real value)
-----------------------------------------------------------------------------
Key: PB-89
URL: https://issues.apache.org/jira/browse/PB-89
Project: Portals Bridges
Issue Type: Bug
Components: struts
Affects Versions: 1.0.4
Environment: Local on windows, Jboss Portal 2.7.1 bundle, jboss AS 4.2.3
Reporter: Vincent Vanghelle
Hi.
I've got a problem in my form, in a struts web app.
Directly via the action, form is ok, but with struts portlet, there is a problem at the "name"
tag of a submit input.
Here is the submit input of my form :
Code:
<html:submit property="action" ><bean:message key="link.Cancel"/></html:submit>
For both directly via the action and via the portlet, the generated html is :
Code:
<input type="submit" name="action" value="Cancel" />
But in my form bean, i've got 2 different things :
- Via the action, the property is ok, when I do a getAction() I obtain "Cancel"
- Via the Struts portlet, when I do a getAction(), I obtain "1". (whatever the value I give
to the submit input name)
And it does that only for the submit input, text input are normal
So there's a problem in the form bean Validator, and my form don't work...
thanks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
ApacheCon EU 2009 registration is now open!
23-27 March -- Mövenpick Hotel, Amsterdam, Netherlands
http://www.eu.apachecon.com/
================================
Registration for ApacheCon Europe 2009 is now open - act before early
bird prices expire 6 February. Remember to book a room at the Mövenpick
and use the Registration Code: Special package attendees for the
conference registration, and get 150 Euros off your full conference
registration.
Lower Costs - Thanks to new VAT tax laws, our prices this year are 19%
lower than last year in Europe! We've also negotiated a Mövenpick rate
of a maximum of 155 Euros per night for attendees in our room block.
Quick Links:
http://xrl.us/aceu09sp See the schedule
http://xrl.us/aceu09hp Get your hotel room
http://xrl.us/aceu09rp Register for the conference
Other important notes:
- Geeks for Geeks is a new mini-track where we can feature advanced
technical content from project committers. And our Hackathon on Monday
and Tuesday is open to all attendees - be sure to check it off in your
registration.
- The Call for Papers for ApacheCon US 2009, held 2-6 November
2009 in Oakland, CA, is open through 28 February, so get your
submissions in now. This ApacheCon will feature special events with
some of the ASF's original founders in celebration of the 10th
anniversary of The Apache Software Foundation.
http://www.us.apachecon.com/c/acus2009/
- Interested in sponsoring the ApacheCon conferences? There are plenty
of sponsor packages available - please contact Delia Frees at
delia@apachecon.com for further information.
======================================================
ApacheCon EU 2008: A week of Open Source at it's best!
Hackathon - open to all! | Geeks for Geeks | Lunchtime Sessions
In-Depth Trainings | Multi-Track Sessions | BOFs | Business Panel
Lightning Talks | Receptions | Fast Feather Track | Expo... and more!
- Shane Curcuru, on behalf of
Noirin Shirley, Conference Lead,
and the whole ApacheCon Europe 2009 Team
http://www.eu.apachecon.com/ 23-27 March -- Amsterdam, Netherlands
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
I've noticed that org.apache.portals.bridges:portals-bridges-common:1.0.4 on the central maven repository [1] has the wrong SHA1 checksums. In a reaction from a Maven developer he suggested that the developers of portals-bridges-commons could fix the checksums and request a new upload for them. [quote] Yes, you need to make sure they are fixed in the apache repository first: http://people.apache.org/repo/m2-ibiblio-rsync-repository which is up to the project in question. Then they can ask for them to be re-synced (checks only, not POMs or artifact changes). [/quote] Could someone pick this up? [1] http://repo1.maven.org/maven2/org/apache/portals/bridges/portals-bridges-common/1.0.4/portals-bridges-common-1.0.4.jar With regards, Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl --------------------------------------------------------------------- To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org For additional commands, e-mail: bridges-dev-help@portals.apache.org
Will bridges work correct with newer versions of struts 1.3.x
-------------------------------------------------------------
Key: PB-88
URL: https://issues.apache.org/jira/browse/PB-88
Project: Portals Bridges
Issue Type: Improvement
Reporter: Alexey Zavizionov
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[ https://issues.apache.org/jira/browse/PB-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antony Stubbs updated PB-84:
----------------------------
Attachment: utils.patch
Still, applying the changes suggested so far will at least make it easier for people to debug,
rather than the CCE.
> CCE in PortletWindowUtils.getPortletWindowId
> --------------------------------------------
>
> Key: PB-84
> URL: https://issues.apache.org/jira/browse/PB-84
> Project: Portals Bridges
> Issue Type: Bug
> Components: common
> Affects Versions: 1.0
> Environment: Mac OS, Wicket Portlets, OpenPortal Portlet Container
> Reporter: Tim Boudreau
> Attachments: portals-bridges-common-1.0.4.jar, utils.patch
>
>
> I'm trying to get wicket portlet support working over OpenPortal. I've hacked together
implementations of ServletContextProvider and PortletResourceURLFactory - just required exposing
WicketFilter from the Application to get the necessary data. I can deploy a portlet, but...
> I'm getting this exception.
> java.lang.ClassCastException: java.lang.Double
> at org.apache.portals.bridges.util.PortletWindowUtils.getPortletWindowId(PortletWindowUtils.java:45)
> Looking at the code, this seems like a clear bug: The method casts to String here:
> (String)session.getAttribute(PORTLET_WINDOW_ID);
> and if null fills in the value with an instance of Double. If it's going to put a Double
there, it should probably not expect a String - this exception will occur any time this method
is called twice for a PortletSession, it will throw the CCE the second time it is called.
> Since the value is not used, probably simply changing it to
> Object portletWindowId = session.getAttribute(PORTLET_WINDOW_ID);
> would fix it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[ https://issues.apache.org/jira/browse/PB-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12641683#action_12641683
]
Ate Douma commented on PB-84:
-----------------------------
FYI: PLUTO-516 has been fixed, see: https://issues.apache.org/jira/browse/PLUTO-516?focusedCommentId=12641680#action_12641680
That issue very much relates to this one and if you can read in my comment on PLUTO-516, I
suspect the reported errors on PB-84 and PB-77 on other containers like JBoss and OpenPortal
might very well be caused by the exact same implementation mistake.
>From that POV, I'm even less inclined now to spend much time trying to find a reliable
work around as that most likely just won't be possible if those other containers indeed made
the same mistake.
The earlier work around I proposed above (https://issues.apache.org/jira/browse/PB-84?focusedCommentId=12623333#action_12623333)
definitely won't work.
As I haven't received the needed feedback for validation on that work around I already concluded
it to be invalid, and now I'm even more sure about it.
So, unless someone can come up with another explanation and possible solution for those containers,
I'll probably close this issue in the near future as Incomplete/Won't Fix
> CCE in PortletWindowUtils.getPortletWindowId
> --------------------------------------------
>
> Key: PB-84
> URL: https://issues.apache.org/jira/browse/PB-84
> Project: Portals Bridges
> Issue Type: Bug
> Components: common
> Affects Versions: 1.0
> Environment: Mac OS, Wicket Portlets, OpenPortal Portlet Container
> Reporter: Tim Boudreau
> Attachments: portals-bridges-common-1.0.4.jar
>
>
> I'm trying to get wicket portlet support working over OpenPortal. I've hacked together
implementations of ServletContextProvider and PortletResourceURLFactory - just required exposing
WicketFilter from the Application to get the necessary data. I can deploy a portlet, but...
> I'm getting this exception.
> java.lang.ClassCastException: java.lang.Double
> at org.apache.portals.bridges.util.PortletWindowUtils.getPortletWindowId(PortletWindowUtils.java:45)
> Looking at the code, this seems like a clear bug: The method casts to String here:
> (String)session.getAttribute(PORTLET_WINDOW_ID);
> and if null fills in the value with an instance of Double. If it's going to put a Double
there, it should probably not expect a String - this exception will occur any time this method
is called twice for a PortletSession, it will throw the CCE the second time it is called.
> Since the value is not used, probably simply changing it to
> Object portletWindowId = session.getAttribute(PORTLET_WINDOW_ID);
> would fix it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[ https://issues.apache.org/jira/browse/PB-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma reassigned PB-87:
---------------------------
Assignee: Ate Douma
> javadoc for ServletPortletSessionProxy
> --------------------------------------
>
> Key: PB-87
> URL: https://issues.apache.org/jira/browse/PB-87
> Project: Portals Bridges
> Issue Type: Improvement
> Affects Versions: 1.0.4
> Reporter: Antony Stubbs
> Assignee: Ate Douma
> Attachments: bridges javadoc patch.diff
>
>
> adds missing javadoc
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[ https://issues.apache.org/jira/browse/PB-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antony Stubbs updated PB-87:
----------------------------
Attachment: bridges javadoc patch.diff
> javadoc for ServletPortletSessionProxy
> --------------------------------------
>
> Key: PB-87
> URL: https://issues.apache.org/jira/browse/PB-87
> Project: Portals Bridges
> Issue Type: Improvement
> Affects Versions: 1.0.4
> Reporter: Antony Stubbs
> Attachments: bridges javadoc patch.diff
>
>
> adds missing javadoc
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
javadoc for ServletPortletSessionProxy
--------------------------------------
Key: PB-87
URL: https://issues.apache.org/jira/browse/PB-87
Project: Portals Bridges
Issue Type: Improvement
Affects Versions: 1.0.4
Reporter: Antony Stubbs
adds missing javadoc
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[ https://issues.apache.org/jira/browse/PB-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12641201#action_12641201
]
Antony Stubbs commented on PB-84:
---------------------------------
While we're at improving this code, may I also suggest something along the following lines?
To help with error resolution...
{code}
/** The portlet scope namespace as defined in PLT. 15.3. */
private static final String PORTLET_SCOPE_NAMESPACE = "javax.portlet.p.";
/**
* The attribute name of the portlet winow id test, to be stored in the portlet session.
*/
public static String PORTLET_WINDOW_ID = "org.apache.portals.bridges.util.portlet_window_id";
{code}
and
{code}
...
final String[] nameRef = new String[1]; // array so that it can be accessed within anonymous
class yet changed later
...
// check that the attribute name was prefixed properly / as expected
if (nameRef[0].startsWith(PORTLET_SCOPE_NAMESPACE) && nameRef[0].contains("?"))
{
portletWindowId = nameRef[0].substring(PORTLET_SCOPE_NAMESPACE.length(),
nameRef[0].indexOf('?'));
System.out.println(" --> found - PORTLET_WINDOW_ID = " + portletWindowId);
session.setAttribute(PORTLET_WINDOW_ID, portletWindowId,
PortletSession.PORTLET_SCOPE);
}
else
{
throw new RuntimeException(
"Window ID attribute not prefixed with PORTLET_SCOPE_NAMESPACE. "
+ "Make sure the portlet container stores the attribute in PORTLET_SCOPE_NAMESPACE
"
+ "and prefix's the name with the PORTLET NAMESPACE.");
}
{code}
> CCE in PortletWindowUtils.getPortletWindowId
> --------------------------------------------
>
> Key: PB-84
> URL: https://issues.apache.org/jira/browse/PB-84
> Project: Portals Bridges
> Issue Type: Bug
> Components: common
> Affects Versions: 1.0
> Environment: Mac OS, Wicket Portlets, OpenPortal Portlet Container
> Reporter: Tim Boudreau
> Attachments: portals-bridges-common-1.0.4.jar
>
>
> I'm trying to get wicket portlet support working over OpenPortal. I've hacked together
implementations of ServletContextProvider and PortletResourceURLFactory - just required exposing
WicketFilter from the Application to get the necessary data. I can deploy a portlet, but...
> I'm getting this exception.
> java.lang.ClassCastException: java.lang.Double
> at org.apache.portals.bridges.util.PortletWindowUtils.getPortletWindowId(PortletWindowUtils.java:45)
> Looking at the code, this seems like a clear bug: The method casts to String here:
> (String)session.getAttribute(PORTLET_WINDOW_ID);
> and if null fills in the value with an instance of Double. If it's going to put a Double
there, it should probably not expect a String - this exception will occur any time this method
is called twice for a PortletSession, it will throw the CCE the second time it is called.
> Since the value is not used, probably simply changing it to
> Object portletWindowId = session.getAttribute(PORTLET_WINDOW_ID);
> would fix it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[ https://issues.apache.org/jira/browse/PB-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12641169#action_12641169
]
Antony Stubbs commented on PB-84:
---------------------------------
Ok, trying to track this down, think I've found something.
Why does the Pluto PorletSessionImpl#setAttribute use application shop in the following situation?
This really needs explanation ala javadoc etc. Because in the spec, it clearly says that setAttribute
should use PORTLET_SCOPE as it does in the else block. This seems to be cause the session
attributes set in getWindowId in the Apache Bridges to fail in detecting the container assigned
window id, because of course the attribute gets put into APPLICATION_SCOPE and a window id
is never created.
{code}
public void setAttribute(String name, Object value, int scope) {
ArgumentUtility.validateNotNull("attributeName", name);
if (scope == PortletSession.APPLICATION_SCOPE) {
httpSession.setAttribute(name, value);
} else {
httpSession.setAttribute(createPortletScopedId(name), value);
}
}
{code}
Ok, yup, changing the setAttribute calls from PortletWindowUtils#getWindowId to call the explicit
version of setAttribute(name,value,scope) and pass PortletSession.PORTLET_SCOPE lets the Apache
Bridges function work correctly.
This points towards a Pluto issue now, not a bridges issue, so I will create another jira
issue for pluto.
For a work around, I have changed getWindowId to use
{code}
session.setAttribute(PORTLET_WINDOW_ID, ...., PortletSession.PORTLET_SCOPE);
{code}
in both places where it is used, and the windowId now appears to be generated on the attribute,
and detected correctly.
I have created a Pluto issue here:
https://issues.apache.org/jira/browse/PLUTO-516
> CCE in PortletWindowUtils.getPortletWindowId
> --------------------------------------------
>
> Key: PB-84
> URL: https://issues.apache.org/jira/browse/PB-84
> Project: Portals Bridges
> Issue Type: Bug
> Components: common
> Affects Versions: 1.0
> Environment: Mac OS, Wicket Portlets, OpenPortal Portlet Container
> Reporter: Tim Boudreau
> Attachments: portals-bridges-common-1.0.4.jar
>
>
> I'm trying to get wicket portlet support working over OpenPortal. I've hacked together
implementations of ServletContextProvider and PortletResourceURLFactory - just required exposing
WicketFilter from the Application to get the necessary data. I can deploy a portlet, but...
> I'm getting this exception.
> java.lang.ClassCastException: java.lang.Double
> at org.apache.portals.bridges.util.PortletWindowUtils.getPortletWindowId(PortletWindowUtils.java:45)
> Looking at the code, this seems like a clear bug: The method casts to String here:
> (String)session.getAttribute(PORTLET_WINDOW_ID);
> and if null fills in the value with an instance of Double. If it's going to put a Double
there, it should probably not expect a String - this exception will occur any time this method
is called twice for a PortletSession, it will throw the CCE the second time it is called.
> Since the value is not used, probably simply changing it to
> Object portletWindowId = session.getAttribute(PORTLET_WINDOW_ID);
> would fix it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[ https://issues.apache.org/jira/browse/PB-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12640538#action_12640538
]
Antony Stubbs commented on PB-84:
---------------------------------
P.s. its just a basic hello world portlet application, nothing to it, deployed to pluto installed
on tomcat using pluto:install .
> CCE in PortletWindowUtils.getPortletWindowId
> --------------------------------------------
>
> Key: PB-84
> URL: https://issues.apache.org/jira/browse/PB-84
> Project: Portals Bridges
> Issue Type: Bug
> Components: common
> Affects Versions: 1.0
> Environment: Mac OS, Wicket Portlets, OpenPortal Portlet Container
> Reporter: Tim Boudreau
> Attachments: portals-bridges-common-1.0.4.jar
>
>
> I'm trying to get wicket portlet support working over OpenPortal. I've hacked together
implementations of ServletContextProvider and PortletResourceURLFactory - just required exposing
WicketFilter from the Application to get the necessary data. I can deploy a portlet, but...
> I'm getting this exception.
> java.lang.ClassCastException: java.lang.Double
> at org.apache.portals.bridges.util.PortletWindowUtils.getPortletWindowId(PortletWindowUtils.java:45)
> Looking at the code, this seems like a clear bug: The method casts to String here:
> (String)session.getAttribute(PORTLET_WINDOW_ID);
> and if null fills in the value with an instance of Double. If it's going to put a Double
there, it should probably not expect a String - this exception will occur any time this method
is called twice for a PortletSession, it will throw the CCE the second time it is called.
> Since the value is not used, probably simply changing it to
> Object portletWindowId = session.getAttribute(PORTLET_WINDOW_ID);
> would fix it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[ https://issues.apache.org/jira/browse/PB-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12640536#action_12640536
]
Antony Stubbs commented on PB-84:
---------------------------------
actually, come to think of it, the StringIndexOutOfBoundsException was probably the reason
why the Double wasnt being replaced, as the code threw the exception before it got to that
stage, and subsequent requests were retrieving the Double and getting the class cast exceptions.
But regardless, your new implementation does seem to clarify the issues.
> CCE in PortletWindowUtils.getPortletWindowId
> --------------------------------------------
>
> Key: PB-84
> URL: https://issues.apache.org/jira/browse/PB-84
> Project: Portals Bridges
> Issue Type: Bug
> Components: common
> Affects Versions: 1.0
> Environment: Mac OS, Wicket Portlets, OpenPortal Portlet Container
> Reporter: Tim Boudreau
> Attachments: portals-bridges-common-1.0.4.jar
>
>
> I'm trying to get wicket portlet support working over OpenPortal. I've hacked together
implementations of ServletContextProvider and PortletResourceURLFactory - just required exposing
WicketFilter from the Application to get the necessary data. I can deploy a portlet, but...
> I'm getting this exception.
> java.lang.ClassCastException: java.lang.Double
> at org.apache.portals.bridges.util.PortletWindowUtils.getPortletWindowId(PortletWindowUtils.java:45)
> Looking at the code, this seems like a clear bug: The method casts to String here:
> (String)session.getAttribute(PORTLET_WINDOW_ID);
> and if null fills in the value with an instance of Double. If it's going to put a Double
there, it should probably not expect a String - this exception will occur any time this method
is called twice for a PortletSession, it will throw the CCE the second time it is called.
> Since the value is not used, probably simply changing it to
> Object portletWindowId = session.getAttribute(PORTLET_WINDOW_ID);
> would fix it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[ https://issues.apache.org/jira/browse/PB-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12640533#action_12640533
]
Antony Stubbs commented on PB-84:
---------------------------------
Ok, the new code that you posted seems to do better, but I seem to have a problem where
{code}
portletWindowId = nameRef[0].substring("javax.portlet.p.".length(),
nameRef[0].indexOf('?'));
{code}
throws StringIndexOutOfBoundsException, because the value of nameRef[0] comes back just as
PORTLET_WINDOW_ID
i.e. "org.apache.portals.bridges.util.portlet_window_id" not "javax.portlet.p.*" as the code
implies
{code}
getPortletWindowId for session: CC465B39BA9199712DEEF690F90AE2C2 (thread: 15)
no portletWindowId yet - going to derive it.
17/10/2008 15:44:23 org.apache.catalina.core.ApplicationDispatcher invoke
SEVERE: Servlet.service() for servlet default threw exception
java.lang.StringIndexOutOfBoundsException: String index out of range: -17
{code}
> CCE in PortletWindowUtils.getPortletWindowId
> --------------------------------------------
>
> Key: PB-84
> URL: https://issues.apache.org/jira/browse/PB-84
> Project: Portals Bridges
> Issue Type: Bug
> Components: common
> Affects Versions: 1.0
> Environment: Mac OS, Wicket Portlets, OpenPortal Portlet Container
> Reporter: Tim Boudreau
> Attachments: portals-bridges-common-1.0.4.jar
>
>
> I'm trying to get wicket portlet support working over OpenPortal. I've hacked together
implementations of ServletContextProvider and PortletResourceURLFactory - just required exposing
WicketFilter from the Application to get the necessary data. I can deploy a portlet, but...
> I'm getting this exception.
> java.lang.ClassCastException: java.lang.Double
> at org.apache.portals.bridges.util.PortletWindowUtils.getPortletWindowId(PortletWindowUtils.java:45)
> Looking at the code, this seems like a clear bug: The method casts to String here:
> (String)session.getAttribute(PORTLET_WINDOW_ID);
> and if null fills in the value with an instance of Double. If it's going to put a Double
there, it should probably not expect a String - this exception will occur any time this method
is called twice for a PortletSession, it will throw the CCE the second time it is called.
> Since the value is not used, probably simply changing it to
> Object portletWindowId = session.getAttribute(PORTLET_WINDOW_ID);
> would fix it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[ https://issues.apache.org/jira/browse/PB-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12640531#action_12640531
]
Ate Douma commented on PB-84:
-----------------------------
Now this is getting interesting :)
Can you give some instruction steps how to reproduce this, and with which (Wicket?) application
did you test it with?
> CCE in PortletWindowUtils.getPortletWindowId
> --------------------------------------------
>
> Key: PB-84
> URL: https://issues.apache.org/jira/browse/PB-84
> Project: Portals Bridges
> Issue Type: Bug
> Components: common
> Affects Versions: 1.0
> Environment: Mac OS, Wicket Portlets, OpenPortal Portlet Container
> Reporter: Tim Boudreau
> Attachments: portals-bridges-common-1.0.4.jar
>
>
> I'm trying to get wicket portlet support working over OpenPortal. I've hacked together
implementations of ServletContextProvider and PortletResourceURLFactory - just required exposing
WicketFilter from the Application to get the necessary data. I can deploy a portlet, but...
> I'm getting this exception.
> java.lang.ClassCastException: java.lang.Double
> at org.apache.portals.bridges.util.PortletWindowUtils.getPortletWindowId(PortletWindowUtils.java:45)
> Looking at the code, this seems like a clear bug: The method casts to String here:
> (String)session.getAttribute(PORTLET_WINDOW_ID);
> and if null fills in the value with an instance of Double. If it's going to put a Double
there, it should probably not expect a String - this exception will occur any time this method
is called twice for a PortletSession, it will throw the CCE the second time it is called.
> Since the value is not used, probably simply changing it to
> Object portletWindowId = session.getAttribute(PORTLET_WINDOW_ID);
> would fix it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[ https://issues.apache.org/jira/browse/PB-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12640511#action_12640511
]
Antony Stubbs commented on PB-84:
---------------------------------
Hi Ate,
I've just hit this same problem with Pluto trunk no less... Am looking further into it now.
> CCE in PortletWindowUtils.getPortletWindowId
> --------------------------------------------
>
> Key: PB-84
> URL: https://issues.apache.org/jira/browse/PB-84
> Project: Portals Bridges
> Issue Type: Bug
> Components: common
> Affects Versions: 1.0
> Environment: Mac OS, Wicket Portlets, OpenPortal Portlet Container
> Reporter: Tim Boudreau
> Attachments: portals-bridges-common-1.0.4.jar
>
>
> I'm trying to get wicket portlet support working over OpenPortal. I've hacked together
implementations of ServletContextProvider and PortletResourceURLFactory - just required exposing
WicketFilter from the Application to get the necessary data. I can deploy a portlet, but...
> I'm getting this exception.
> java.lang.ClassCastException: java.lang.Double
> at org.apache.portals.bridges.util.PortletWindowUtils.getPortletWindowId(PortletWindowUtils.java:45)
> Looking at the code, this seems like a clear bug: The method casts to String here:
> (String)session.getAttribute(PORTLET_WINDOW_ID);
> and if null fills in the value with an instance of Double. If it's going to put a Double
there, it should probably not expect a String - this exception will occur any time this method
is called twice for a PortletSession, it will throw the CCE the second time it is called.
> Since the value is not used, probably simply changing it to
> Object portletWindowId = session.getAttribute(PORTLET_WINDOW_ID);
> would fix it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
The Travel Assistance Committee is taking in applications for those wanting to attend ApacheCon US 2008 between the 3rd and 7th November 2008 in New Orleans. The Travel Assistance Committee is looking for people who would like to be able to attend ApacheCon US 2008 who need some financial support in order to get there. There are VERY few places available and the criteria is high, that aside applications are open to all open source developers who feel that their attendance would benefit themselves, their project(s), the ASF and open source in general. Financial assistance is available for flights, accomodation and entrance fees either in full or in part, depending on circumstances. It is intended that all our ApacheCon events are covered, so it may be prudent for those in Europe and or Asia to wait until an event closer to them comes up - you are all welcome to apply for ApacheCon US of course, but there must be compelling reasons for you to attend an event further away that your home location for your application to be considered above those closer to the event location. More information can be found on the main Apache website at http://www.apache.org/travel/index.html - where you will also find a link to the application form and details for submitting. Time is very tight for this event, so applications are open now and will end on the 2nd October 2008 - to give enough time for travel arrangements to be made. Good luck to all those that will apply. Regards, The Travel Assistance Committee
[ https://issues.apache.org/jira/browse/PB-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma updated PB-86:
------------------------
Fix Version/s: (was: 1.0.4)
(was: 1.0.3)
1.0.5
> Configure StrutsPortlet error output (disable stack trace for security reason)
> ------------------------------------------------------------------------------
>
> Key: PB-86
> URL: https://issues.apache.org/jira/browse/PB-86
> Project: Portals Bridges
> Issue Type: Improvement
> Components: struts
> Affects Versions: 1.0.3, 1.0.4
> Reporter: Joachim Müller
> Assignee: Ate Douma
> Fix For: 1.0.5
>
> Attachments: patch_PB-86.diff
>
>
> Currently the StrutsPortlet always renders the full stack trace into the portlet when
an error occurs. This may be critical concerning security issues.
> With the supplied patch the error message can be loaded via resource bundle (per portlet
). The message can contain place holders which will be replaced by specific error data.
> Example:
> - specify portlet resources in portlet xml:
> <resource-bundle>JPetstorePortletResources</resource-bundle>
> - specify error message inside bundle:
> <code>
> # Message to be rendered in HTML when unhandled ERROR in StrutsPortlet occured (exception).
> # {ErrorCode} = will be replaced by StrutsPortletErrorContext.getErrorCode (blank if
not set)
> # {ErrorMessage} = will be replaced by StrutsPortletErrorContext.getErrorMessage (blank
if not set)
> # {Exception.Message} = will be replaced by StrutsPortletErrorContext.getError.getMessage
-> e.g. when ServletException (blank if not set)
> # {Exception.Class.Name} = will be replaced by StrutsPortletErrorContext.getError.getClass.getName
-> e.g. when ServletException (blank if not set)
> # {Exception.StackTrace} = will be replaced by StrutsPortletErrorContext.getError.getStackTrace
-> e.g. when ServletException (blank if not set)
> # former default in code:
> strutsportlet.error.output=<hr/><h2>Error</h2><table border='1'><tr><td
valign='top'><b>Error Code</b></td><td>{ErrorCode}</td></tr><tr><td
valign='top'><b>Error Message</b></td><td>{ErrorMessage}</td></tr><tr><td
valign='top'><b>Error</b></td><td>{Exception.Message}</td></tr><tr><td
valign='top'><b>Error Type</b></td><td>{Exception.Class.Name}</td></tr><tr><td
valign='top'><b>Stacktrace</b></td><td>{Exception.StackTrace}</td></tr></table>
> <code>
> If no bundle or message is specified, the patch reduces the default output to "Error"
without rendering specific error data (stack trace ...).
> CAUTION: The bundle is only supplied for the JPETSTORE Portlet. All other Struts Portlet
do output only "Error" when rendering an error. This behavior can be changed in the StrutsPortlet.java
(commented).
> The default configuration in the bundle supplied is to output the error information as
it was before.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[ https://issues.apache.org/jira/browse/PB-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma reassigned PB-86:
---------------------------
Assignee: Ate Douma
> Configure StrutsPortlet error output (disable stack trace for security reason)
> ------------------------------------------------------------------------------
>
> Key: PB-86
> URL: https://issues.apache.org/jira/browse/PB-86
> Project: Portals Bridges
> Issue Type: Improvement
> Components: struts
> Affects Versions: 1.0.3, 1.0.4
> Reporter: Joachim Müller
> Assignee: Ate Douma
> Fix For: 1.0.3, 1.0.4
>
> Attachments: patch_PB-86.diff
>
>
> Currently the StrutsPortlet always renders the full stack trace into the portlet when
an error occurs. This may be critical concerning security issues.
> With the supplied patch the error message can be loaded via resource bundle (per portlet
). The message can contain place holders which will be replaced by specific error data.
> Example:
> - specify portlet resources in portlet xml:
> <resource-bundle>JPetstorePortletResources</resource-bundle>
> - specify error message inside bundle:
> <code>
> # Message to be rendered in HTML when unhandled ERROR in StrutsPortlet occured (exception).
> # {ErrorCode} = will be replaced by StrutsPortletErrorContext.getErrorCode (blank if
not set)
> # {ErrorMessage} = will be replaced by StrutsPortletErrorContext.getErrorMessage (blank
if not set)
> # {Exception.Message} = will be replaced by StrutsPortletErrorContext.getError.getMessage
-> e.g. when ServletException (blank if not set)
> # {Exception.Class.Name} = will be replaced by StrutsPortletErrorContext.getError.getClass.getName
-> e.g. when ServletException (blank if not set)
> # {Exception.StackTrace} = will be replaced by StrutsPortletErrorContext.getError.getStackTrace
-> e.g. when ServletException (blank if not set)
> # former default in code:
> strutsportlet.error.output=<hr/><h2>Error</h2><table border='1'><tr><td
valign='top'><b>Error Code</b></td><td>{ErrorCode}</td></tr><tr><td
valign='top'><b>Error Message</b></td><td>{ErrorMessage}</td></tr><tr><td
valign='top'><b>Error</b></td><td>{Exception.Message}</td></tr><tr><td
valign='top'><b>Error Type</b></td><td>{Exception.Class.Name}</td></tr><tr><td
valign='top'><b>Stacktrace</b></td><td>{Exception.StackTrace}</td></tr></table>
> <code>
> If no bundle or message is specified, the patch reduces the default output to "Error"
without rendering specific error data (stack trace ...).
> CAUTION: The bundle is only supplied for the JPETSTORE Portlet. All other Struts Portlet
do output only "Error" when rendering an error. This behavior can be changed in the StrutsPortlet.java
(commented).
> The default configuration in the bundle supplied is to output the error information as
it was before.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[ https://issues.apache.org/jira/browse/PB-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joachim Müller updated PB-86:
-----------------------------
Attachment: patch_PB-86.diff
> Configure StrutsPortlet error output (disable stack trace for security reason)
> ------------------------------------------------------------------------------
>
> Key: PB-86
> URL: https://issues.apache.org/jira/browse/PB-86
> Project: Portals Bridges
> Issue Type: Improvement
> Components: struts
> Affects Versions: 1.0.3, 1.0.4
> Reporter: Joachim Müller
> Fix For: 1.0.3, 1.0.4
>
> Attachments: patch_PB-86.diff
>
>
> Currently the StrutsPortlet always renders the full stack trace into the portlet when
an error occurs. This may be critical concerning security issues.
> With the supplied patch the error message can be loaded via resource bundle (per portlet
). The message can contain place holders which will be replaced by specific error data.
> Example:
> - specify portlet resources in portlet xml:
> <resource-bundle>JPetstorePortletResources</resource-bundle>
> - specify error message inside bundle:
> <code>
> # Message to be rendered in HTML when unhandled ERROR in StrutsPortlet occured (exception).
> # {ErrorCode} = will be replaced by StrutsPortletErrorContext.getErrorCode (blank if
not set)
> # {ErrorMessage} = will be replaced by StrutsPortletErrorContext.getErrorMessage (blank
if not set)
> # {Exception.Message} = will be replaced by StrutsPortletErrorContext.getError.getMessage
-> e.g. when ServletException (blank if not set)
> # {Exception.Class.Name} = will be replaced by StrutsPortletErrorContext.getError.getClass.getName
-> e.g. when ServletException (blank if not set)
> # {Exception.StackTrace} = will be replaced by StrutsPortletErrorContext.getError.getStackTrace
-> e.g. when ServletException (blank if not set)
> # former default in code:
> strutsportlet.error.output=<hr/><h2>Error</h2><table border='1'><tr><td
valign='top'><b>Error Code</b></td><td>{ErrorCode}</td></tr><tr><td
valign='top'><b>Error Message</b></td><td>{ErrorMessage}</td></tr><tr><td
valign='top'><b>Error</b></td><td>{Exception.Message}</td></tr><tr><td
valign='top'><b>Error Type</b></td><td>{Exception.Class.Name}</td></tr><tr><td
valign='top'><b>Stacktrace</b></td><td>{Exception.StackTrace}</td></tr></table>
> <code>
> If no bundle or message is specified, the patch reduces the default output to "Error"
without rendering specific error data (stack trace ...).
> CAUTION: The bundle is only supplied for the JPETSTORE Portlet. All other Struts Portlet
do output only "Error" when rendering an error. This behavior can be changed in the StrutsPortlet.java
(commented).
> The default configuration in the bundle supplied is to output the error information as
it was before.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org