Re: OpenSessionInViewFilter not working in portlets?
Gonzalo Aguilar Delgado wrote: Hi, I'm trying to make the OpenSessionInViewFilter to work with my portlets but it seems that does not initialize nor work. Can you check if something is wrong, please? What I see is missing from your web.xml is needed dispatcher configurations for the OpenSessionInViewFilter filter-mapping to get it invoked when you invoke Wicket from the WicketPortlet. By default a filter is *only* invoked during a direct client-side REQUEST, not during an include or forward from within another servlet (or portlet, which of course is also invoked as a servlet). See also servlet spec 2.4, SRV.6.2.5 Filters and the RequestDispatcher So you need to add additional dispatcher settings, just as with the WicketFilter, to the filter-mapping for openSessionInViewFilter: filter-mapping filter-nameopenSessionInViewFilter/filter-name url-pattern/customer-detail/*/url-pattern dispatcherREQUEST/dispatcher dispatcherINCLUDE/dispatcher dispatcherFORWARD/dispatcher /filter-mapping HTH, Ate Thank you -- web.xml --- ?xml version=1.0 encoding=UTF-8? !-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; version=2.4 xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; display-nameMy Portlet Application/display-name !-- For deploying on Websphere: disable WebSphere default portletcontainer However: if you actually want to deploy on WebSphere Portal, comment the following out -- context-param param-namecom.ibm.websphere.portletcontainer.PortletDeploymentEnabled/param-name param-valuefalse/param-value /context-param context-param param-namecontextConfigLocation/param-name param-value/WEB-INF/applicationContext.xml/param-value /context-param listener listener-classorg.springframework.web.context.ContextLoaderListener/listener-class /listener !-- Enable the filters for Hibernate -- filter filter-nameopenSessionInViewFilter/filter-name filter-classorg.springframework.orm.hibernate3.support.OpenSessionInViewFilter/filter-class init-param param-namesingleSession/param-name param-valuetrue/param-value /init-param init-param param-namesessionFactoryBeanName/param-name param-valueopRoyalCaninSessionFactory/param-value /init-param /filter filter-mapping filter-nameopenSessionInViewFilter/filter-name url-pattern/customer-detail/*/url-pattern /filter-mapping !-- Wicket filters -- filter filter-nameCustomerDetailPortlet/filter-name filter-classorg.apache.wicket.protocol.http.WicketFilter/filter-class init-param param-nameapplicationFactoryClassName/param-name param-valueorg.apache.wicket.spring.SpringWebApplicationFactory/param-value /init-param init-param param-nameapplicationBean/param-name param-valuecustomerDetailPortletBean/param-value /init-param /filter filter-mapping filter-nameCustomerDetailPortlet/filter-name url-pattern/customer-detail/*/url-pattern dispatcherREQUEST/dispatcher dispatcherINCLUDE/dispatcher dispatcherFORWARD/dispatcher /filter-mapping !-- Added when deployed with maven -- servlet descriptionMVC Servlet for Jetspeed Portlet Applications/description display-nameJetspeed Container/display-name servlet-nameJetspeedContainer/servlet-name servlet-classorg.apache.jetspeed.container.JetspeedContainerServlet/servlet-class init-param param-namecontextName/param-name param-valuecrmportal-contact/param-value /init-param
Re: Wicket portles in Sun Portal
Wilhelmsen Tor Iver wrote: To dig up this old thread: I now use Ate Douma's patch for JSR-286 support from https://issues.apache.org/jira/browse/WICKET-1620 which has removed the need for the portal to implement the Apache portlet bridge's two interfaces. A small step for man etc. :) Well, credits for those patches go to Thijs Vonk, I'm just the assignee of that issue :) Note though: those patches *as such* still need quite some refactoring (as already discussed on this list before) and the final JSR-286 support very likely will turn out a little bit different... For those who haven't discovered this yet, I might have a nice news update: JSR-286 has finally landed! See: http://jcp.org/aboutJava/communityprocess/final/jsr286/index.html There now is an issue - the same I had in JBoss - that it seems the bridge has a bug where the WicketFilterPortletContext call to ServletPortletSessionProxy.createProxy(filterRequestContext.getRequest() ) places a Double into the window-id propery that later will be cast to String... No. This is *not* a bug in the bridge, but one in their portlet container implementation. The method concerning this issue is o.a.p.bridges.util.PortletWindowUtils.getPortletWindowId(PortletSession) That method (which I wrote) is 100% following the JSR-168 specification, its just too bad JBoss Portal (and now it seems also Sun Portal) fail to follow those rules concerning this functionality. ... makes me wonder if they (now) share some common codebase ? ... Anyway, I know this is annoying and I could maybe fix this through a workaround (not sure yet though: this exception might indicate something more/worse is wrong, but I haven't debugged *their* engines yet). But... such a fix or workaround will take some time to formally land in a new release of bridges anyway, and maybe by that time this is moot if we have (basic) JSR-286 support in place for Wicket by then ... Are there plans to completely disconnect the Wicket portlet impl. from the bridge (i.e. including this dependency to ServletPortletSessionProxy)? Yes/no. JSR-286 support will no longer need/depend on the two ServletContextProvider and PortletResourceURLFactory implementations. Additionally, the ServletPortletSessionProxy functionality *might* be replaced by a native JSR-286 feature but... that is an optional feature of the spec, so it depends if the underlying portlet container does support it or not. If not, the ServletPortletSessionProxy (which provides exactly the same functionality as this optional feature... wonder how come?) will still be needed. But in that case, the part you encountered the exception in comes from determining the Portlet WindowId, and *that* is now also formally provided by JSR-286 and thus can be resolved in a JSR-286 native way too. HTH, Ate - Tor Iver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket portles in Sun Portal
I don't know the Sun Portal that well, but AFAIK they have (or are working on) beta Portlet API 2.0 (JSR-286) support already. As the interfaces which Wicket Portlet currently needs from Apache Portals Bridges Common are natively supported with JSR-286, the easiest solution is: a) waiting for JSR-286 to finally get published (it is already accepted, just still not made available publicly :( ) b) upgrade Wicket portlet support to (optionally, if JSR-286 is available at runtime) make use of the JSR-286 API's instead of the custom Bridges interfaces For b) I hope to get started on that ASAP. As I'm also working on a big upgrade/refactoring of both Pluto 2.0 and Jetspeed 2.2 to get them aligned, this is something I'll have to try to squeeze in sometime soon. *Any help with this is very much appreciated.* For a) I just hope the JCP will speed up their administrative handling of it. But, we don't have to wait for the public release of JSR-286 to start working on it. Pluto 2.0 (trunk development) as well as other portals do have (beta) JSR-286 support which can be used for developing and testing already. We only don't have a formal portlet-api-2.0.jar available from any public repository, which is somewhat painful as adding it as dependency on Wicket would break out-of-the-box building for everyone who hasn't installed that jar locally. That's the main reason (and lack of time of course) I haven't started on this already. Now, if you're stuck on a Portal which doesn't provide JSR-286 support any time soon, and neither provides implementations of those Bridges interfaces, you'll have to write them yourself I'm afraid. As the experience of Thijs Vonk with Liferay showed, it really depends on how open and flexible the core features of that portal engine is, and whether they already have similar (albeit still proprietary) support of these features. But if/once they do have preliminary (as Jetspeed right now) or real JSR-286 support, providing implementations for these interfaces should not be difficult. Regards, Ate Wilhelmsen Tor Iver wrote: We have (wisely :) ) chosen Wicket as web framework, but also chosen Sun Portal as the portal engine (not just Pluto but the commercial product). This causes a problem since Sun apparently haven't implemented the two interfaces required by Apache's bridge, so Wicket 1.3.x portlets do not work since the WicketPortlet appears to require the bridge. Are there anyone else who have used this combination successfully? As I see it, there are four possible solutions: 1) Provide implementations of the interfaces that hook into the Sun portlet engine 2) Make a custom WicketPortlet that does away with the bridge requirement and does all translation between the portlet world and the Wicket world. Has the disadvantage of effectively redoing work that the bridge already does 3) Make a custom Wicket Channel in the portlet server to (in effect) provide such a bridge (or wait for someone at Sun to write one :) ) which has the disadvantage of being tied to Sun's product 4) Serve the Wicket portlets from a second portlet container that _does_ support the bridge (Liferay, Jetspeed or JBoss if I am not mistaken), and use WSRP to show them in Sun's portal Which do you guys think is most likely to succeed? Med vennlig hilsen TOR IVER WILHELMSEN Senior systemutvikler Arrive AS T (+47) 48 16 06 18 E-post: [EMAIL PROTECTED] http://servicedesk.arrive.no - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Websphere Portal 6 + Wicket Portlet Experience
Fernando, I don't use Websphere Portal 6 (mainly Jetspeed-2), but I googled a bit for their support of the Apache Bridges SerlvetContextProvider and PortletResourceURLFactory functionality. It looks like it is now possible to use Websphere and Websphere Portal specific APIs to implement these interfaces. To support the ServletContextProvider, they have just released Fix Pack 13 for Websphere 6.1 which now provides an implementation [1]. LOL, finally someone got them to allow using the Struts Bridge I wrote 3 years ago besides their own Struts Bridge implementation ;) For the PortletResourceURLFactory, AFAIK there isn't formal (IBM) support for yet, but I think it should be possible to write an implementation yourself now by looking at the new Single Portlet Refresh API in Websphere Portal 6.0.1 [2] It will require some experimenting and coding yourself, but looking at the examples given it definitely seems doable. If you do manage to get this working, please keep us informed. Would be very nice to add Websphere Portal 6 (.0.1) to the list of supported portals. NB: As the JSR-286 and the RI at Pluto is nearing its completion [3,4], I plan to start working on formal JSR-286 compliant Wicket Portlet support real soon. Then none of these proprietary interfaces will be needed as JSR-286 supports these features natively. Regards, Ate [1] http://www-1.ibm.com/support/docview.wss?rs=180uid=swg1PK52044 [2] http://www.ibm.com/developerworks/websphere/library/techarticles/0712_behl/0712_behl.html?S_TACT=105AGX10S_CMP=LP [3] http://hnsp.inf-bb.uni-jena.de/spec/ (temporarily JSR-286 drafts) [4] http://svn.apache.org/viewvc/portals/pluto/branches/1.1-286-trunk-merge/ Martijn Dashorst wrote: Ate or Janne may be the ones to provide feedback. As it has been a vacation in the Netherlands, it may take a while for them to catch up. Martijn On Jan 7, 2008 12:13 PM, fapereira [EMAIL PROTECTED] wrote: Any feedback please? Thanks! fapereira wrote: Hello everyone, i'm currently research the best way to use framework that can do clean as possible development for normal web apps and portlets. What i understand the way that wicket do that, its using Apache Portals Bridges, but that require that the portal server implements the current interfaces bellow: a) Apache Portals Bridges ServletContextProvider interface b) Apache Portals Bridges PortletResourceURLFactory interface My problem here its the fact i use webfear, ops.. websphere application/portal 6.0. I want to know all kind of feedback related with the experience using wicket in this specific portal/version. Thanks very much for your attention. Best Regards, Fernando. -- View this message in context: http://www.nabble.com/Websphere-Portal-6-%2B-Wicket-Portlet-Experience-tp14597270p14663144.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thx everybody that attended the user group meeting in The Netherlands
Niels van Kampenhout wrote: Roy van Rijn wrote: Somebody answer this question please, I would love to see the Hippo presentation again :-) It was the best presentation I've seen in years, I learned something and had a good laugh with all the Lego and Hippo pictures. (see the IRC logs). Thanks! :-) But its a good question, where can we find the slides? I put our presentation on slideshare: http://www.slideshare.net/nielsvk/wicket-plugin-architecture Can the other speakers upload their slides too please? Niels http://www.slideshare.net/ate.douma/wicket-portlet-primer Ate - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ping2
Martijn Dashorst wrote: I only replied to you, I thought it would not benefit the community too much, replying to a message that is intended to be ignored :) LOL, so my webmail client isn't dumb after all: what a discovery ;) Hopefully this response will be last bit of this ignorable thread. If this one comes through, I know its the hotel wired network blocking my mail but I can send through the wireless network provided by ApacheCon itself ... Regards, Ate But this seems to work though. Martijn On 11/14/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I don't see anything coming by in moderation, so not sure what's wrong... (instead of replying only to Martijn sending this also to the list, stupid webmail client...) I suspect the wired internet connection at the hotel room here in Atlanta (ApacheCon US 2007) might be interfering. I'll try to send out a message later from the wireless network down at the Hackaton and see if that works. Right now it seems only webmail works :( Ate Martijn On 11/14/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Please ignore this test message. This is my 4th attempt to send a message to this list already since yesterday of which so far none has come through. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-rc1 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem deploying the app as portlet in Jetspeed
Hi Dipu, I do need the possible errors from jetspeed.log and maybe catalina.out to help. Without that, I really don't know what's going wrong and what has an initialization failure here. Ate Dipu Seminlal wrote: Hi all, I tried to deploy my application as portlet in jetspeed and it's complaining about Initialization failure I can't find anything useful in the logs I am using Jetspeed 2.1.2 and my app is build against the wicket trunk. I have given the following in my portlet.xml init-param nameServletContextProvider/name valueorg.apache.jetspeed.portlet.ServletContextProviderImpl/value /init-param init-param namePortletResourceURLFactory/name valueorg.apache.jetspeed.portlet.PortletResourceURLFactoryImpl/value /init-param and the following in web.xml servlet servlet-nameJetspeedContainer/servlet-name display-nameJetspeed Container/display-name descriptionMVC Servlet for Jetspeed Portlet Applications/description servlet-classorg.apache.jetspeed.container.JetspeedContainerServlet/servlet-class init-param param-namecontextName/param-name param-valueFAB/param-value /init-param load-on-startup100/load-on-startup /servlet servlet-mapping servlet-nameJetspeedContainer/servlet-name url-pattern/container/*/url-pattern /servlet-mapping has anyone seen this before ? Regards Dipu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Portlets in Liferay
Thijs wrote: I'm trying to get wicket portlets to work in Liferay. As fas as I can tell there are at least 2 issues at the moment: 1.) A nullpointer exception in WebResponse due to an issue in de Liferay code that returns null in the encodeRedirectUrl (see http://www.liferay.com/web/guest/community/forums/message_boards/message/249501 ) To answer a question on the liferay forum I need to know why the encodeRedirectUrl is called. I think this is because of the REDIRECT_TO_RENDER setting done by the WicketFilterPortletContext. But can somebody confirm that?! Hi Thijs, I've looked a bit deeper into this issue and it turned out that this is (or was) a JSR-168 conformance problem indeed. On Jetspeed-2 this didn't really cause any problems as we are more relaxed on this specific issue (in the end, redirects during rendering are not and will not ever be possible so allowing encoding doesn't hurt either). But clearly this needed to be resolved independently of Jetspeed, so I've created a new issue, https://issues.apache.org/jira/browse/WICKET-1155, as well as already resolved it :) Please do check if this now works for you too. 2.) https://issues.apache.org/jira/browse/WICKET-1132 I have no clue what causes this issue or where to look. Can somebody give me a push in the right direction? For this one, I really don't have a clue. You'll probably need a Liferay expert here as this goes into the internal url handling of the Liferay portlet container and is beyond Wicket itself. Regards, Ate - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket meetup (the netherlands) ideas
Johan Compagner wrote: The best man for this would be Ate ... Dont know if he can attend? I'll attend and definitely will do my best to answer any questions about the portlet support as much as I can. I haven't really planned a presentation yet, but if there is enough interest I guess I can come up with something ;) On 11/5/07, Thijs [EMAIL PROTECTED] wrote: It would be grate to get some more info on the portlet implementation. I've been trying to get that working on another portal server then Jetspeed without much luck :) Also a tips and tricks kinda thing would be great. To show some nice tricks to my employer and fellow colleges. I haven't been using Wicket professionally jet. I only used it to build my own blog with it. I'm trying to get my employer to look at Wicket but I need working portlet support for Liferay to get that done) :) About Liferay specifics, I'm willing to help of course but as I don't know much of its internals my knowledge is limited. What I can do is try to contact Brian Chan or Jorge Ferrer from Liferay directly who I know personally from our JSR-286 meetings. But that'll have to wait until after ApacheCon US next week as I really don't have time for anything else right now (besides supporting several custom portal projects). Please do ping me again if I don't follow up in 2 weeks time. Regards, Ate Eelco Hillenius wrote: we are already in the month of the great Wicket meetup in the netherlands So does anybody have idea's what you would like to see ? Do you want to see some short presentations? What would be good topics? This is your chance to do some practicing on presenting Johan! One idea that comes in mind is to let Arje or someone else from Hippo talk about how they plan to use Wicket (or are already doing so) and/ or have a talk on why and how to use portlets with Wicket. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Portlet howto
Charly wrote: Hello, I have the beginning of a solution ! Cool ! My code is based on Liferay's struts support with some adaptations. At this time, Guestbook portlet sample is ok, and I've made a modification in wicket to get Navomatic and other bookmarkablePage working. The main point is that Liferay want a new HttpServletRequest (from theirs object) in ServletContextProvider implementation of ServletContextProvider and we must copy the request's parameters from the original request to the new one. Weird, but I guess it is something Liferay specific. I translate also the _wu (WicketPortlet.WICKET_URL_PORTLET_PARAMETER) parameter into differents parameters Why? The WicketPortlet dispatches to the servlet/filter using this url, so the underlying web container (e.g. catalina) should already provide the query string parameters as request parameters (as required by the servlet spec). You can have a look to my 3 classes at the end of this mail. I notice that you don't set the provided Map portletArg arguments on the created PortletURLImpl in createResourceURL method. You probably should... I've got a problem for all bookmarkablePage, because the argument are encoded by Wicket, and Liferay encode it second time. Liferay shouldn't be doing that: you should get back the parameters previously set on a PortletURL exactly the same. Seems like a Liferay bug to me. The parameter received is like %3Aorg.apache.wicket.examples.navomatic.Page2. So I add a call to decode function from org.apache.wicket.protocol.http.RequestUtils Here is my code modification (it's maybe possible to find a another solution too) in the class org.apache.wicket.protocol.http.request.WebRequestCodingStrategy, method addBookmarkablePageParameters(final Request request, final RequestParameters parameters) (line : 521 / SVN revision : 585043) I change from final String[] components = Strings.split(requestString, Component.PATH_SEPARATOR); to final String[] components = Strings.split(RequestUtils.decode(requestString),Component.PATH_SEPARATOR); (Note: I test it with jetspeed and it works) The main remaining problem is about Ajax portlet. I have this Error : === 15:38:53,248 ERROR [[default]:731] Servlet.service() pour la servlet default a lancé une exception java.lang.NullPointerException at org.apache.wicket.protocol.http.WebResponse.redirect(WebResponse.java:204) at org.apache.wicket.protocol.http.BufferedWebResponse.close(BufferedWebResponse.java:66) Seems like a strange NPE to me. Looking at WebResponse.java:204, the only null reference in that code line could be the url string itself, but as the stacktrace indicates, the redirect is called from BufferedWebResponse.java:66 and there it only does that *if* the url != null. Can you further debug this? Ate - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Portlet howto
Thijs wrote: Hi (Ate?) Hi Thijs, Is there someone who could write a small wikipage on what I have to change in a Quickstart project to deploy it as a portlet? I can and will, and even promised to do so last week :( But I'm currently crammed with two new client (portal) projects put on my table last week as well as adding some finer integration for Wicket Header Contributions in Jetspeed before we release Jetspeed 2.1.3 hopefully somewhere next week (you can expect a few small. but transparent, changes to the Wicket Portlet support shortly). I'm trying to get the examples.war working on a liferay portal (liferay.com). But this is giving me so much trouble that I just want to work with an 'empty' quickstart. Because I'm not sure if it is Wicket that is giving me the headache's or Liferay (with their custom xml configs). :) To get you started, I'll give the important configuration (and portal runtime) settings/requirements inline here. These will eventually end up on a Wiki page, but I'm afraid I won't have time to write that before next week. First of all, you need to make sure the portal (Liferay in your case) provides an implementation of the Apache Portals Bridges PortletResourceURLFactory interface, see: http://portals.apache.org/bridges/multiproject/portals-bridges-common/xref/org/apache/portals/bridges/common/PortletResourceURLFactory.html The related jar containing this interface, portal-bridges-common-1.0.3.jar (available from repo1.maven.org) needs to be in your portlet classpath directly or provided in the shared classpath of your portal. You will have to check if your portal (Liferay) provides support for these kind of RenderURLs which allows direct access to a portlet and full control over its response (like setting content type etc.). A ResourceURL will be a standard JSR-286 (Portlet API 2.0) feature but as it isn't yet released (it will be soon) for which I created this temporary interface to allow using it in a JSR-186 container as well, as long as a portal provides a propetairy mapping for it. Jetspeed 2 does, and AFAIK, most other portals do as well, you just need to find out how to map this for Liferay and provide (or use) their proprietary api to handle it. Secondly, you need also to provide an implementation of the Apache Portals Bridges ServletContextProvider interface, see: http://portals.apache.org/bridges/multiproject/portals-bridges-common/xref/org/apache/portals/bridges/common/ServletContextProvider.html That I know Liferay already provides as I know it provides support for the Apache Portals Struts Bridge which uses the same interface. Note: this interface also is provided with the portal-bridges-common-1.0.3.jar (and earlier). BTW: this inteface also won't be needed anymore for proper JSR-286 containers. Once they are available I'll upgrade the Wicket Portlet support to really work out-of-the-box and portal specific configurations won't be needed then. The implementations of these two interfaces need to be provided to the WicketPortlet. There are three ways of doing that, the simplest is providing a WicketPortlet.properties file in the classpath under package org.apache.wicket.protocol.http.portlet. The one I provide with Jetspeed 2 (out-of-the-box through a shared library) contains the following: # Default Jetspeed-2 provided WicketPortlet ServletContextProvider and PortletResourceURLFactory org.apache.portals.bridges.common.ServletContextProvider=org.apache.jetspeed.portlet.ServletContextProviderImpl org.apache.portals.bridges.common.PortletResourceURLFactory=org.apache.jetspeed.portlet.PortletResourceURLFactoryImpl Another way of defining these (maybe easier for testing) is providing them as portlet init parameters (named ServletContextProvider and PortletResourceURLFactory) or even as web.xml context param using their full class name just as in the properties file. Defining these through WicketPortlet.properties though will allow you to keep this portal specific configuration out of your application and thus be more portable. Additionally, you will need to modify the wicket filter mapping in your web.xml to support handling both direct requests as well include dispatch requests, e.g. filter-mapping filter-nameAjaxApplication/filter-name url-pattern/ajax/*/url-pattern dispatcherREQUEST/dispatcher dispatcherINCLUDE/dispatcher /filter-mapping Note: this requires at least a Servlet 2.4 descriptor just as in the wicket-examples application. Finally, in your portlet.xml, you need to define a portlet init-param named wicketFilterPath with as value the url-pattern of your wicket application, but without the trailing /*, e.g.: portlet descriptionExamples using wicket's built-in AJAX./description portlet-nameAjaxApplication/portlet-name display-nameajax/display-name portlet-classorg.apache.wicket.protocol.http.portlet.WicketPortlet/portlet-class init-param
Re: Portlet howto
Gwyn Evans wrote: On Monday, October 8, 2007, 11:45:39 AM, Ate [EMAIL PROTECTED] wrote: To get you started, I'll give the important configuration (and portal runtime) settings/requirements inline here. These will eventually end up on a Wiki page, but I'm afraid I won't have time to write that before next week. http://cwiki.apache.org/WICKET/portal-howto.html :-) Nice ;) Thanks Gwyn /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Wicket Portlets Demo available
I'm even more happy to announce that Wicket Portlet Support has now been merged into the trunk and already will be part of the upcoming 1.3.0-beta4 release! In the next few days or hopefully latest end of next week, I'll add some documentation to the Wicket Wiki describing the portlet features, limitations, how to write portlet compliant Wicket applications and how to run them in a portal. For those already familiar with portlets and portals, check out the WICKET-647 and WICKET-658 issues which have some head start info. Regards, Ate Douma Ate Douma wrote: I'm really happy to announce that a new and quite feature complete Wicket Portlets Demo is now available for download at: http://people.apache.org/~ate/wicket/jetspeed-2.1.3-dev-wicket-demo-installer.jar I've worked hard the last few weeks to improve the Wicket portlet support branch and it can now run all Wicket Examples natively as portlet! See also IRA issue WICKET-658 at http://issues.apache.org/jira/browse/WICKET-658#action_12528082 where I have provided more information how to install and use this demo. Although there probably are still some minor issues here and there, the demo will show that portlet development using Wicket is now very much feasible. I'd like to invite anyone interested to try out the demo and see it in action for yourself, and of course please report any encountered issue/problems to the dev list. I've developed the portlet support based on the 1.3.0-beta3 release (with few minor bugfixes ported back from the trunk), so although the trunk development has progressed at it usual aggressive speed, updating the portlet-support to the latest Wicket trunk shouldn't be too much work (that is: right now!). As we would like to start using Wicket for a rewrite of the Jetspeed-2 administration portlets *now*, it would be great if the portlet support can be incorporated into the trunk as soon as possible. Delaying this until after the 1.3.0 release would mean being out-of-sync with the main wicket trunk development all the time and a lot of work each time we want/need to bring it back in sync. Initially, back in May this year, my idea was waiting with merging the portlet support in the trunk to after the 1.3.0 release. But as 1.3.0 still isn't released yet and still in beta phase, it would be much better to merge now otherwise the portlet-support will be constantly out-of-sync with the main wicket trunk development, causing a lot of effort each time we want (or need) to bring it back in sync. For Jetspeed-2, we would very much like to start using Wicket for a rewrite of the Jetspeed-2 administration portlet *now*. Having towait until after the 1.3.0 release, or be dependent on unofficial builds from the portlet-support branch would be less ideal to say the least. Other parties, like my own company, already have started using the Wicket portlet-support branch, so having to delay the merge to trunk really wouldn't be fun. AFAICS though, the impact of merging the portlet-support to trunk won't be big. I had to make a few (internal) changes in the wicket core, but I don't think those will have functional side-effects. To make it easier for the other committers to decide if we can merge the portlet-support to trunk now, I will create a new JIRA issue for it. For the changes needed to the current Wicket trunk I'll create separate patches with explanations why and attach those to that issue. (note: most of these changes I already described in detail under subtasks of the WICKET-647 issue). We can then discuss these changes individually and if need be see if alternative solutions are possible. After those changes are reviewed and accepted, the portlet support then can be merged to the trunk. WDYT? Regards, Ate - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Wicket Portlets Demo available
Dipu Seminlal wrote: Hi Ate, I'm interested in the portlet support which you have implemented in wicket. Cool! Any idea when it might be merged into the trunk? It is under discussion right now on the dev list. I've proposed to merge this into trunk now (before -beta4 release), but this hasn't been decided or voted upon yet. I do hope we can wrap this up quickly though. The discussion is somewhat split up over two different threads which you can view in context using nabble: [1] http://www.nabble.com/Please-review-WICKET-983%3A-Merge-the-portlet-support-branch-into-the-trunk-tf4470851.html [2] http://www.nabble.com/Re%3A--jira--Resolved%3A-%28WICKET-647%29-New-Wicket-Portlet-support-tf4467600.html Feel free to join those and let us know your opinion too :) Regards, Ate Regards Dipu On 9/17/07, Ate Douma [EMAIL PROTECTED] wrote: I'm really happy to announce that a new and quite feature complete Wicket Portlets Demo is now available for download at: http://people.apache.org/~ate/wicket/jetspeed-2.1.3-dev-wicket-demo-installer.jar I've worked hard the last few weeks to improve the Wicket portlet support branch and it can now run all Wicket Examples natively as portlet! See also IRA issue WICKET-658 at http://issues.apache.org/jira/browse/WICKET-658#action_12528082 where I have provided more information how to install and use this demo. Although there probably are still some minor issues here and there, the demo will show that portlet development using Wicket is now very much feasible. I'd like to invite anyone interested to try out the demo and see it in action for yourself, and of course please report any encountered issue/problems to the dev list. I've developed the portlet support based on the 1.3.0-beta3 release (with few minor bugfixes ported back from the trunk), so although the trunk development has progressed at it usual aggressive speed, updating the portlet-support to the latest Wicket trunk shouldn't be too much work (that is: right now!). As we would like to start using Wicket for a rewrite of the Jetspeed-2 administration portlets *now*, it would be great if the portlet support can be incorporated into the trunk as soon as possible. Delaying this until after the 1.3.0 release would mean being out-of-sync with the main wicket trunk development all the time and a lot of work each time we want/need to bring it back in sync. Initially, back in May this year, my idea was waiting with merging the portlet support in the trunk to after the 1.3.0 release. But as 1.3.0 still isn't released yet and still in beta phase, it would be much better to merge now otherwise the portlet-support will be constantly out-of-sync with the main wicket trunk development, causing a lot of effort each time we want (or need) to bring it back in sync. For Jetspeed-2, we would very much like to start using Wicket for a rewrite of the Jetspeed-2 administration portlet *now*. Having towait until after the 1.3.0 release, or be dependent on unofficial builds from the portlet-support branch would be less ideal to say the least. Other parties, like my own company, already have started using the Wicket portlet-support branch, so having to delay the merge to trunk really wouldn't be fun. AFAICS though, the impact of merging the portlet-support to trunk won't be big. I had to make a few (internal) changes in the wicket core, but I don't think those will have functional side-effects. To make it easier for the other committers to decide if we can merge the portlet-support to trunk now, I will create a new JIRA issue for it. For the changes needed to the current Wicket trunk I'll create separate patches with explanations why and attach those to that issue. (note: most of these changes I already described in detail under subtasks of the WICKET-647 issue). We can then discuss these changes individually and if need be see if alternative solutions are possible. After those changes are reviewed and accepted, the portlet support then can be merged to the trunk. WDYT? Regards, Ate - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Wicket Portlets Demo available
Eelco Hillenius wrote: WDYT? Good news Ate! I'm +1 for putting it in trunk if you take on the responsibility of maintaining it properly. Sure :) I'm pretty much involved in several projects which would like to use the Wicket portlet support, and of course if we manage to rewrite our Jetspeed-2 admin portlets in Wicket (for release 2.2) there will be a direct Apache connection too! So, you can be assured of my continued involvement and interest in this, and even without concrete projects at hand. But I will need support from all the Wicket committers for trying to maintain portlet compatibility as much as possible too! There aren't that many specific rules to follow, but certain things simply aren't allowed like modifying an url after it is generated (like from client side javascript). There are easy workaround/alternatives for that like using POST with hidden parameters instead of GET requests. Once we have portlet support in the branch as an officially supported feature, everyone should take these restrictions in mind. And of course, for very servlet specific features which make no sense in a portlet this won't apply. I plan to create a JIRA issue for merging to trunk later this evening or tomorrow and then you can all see concrete examples of what I mean by this. Many thanks for the positive responses so far already, Regards, Ate Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
New Wicket Portlets Demo available
I'm really happy to announce that a new and quite feature complete Wicket Portlets Demo is now available for download at: http://people.apache.org/~ate/wicket/jetspeed-2.1.3-dev-wicket-demo-installer.jar I've worked hard the last few weeks to improve the Wicket portlet support branch and it can now run all Wicket Examples natively as portlet! See also IRA issue WICKET-658 at http://issues.apache.org/jira/browse/WICKET-658#action_12528082 where I have provided more information how to install and use this demo. Although there probably are still some minor issues here and there, the demo will show that portlet development using Wicket is now very much feasible. I'd like to invite anyone interested to try out the demo and see it in action for yourself, and of course please report any encountered issue/problems to the dev list. I've developed the portlet support based on the 1.3.0-beta3 release (with few minor bugfixes ported back from the trunk), so although the trunk development has progressed at it usual aggressive speed, updating the portlet-support to the latest Wicket trunk shouldn't be too much work (that is: right now!). As we would like to start using Wicket for a rewrite of the Jetspeed-2 administration portlets *now*, it would be great if the portlet support can be incorporated into the trunk as soon as possible. Delaying this until after the 1.3.0 release would mean being out-of-sync with the main wicket trunk development all the time and a lot of work each time we want/need to bring it back in sync. Initially, back in May this year, my idea was waiting with merging the portlet support in the trunk to after the 1.3.0 release. But as 1.3.0 still isn't released yet and still in beta phase, it would be much better to merge now otherwise the portlet-support will be constantly out-of-sync with the main wicket trunk development, causing a lot of effort each time we want (or need) to bring it back in sync. For Jetspeed-2, we would very much like to start using Wicket for a rewrite of the Jetspeed-2 administration portlet *now*. Having towait until after the 1.3.0 release, or be dependent on unofficial builds from the portlet-support branch would be less ideal to say the least. Other parties, like my own company, already have started using the Wicket portlet-support branch, so having to delay the merge to trunk really wouldn't be fun. AFAICS though, the impact of merging the portlet-support to trunk won't be big. I had to make a few (internal) changes in the wicket core, but I don't think those will have functional side-effects. To make it easier for the other committers to decide if we can merge the portlet-support to trunk now, I will create a new JIRA issue for it. For the changes needed to the current Wicket trunk I'll create separate patches with explanations why and attach those to that issue. (note: most of these changes I already described in detail under subtasks of the WICKET-647 issue). We can then discuss these changes individually and if need be see if alternative solutions are possible. After those changes are reviewed and accepted, the portlet support then can be merged to the trunk. WDYT? Regards, Ate - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
