This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Transferred from the woodstock to vwp for investigation. The Woodstock issue can be found here: https://woodstock.dev.java.net/issues/show_bug.cgi?id=1168 It is not clear that this is a Woodstock bug as all references made by the submitter refer to NB6.0 vs 6.1. There was an effort to add portlet support into NB 6.1 so it would be good for the VWP team to review this issue as there haven't been any changes to the Woodstock components that should affect portlets in NB6.1. Bug Details: ============ Visual JSF components are not displayed properly in Portlet environment when there are multiple jsf portlets in the same portal page. This was working with NetBeans 6.0 but is not working with NetBeans 6.1 Beta. Steps to reproduce : 1. Install NetBeans 6.1 Beta 2. Install Portal Pack plugins from http://portalpack.netbeans.org/nb6/download.html - Download portal pack 2.0 Beta 3 zip file and install all nbms inside that zip. - Download visual portlet builder nbm and install it. 3. Start NetBeans 6.1 4. Create a Web Application 5. On the web application Right Click > New > Visual Web JSF Portlet Page 6. Design your portlet application and create a war 7. Deploy the war on Portlet Container RC2 which is available at https://portlet-container.dev.java.net/public/Download.html 8. Verify the deployed portlet at http://localhost:[port]/portletdriver/ is displayed properly 9. Create/Deploy another portlet web application using step 4-7 10. Now go to the same url http://localhost:[port]/portletdriver/ You will notice that first portlet is not displayed properly. Only the second one is displayed properly. Note: If the same steps are repeated on NetBeans 6.0 both the portlets are visible and behave properly. This is a stopper for us as visual web components in NB 6.1 cannot be used as portlets. ------- Additional comments from camucci Tue Apr 8 17:37:29 +0000 2008 ------- I am trying to reproduce your test steps and have a few questions. 1. Were there any exceptions thrown in the Glassfish/Portlet Container, or NetBeans Logs that can help us further debug this issue for you? Please send any log details relevant to this issue. 2. What did you select for Frameworks when creating this project? Did you select both Portlet Support and Visual Web Java Server Faces? If you chose Portlet Support, did you accept all the defaults? 3. I could not locate any specific instructions on how to deploy to the Portlet Container RC2, can you please provide specific instructions, if any. ------- Additional comments from ranjansatya Tue Apr 8 18:52:40 +0000 2008 ------- Please find my responses for your questions 1. Were there any exceptions thrown in the Glassfish/Portlet Container, or NetBeans Logs that can help us further debug this issue for you? Please send any log details relevant to this issue. Ans: I didn't find any exception in Glassfish/NetBeans log specific to woodstock. 2. What did you select for Frameworks when creating this project? Did you select both Portlet Support and Visual Web Java Server Faces? If you chose Portlet Support, did you accept all the defaults? Ans: You don't need to select any framework. Just create a simple web app and then create visual portlet inside your webapp. While creating a Visual Web JSF Portlet page, the visual web framework is added automatically. 3. I could not locate any specific instructions on how to deploy to the Portlet Container RC2, can you please provide specific instructions, if any. Ans: The steps to install Portlet Container on Glassfish can be found at https://portlet-container.dev.java.net/public/Download.html After installing Portlet Container, restart your glassfish server. -Then hit http://localhost:port/portletdriver/ to see the portlet container page. -You can see a admin tab in the portlet container page. Go to admin tab. There is an option to deploy a war file. Alternately, - You can configure a portlet container instance inside NB. To configure Portlet Container in NB 1. Go to Tools > Servers 2. Add Portlet Container 2.0 instance - Then select your project's runtime as Portlet Container 2.0 instance. - Right click on the project and select "Undeploy and Deploy" - ------- Additional comments from camucci Wed Apr 9 12:16:41 +0000 2008 ------- I was able to reproduce the submitters issue - and noticed that there were portlet exceptions thrown in the glassfish domain log that can hopefully help identify the issues with the portlet. My two NB VWP Portlet Apps were very simply - contained only a Woodstock label and textfield. The first portlet app displayed fine inside of the portlet container driver, yet when the second war was deployed, both are displayed as blank portlets. Both portlet 'containers' are visible, but no label/text, etc. Clearing the cache or shift-reload has no affect. As I noted above, there were exceptions in the glassfish server.log. These exeptions would indicate to me that this is not a woodstock problem. I'd like the developer to review this entry and add comments if possible. Here's the exception seen in the <gf>/domains/domain1/logs/server.log: [#|2008-04-09T08:11:30.328-0400|WARNING|sun-appserver9.1|debug.com.sun.portal.portletcontainer.invoker|_ThreadID=22;_ThreadName=httpSSLWorkerThread-8080-1;bug1168_portlets.VisualWebJSF;_RequestID=8afd4a7d-9cc7-4bdb-a058-b74607b15cbc;|PSPL_PCCTXCSPPCI0006 : Exception thrown while rendering content for portlet window bug1168_portlets.VisualWebJSF. com.sun.portal.container.ContainerException: PortletContainer.getMarkup():getting content java.io.FileNotFoundException: /servlet/PortletAppEngineServlet at com.sun.portal.portletcontainer.impl.PortletContainer.getMarkup(PortletContainer.java:259) at com.sun.portal.portletcontainer.invoker.WindowInvoker.getPortletContent(WindowInvoker.java:322) at com.sun.portal.portletcontainer.invoker.WindowInvoker.render(WindowInvoker.java:242) at com.sun.portal.portletcontainer.driver.PortletContent.getContent(PortletContent.java:68) at com.sun.portal.portletcontainer.driver.DesktopServlet.getPortletContents(DesktopServlet.java:295) at com.sun.portal.portletcontainer.driver.DesktopServlet.getAllPortletContents(DesktopServlet.java:241) at com.sun.portal.portletcontainer.driver.DesktopServlet.doGetPost(DesktopServlet.java:134) at com.sun.portal.portletcontainer.driver.DesktopServlet.doGet(DesktopServlet.java:88) at javax.servlet.http.HttpServlet.service(HttpServlet.java:718) at javax.servlet.http.HttpServlet.service(HttpServlet.java:831) at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:317) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:390) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:288) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214) at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265) at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106) java.io.FileNotFoundException: /servlet/PortletAppEngineServlet at org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:732) at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:384) at javax.servlet.http.HttpServlet.service(HttpServlet.java:718) at javax.servlet.http.HttpServlet.service(HttpServlet.java:831) at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411) at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:855) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:703) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:660) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:578) at com.sun.portal.portletcontainer.impl.PortletContainer.invokePAE(PortletContainer.java:790) at com.sun.portal.portletcontainer.impl.PortletContainer.invokePAE(PortletContainer.java:673) at com.sun.portal.portletcontainer.impl.PortletContainer.getMarkup(PortletContainer.java:209) at com.sun.portal.portletcontainer.invoker.WindowInvoker.getPortletContent(WindowInvoker.java:322) at com.sun.portal.portletcontainer.invoker.WindowInvoker.render(WindowInvoker.java:242) at com.sun.portal.portletcontainer.driver.PortletContent.getContent(PortletContent.java:68) at com.sun.portal.portletcontainer.driver.DesktopServlet.getPortletContents(DesktopServlet.java:295) at com.sun.portal.portletcontainer.driver.DesktopServlet.getAllPortletContents(DesktopServlet.java:241) at com.sun.portal.portletcontainer.driver.DesktopServlet.doGetPost(DesktopServlet.java:134) at com.sun.portal.portletcontainer.driver.DesktopServlet.doGet(DesktopServlet.java:88) at javax.servlet.http.HttpServlet.service(HttpServlet.java:718) at javax.servlet.http.HttpServlet.service(HttpServlet.java:831) at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:317) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:390) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:288) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214) at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265) at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106) ------- Additional comments from camucci Wed Apr 9 12:35:35 +0000 2008 ------- Marking as invalid. This is not a woodstock bug. ------- Additional comments from camucci Wed Apr 9 12:41:35 +0000 2008 ------- Filed https://glassfish.dev.java.net/issues/show_bug.cgi?id=4702 ------- Additional comments from ranjansatya Wed Apr 9 12:50:26 +0000 2008 ------- Sometimes after you deploy the portlet, if you click on the portlets tab you see this exception. This is because portlet is getting deployed. This exception is not related to this bug and it happens only once during portlet deployment. Now you can tail the logs and do the following : 1. Remove any portlet window by clicking 'X'. 2. Now you will see that the other portlet is showing content. 3. Now click on Admin tab. Then under "Modify portlet window" section make the portlet channel that you have removed in [1] as visible. 4. Now go "Portlets" tab. Now you will see that both the portlet are not showing content properly. In all of the above steps you won't be able to see any exception. If you do all these steps with NetBeans 6.0, everything works fine as expected. Hence we think it's a regression and should be fixed in NetBeans 6.1 ------- Additional comments from ranjansatya Wed Apr 9 12:54:27 +0000 2008 ------- As explained above this works with NetBeans 6.0 with the same glassfish and PC version but not in NetBeans 6.1 Beta. Hence reopening this bug.
Just small question:Why do you suppose PortalPack for 6.0/6.0.1 will work in 6.1, if they're for 6.0/6.0.1 only??? This should be an enhancement, not a bug, because in 6.0/6.0.1 everything's fine.
I have forwarded these comments made by dkolar@netbeans.org to the original submitter hoping for a response.
We have already tried Portal Pack 2.0 build for NB 6.1 and the result is same. As Portal Pack 2.0 binaries are not publicly available, we asked to use Portal Pack 2.0 Beta 3 version with NetBeans 6.1. fyi, visual portlet builder in portal pack 2.0 beta 3 is also compatible with NB 6.1
Visual Web actually does not have anything to do here; 1. the JSF Portlet support does is to extend the JSF classpath, which is frozen from 6.0 to 6.1. 2. the JSF Portlet invokes Visual Web designer, which is only for Design time, not related to Deployment. I.e., all the support directly from Visual Web is only for Design time. Satya, could you please compare the project contents that were created by both 6.0 and 6.1? If they are identical, then we can limit our further investigation into the deployment environment: Server and JSF/Portlet support libraries. Thanks!
I mean, comparing the contents of projects created by 6.0 and 6.1 should give us more clue what's wrong.
Here are the jsp code snippet for same jsf portlet page (same components) in NetBeans 6.0 & NetBeans 6.1 In NetBeans 6.0 ---------------- <webuijsf:form binding="#{PortletPage1.form1}" id="form1"> <webuijsf:label binding="#{PortletPage1.label1}" id="label1" style="position: absolute; left: 48px; top: 48px" text="Label"/> <webuijsf:textField binding="#{PortletPage1.textField1}" id="textField1" style="position: absolute; left: 120px; top: 48px"/> </webuijsf:form> In NetBeans 6.1 ----------------- <webuijsf:form binding="#{PortletPage1.form1}" id="form1"> <webuijsf:label id="label1" style="position: absolute; left: 48px; top: 48px" text="Label"/> <webuijsf:textField id="textField1" style="position: absolute; left: 120px; top: 48px"/> </webuijsf:form> The only difference I could see between these two is, there is a "binding" attribute for webuijsf:label and webuijsf:textField in NetBeans 6.0 but there is no binding attribute in the NetBeans 6.1 generated code.
This bug is very critical to Visual portlet builder feature as no two jsf portlets can be deployed on the same portal page, which is a very common usecase for a portlet development.
> The only difference I could see between these two is, there is a "binding" attribute for webuijsf:label and webuijsf:textField in NetBeans 6.0 but there is no binding attribute in the NetBeans 6.1 generated code. Yes, Visual Web insync now does not default generate codes for "binding" in NetBeans 6.1. Does portlet container depend on this? To confirm, do you use the same server for testing these 2 projects? if you manually add this "binding" in your 6.1 project, will that work after?
Upgrading it to P1. This is a regression and it used to work in NB6.0
It's not a deployment server issue; insync generates different codes from 6.0 to 6.1. Is that possible insync continue generating "binding" for portlet page; if the answer from Satya is Yes that the portlet container does need this binding.
Satya, Few questions for you. - when you say that the deployment environment is the same, are the Glassfish, Porlet Container versions the same ? - Visual JSF Portlet does not support multiple portlets at design time. So if single portlet works fine, multiple portlets fail, then I am wondering how can this be a NetBeans issue because this is not something one can even do at design time. Satya or woodstock team, Have you tested multiple portlets with woodstock components outside the visual JSF environment. That might give some clues on whether the problem lies. I would be very surprised if binding attribute is the cause this issue, but I could be wrong.
another point to note is there has been many changes from woodstock 4.1.1 to Woodstock 4.2. So its very important to make sure woodstock components work in a multiple portlet scenario outside the visual JSF environment. thanks
The bindings are not generated is the feature we implemented in NetBeans 6.1 for performance reasons. See: http://wiki.netbeans.org/OnDemandBindingAttribute If the user wants the bindings there is an action in the component pop up menu called Add Binding Attribute which can be used to do that. The Project code could use a different set of templates to create pages if they need to start with binding attributes. However when the user drags and drops components on the page they will still not get binding attribute by default. They will have to still add it. Also we need to prove that missing binding attribute is the cause of the failure.
There is nothing here related to 'project'.
I tried adding binding properties to all components in jsf portlet page as suggested by Sandip. But the result was same. I could not see the components in the browser. So I think the missing binding attribute is not the cause for this issue. But while loading the portal page in browser I could see some javascript error related to webui. Error: webui_suntheme4_2.djConfig has no properties http://localhost:8080/Test/theme/com/sun/webui/jsf/suntheme4_2-080320/javascript/bootstrap.js I still feel it's an issue with woodstock runtime library.
Jayashri, Here is my response to your questions Q: when you say that the deployment environment is the same, are the Glassfish, Porlet Container versions the same ? Ans: Yes I am testing with the same glassfish and Portlet Container version. Q: Visual JSF Portlet does not support multiple portlets at design time. So if single portlet works fine, multiple portlets fail, then I am wondering how can this be a NetBeans issue because this is not something one can even do at design time. Ans: I also feel the same.
I am using Netbeans 6.1 RC1, have installed the Portal Pack plugins OK (Step 2), but getting an error trying to install the Visual Portlet Builder NBM. The error is : "Missing required modules for Plugin Visual Web JSF Portlet Support: module org.netbeans.modules.portalpack.jsfportletbridge >1.0" Do we not want to use 6.1 RC1? Anyone know how to work around this?
This regression is not for 6.1, it's for 6.0.1! I can reproduce this issue on 6.0.1. I'm using exactly the same GlassFish server, and the same Portlet container. All of the JSP/Java/XML project files are identical from both 6.0 and 6.0.1. The only difference inside the projects and their WAR files are all coming from the component libraries. The list of these different files are: appbase.jar dataprovider.jar dojo-0.9.0.jar - dojo-1.0.1.jar errorhandler.jar jsfcl.jar json-2.jar prototype-1.5.0.jar sqlx.jar webui-jsf-suntheme.jar webui-jsf.jar I.e., not related to how the project text files are created and generated. (insync is free to go) I will check which set of jar files are the cause.
Please note that woodstock libraries were migrated from 4.1 to 4.1.1 in 6.0.1. Dojo libraries were upgraded as well. Cathy, did you test woodstock 4.1.1 in portlet environment ? Thanks
Satya, I remember that we did have similar issue for multiple portlet deployment for 6.0 and resolved by adding <p:portletPage> into the Page file. Is that possible the portlet bridge is not compatible with the new woodstock library and needs update?
There was some portlet testing done in the 4.x timeframe. But, I was not part of that effort, Krys. I'll update this bug again with any info I can dig up.
<p:portletPage> was added to provide namespace for all jsf components in a portal page to avoid conflicts between the components name.
>"Missing required modules for Plugin Visual Web JSF Portlet Support: >module org.netbeans.modules.portalpack.jsfportletbridge >1.0" >Do we not want to use 6.1 RC1? Anyone know how to work around this? You need to install JSF Portlet Bridge library which is available at http://portalpack.netbeans.org/nb6/download.html
Under 6.0.1 IDE, I have 2 'non-working' portlet projects with new 6.0.1 woodstock libraries. After I replaced the following jar files with the old 6.0 woodstock libraries, then they are now both working! dojo-0.9.0.jar -> dojo-1.0.1.jar json-2.jar prototype-1.5.0.jar webui-jsf-suntheme.jar webui-jsf.jar I think either the new woodstock libraries are not working with the portlet container, or the JSF Bridge needs to update for the new woodstock library.
FWIW: I tested with Netbeans 6.1 RC1 (got the bridge installed, thanks Satya) and used the 2.0 RC2 Container. I see a problem wherein when two test portlets are uploaded, both are blank. However, alone I can load each and view Woodstock components. When both are loaded, Firefox Firebug reported error "webui_suntheme4_2.djConfig has no properties".
Also if you minimize one portlet window, when there are two portlets deployed on the portlet container, you can see the output of the other one without any javascript error mentioned in the previous message. The moment you try to display both portlets it fails with the javascript error and the java script is error is specific to webui so again woodstock. FYI, JSF portlet bridge is working fine with multiple jsf portlets which don't use woodstock components.
According to several investigation from various people, looks like the woodstock 4.1.1 and/or the webui_suntheme is not fully working here.
Po-Ting, I think for better attention from Woodstock team, we should transfer this issue to Woodstock issuezilla and close this issue. What do you think?
See the first line of this issue, yes, we may just close this one and return it back to Woodstock issue. > Transferred from the woodstock to vwp for investigation. The Woodstock issue can be found here: > https://woodstock.dev.java.net/issues/show_bug.cgi?id=1168 Unless we want to keep track here.
I think we had better keep track of this issue. I will take this issue and monitor the Woodstock one. But I will change this one to missing FEATURE; not possible for multiple-portlet deployment.
We have to leave this as a defect because this scenario used to work before. Lets leave this open unless there is more info from woodstock team. We'll decide how to deal with this issue on monday.
I was able to recreate the problem described in the bug report I could not use Visual Pack for Portlets at all, as it was failing on me, but I modified my original portlet project I prepared for the blog ( independent of VWP) and recreated the problem. The actual cause is not pinned down exactly yet, but it has to do something with the deferred loading of widgets in Woodstock. Thus the following workaround works: Workaround: When parseOnLoad is set to false, multiple portlets display ok. ( see attached ) Example: <webuijsf:themeLinks id="themeId" webuiAll="true" parseOnLoad="false"/> Since workaround exists, this issue priority can be downgraded.
Created attachment 60185 [details] 2 instances of portlets on the same page
Downgrade to P2 since the workaround exists. Anyway, we should deliver the fix as the patch.
Thanks a lot Dmitry for the workaround. I tried the workaround and I can see multiple portlets now. For now we will change the jsf template generated by Visual portlet builder to automate this workaround.
I believe I found the cause of the problem. please see for further update on this issue: https://woodstock.dev.java.net/issues/show_bug.cgi?id=1168
From woodstock issue: > fixed in 4.3. > > For earlier versions, please use completely functional workaround provided above. The workaround for NetBeans release is already in the Portal Pack module.