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.

Bug 132409 - Visual Web Components in NB 6.0.1 cannot be used in Portlet environment
Summary: Visual Web Components in NB 6.0.1 cannot be used in Portlet environment
Status: RESOLVED FIXED
Alias: None
Product: obsolete
Classification: Unclassified
Component: visualweb (show other bugs)
Version: 6.x
Hardware: Sun All
: P2 blocker (vote)
Assignee: _ potingwu
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-09 14:37 UTC by camucci
Modified: 2008-04-25 13:12 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
2 instances of portlets on the same page (13.72 KB, image/png)
2008-04-15 07:37 UTC, dkushner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description camucci 2008-04-09 14:37:43 UTC
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.
Comment 1 Dan Kolar 2008-04-09 15:02:59 UTC
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.
Comment 2 camucci 2008-04-09 15:37:39 UTC
I have forwarded these comments made by dkolar@netbeans.org to the original submitter hoping for a response.
Comment 3 Satyaranjan D 2008-04-09 15:58:27 UTC
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
 
Comment 4 _ potingwu 2008-04-09 16:52:31 UTC
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!
Comment 5 _ potingwu 2008-04-09 16:54:32 UTC
I mean, comparing the contents of projects created by 6.0 and 6.1 should give us more clue what's wrong.
Comment 6 Satyaranjan D 2008-04-10 19:49:08 UTC
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.

Comment 7 Satyaranjan D 2008-04-10 19:56:13 UTC
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.
Comment 8 _ potingwu 2008-04-10 20:10:59 UTC
> 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?
Comment 9 dgothe 2008-04-10 20:14:34 UTC
Upgrading it to P1. This is a regression and it used to work in NB6.0
Comment 10 _ potingwu 2008-04-10 20:25:50 UTC
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.
Comment 11 Jayashri Visvanathan 2008-04-10 20:40:37 UTC
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.
Comment 12 Jayashri Visvanathan 2008-04-10 20:47:10 UTC
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
Comment 13 _ sandipchitale 2008-04-11 02:05:06 UTC
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.
Comment 14 _ potingwu 2008-04-11 05:14:47 UTC
There is nothing here related to 'project'.
Comment 15 Satyaranjan D 2008-04-11 10:28:03 UTC
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.
Comment 16 Satyaranjan D 2008-04-11 10:33:24 UTC
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.
Comment 17 _ krystyna 2008-04-11 18:57:17 UTC
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?
Comment 18 _ potingwu 2008-04-11 19:13:12 UTC
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.
Comment 19 Jayashri Visvanathan 2008-04-11 19:20:02 UTC
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
Comment 20 _ potingwu 2008-04-11 19:20:59 UTC
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?
Comment 21 camucci 2008-04-11 19:27:14 UTC
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. 
Comment 22 Satyaranjan D 2008-04-11 19:37:43 UTC
<p:portletPage> was added to provide namespace for all jsf components in a portal page to avoid conflicts between the
components name. 
Comment 23 Satyaranjan D 2008-04-11 19:42:19 UTC
>"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
Comment 24 _ potingwu 2008-04-11 20:24:56 UTC
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.
Comment 25 _ krystyna 2008-04-11 23:42:29 UTC
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". 
Comment 26 Satyaranjan D 2008-04-12 05:20:05 UTC
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.
Comment 27 _ potingwu 2008-04-12 17:14:33 UTC
According to several investigation from various people, looks like the woodstock 4.1.1 and/or the webui_suntheme is not
fully working here.
Comment 28 Winston Prakash 2008-04-12 17:50:23 UTC
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?
Comment 29 _ potingwu 2008-04-12 17:56:38 UTC
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.
Comment 30 _ potingwu 2008-04-12 18:11:13 UTC
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.
Comment 31 Jayashri Visvanathan 2008-04-12 20:58:09 UTC
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.
Comment 32 dkushner 2008-04-15 07:36:00 UTC
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.

Comment 33 dkushner 2008-04-15 07:37:45 UTC
Created attachment 60185 [details]
2 instances of portlets on the same page
Comment 34 Petr Blaha 2008-04-15 10:26:35 UTC
Downgrade to P2 since the workaround exists. Anyway, we should deliver the fix as the patch.
Comment 35 Satyaranjan D 2008-04-15 12:56:26 UTC
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.
Comment 36 dkushner 2008-04-16 04:15:14 UTC
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
Comment 37 _ potingwu 2008-04-17 19:54:12 UTC
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.