You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Ate Douma (JIRA)" <ji...@apache.org> on 2007/06/15 11:50:26 UTC
[jira] Created: (WICKET-660) New Wicket Portlet support: Merge
WicketPortletFilter back in WicketFilter using a delagate class for
handling and (class) loading the portlet specific functionality
New Wicket Portlet support: Merge WicketPortletFilter back in WicketFilter using a delagate class for handling and (class) loading the portlet specific functionality
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: WICKET-660
URL: https://issues.apache.org/jira/browse/WICKET-660
Project: Wicket
Issue Type: Sub-task
Components: wicket-portlet
Affects Versions: 1.3.0-beta2
Reporter: Ate Douma
Assignee: Ate Douma
I moved the usage of all portlet api specific classes in WicketPortletFilter to a separately class, WicketFilterPortletContext, which will only be created when running in a portlet container.
As effect, the resulting WicketPortletFilter code doesn't depend on the portlet api anymore, so using it within a non-portlet container context (plain Tomcat or Jetty for instance) is now possible too.
But, now the remaing code in WicketPortletFilter really does do much itself anymore and can easily be integrated back in WicketFilter without problems.
I've decided to do so as it makes Wicket portlet support even less intrusive as it was before: no need to configure a different filter anymore in web.xml !
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-660) New Wicket Portlet support: Merge
WicketPortletFilter back in WicketFilter using a delagate class for
handling and (class) loading the portlet specific functionality
Posted by "Ate Douma (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ate Douma resolved WICKET-660.
------------------------------
Resolution: Fixed
Fixed again.
I've updated the downloadable wicket-examples.war too:
http://people.apache.org/~ate/wicket/wicket-examples/r547651/wicket-examples.war
> New Wicket Portlet support: Merge WicketPortletFilter back in WicketFilter using a delagate class for handling and (class) loading the portlet specific functionality
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-660
> URL: https://issues.apache.org/jira/browse/WICKET-660
> Project: Wicket
> Issue Type: Sub-task
> Components: wicket-portlet
> Affects Versions: 1.3.0-beta2
> Reporter: Ate Douma
> Assignee: Ate Douma
>
> I moved the usage of all portlet api specific classes in WicketPortletFilter to a separately class, WicketFilterPortletContext, which will only be created when running in a portlet container.
> As effect, the resulting WicketPortletFilter code doesn't depend on the portlet api anymore, so using it within a non-portlet container context (plain Tomcat or Jetty for instance) is now possible too.
> But, now the remaing code in WicketPortletFilter really does do much itself anymore and can easily be integrated back in WicketFilter without problems.
> I've decided to do so as it makes Wicket portlet support even less intrusive as it was before: no need to configure a different filter anymore in web.xml !
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (WICKET-660) New Wicket Portlet support: Merge
WicketPortletFilter back in WicketFilter using a delagate class for
handling and (class) loading the portlet specific functionality
Posted by "Ate Douma (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ate Douma reopened WICKET-660:
------------------------------
The merge of WicketFilter and WicketPortletFilter isn't correct yet.
Super calls allows for easy override of parameters, which shouldn't be overlooked when merging two methods...
> New Wicket Portlet support: Merge WicketPortletFilter back in WicketFilter using a delagate class for handling and (class) loading the portlet specific functionality
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-660
> URL: https://issues.apache.org/jira/browse/WICKET-660
> Project: Wicket
> Issue Type: Sub-task
> Components: wicket-portlet
> Affects Versions: 1.3.0-beta2
> Reporter: Ate Douma
> Assignee: Ate Douma
>
> I moved the usage of all portlet api specific classes in WicketPortletFilter to a separately class, WicketFilterPortletContext, which will only be created when running in a portlet container.
> As effect, the resulting WicketPortletFilter code doesn't depend on the portlet api anymore, so using it within a non-portlet container context (plain Tomcat or Jetty for instance) is now possible too.
> But, now the remaing code in WicketPortletFilter really does do much itself anymore and can easily be integrated back in WicketFilter without problems.
> I've decided to do so as it makes Wicket portlet support even less intrusive as it was before: no need to configure a different filter anymore in web.xml !
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-660) New Wicket Portlet support: Merge
WicketPortletFilter back in WicketFilter using a delagate class for
handling and (class) loading the portlet specific functionality
Posted by "Ate Douma (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ate Douma resolved WICKET-660.
------------------------------
Resolution: Fixed
Done.
So now you can deploy a portlet-supporting wicket application also in plain web containers!
I've build a new version of the wicket-examples.war which you can download from my apache home page
http://people.apache.org/~ate/wicket/wicket-examples/r547598/wicket-examples.war
This example can be used a drop in replacement in the jetspeed-2.1.1-beta1-wicket-demo-installer I've created yesterday (see: WICKET-658): just copy it into ${installationPath}/webapps/jetspeed/WEB-INF/deploy.
And of course you can test run it in a plain web container like Tomcat or Jetty too.
> New Wicket Portlet support: Merge WicketPortletFilter back in WicketFilter using a delagate class for handling and (class) loading the portlet specific functionality
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-660
> URL: https://issues.apache.org/jira/browse/WICKET-660
> Project: Wicket
> Issue Type: Sub-task
> Components: wicket-portlet
> Affects Versions: 1.3.0-beta2
> Reporter: Ate Douma
> Assignee: Ate Douma
>
> I moved the usage of all portlet api specific classes in WicketPortletFilter to a separately class, WicketFilterPortletContext, which will only be created when running in a portlet container.
> As effect, the resulting WicketPortletFilter code doesn't depend on the portlet api anymore, so using it within a non-portlet container context (plain Tomcat or Jetty for instance) is now possible too.
> But, now the remaing code in WicketPortletFilter really does do much itself anymore and can easily be integrated back in WicketFilter without problems.
> I've decided to do so as it makes Wicket portlet support even less intrusive as it was before: no need to configure a different filter anymore in web.xml !
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.