Duplicate Id problem with panelNavigation2

2009-01-02 Thread Kai Wiemer
Hello together,
I've got a problem concerning duplicated ids with tomahawks's
panelNavigation2. My current configuration is tomahawk-1.1.8 and
myfaces-1.2.5. Ok, here's the jsp:

<%...@taglib uri="http://java.sun.com/jsf/core"; prefix="f"%>
<%...@taglib uri="http://java.sun.com/jsf/html"; prefix="h"%>
<%...@taglib uri="http://java.sun.com/jsp/jstl/core"; prefix="c"%>
<%...@taglib uri="http://myfaces.apache.org/tomahawk"; prefix="t"%>
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>

  http://www.w3.org/1999/xhtml";>
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  


Now the web.xml:


http://www.w3.org/2001/XMLSchema-instance";
xmlns="http://java.sun.com/xml/ns/javaee";
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd";
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd";
id="WebApp_ID" version="2.5">
Keineahnung

index.html
index.htm
index.jsp
default.html
default.htm
default.jsp


Faces Servlet
javax.faces.webapp.FacesServlet
1


Faces Servlet
*.jsf


javax.faces.STATE_SAVING_METHOD
client


 

MyFacesExtensionsFilter
org.apache.myfaces.webapp.filter.ExtensionsFilter


uploadMaxFileSize
10m


uploadThresholdSize
50k


uploadRepositoryPath
/tmp



MyFacesExtensionsFilter
*.jsf


MyFacesExtensionsFilter
/faces/myFacesExtensionResource/*

  


faces-config.xml is empty and finally the errormessage i receive when
clicking on save button (maybe html is more comfprtable?
http://www.grafik-und-text.de/files/error.html):

Client-id : j_id_jsp_1037428323_3_j_id_jsp_1037428323_4_item0 is
duplicated in the faces tree. Component :
j_id_jsp_1037428323_3_j_id_jsp_1037428323_4_item0, path:
{Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
/duplicatedId.jsp][Class: org.apache.myfaces.custom.div.Div,Id:
navigation][Class: org.apache.myfaces.custom.div.Div,Id:
navigation-inside][Class: javax.faces.component.html.HtmlForm,Id:
j_id_jsp_1037428323_3][Class:
org.apache.myfaces.custom.navmenu.htmlnavmenu.HtmlPanelNavigationMenu,Id:
j_id_jsp_1037428323_4][Class:
org.apache.myfaces.custom.navmenu.htmlnavmenu.HtmlCommandNavigationItem,Id:
j_id_jsp_1037428323_3_j_id_jsp_1037428323_4_item0]}

Caused by:
java.lang.IllegalStateException - Client-id :
j_id_jsp_1037428323_3_j_id_jsp_1037428323_4_item0 is duplicated in the
faces tree. Component :
j_id_jsp_1037428323_3_j_id_jsp_1037428323_4_item0, path:
{Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
/duplicatedId.jsp][Class: org.apache.myfaces.custom.div.Div,Id:
navigation][Class: org.apache.myfaces.custom.div.Div,Id:
navigation-inside][Class: javax.faces.component.html.HtmlForm,Id:
j_id_jsp_1037428323_3][Class:
org.apache.myfaces.custom.navmenu.htmlnavmenu.HtmlPanelNavigationMenu,Id:
j_id_jsp_1037428323_4][Class:
org.apache.myfaces.custom.navmenu.htmlnavmenu.HtmlCommandNavigationItem,Id:
j_id_jsp_1037428323_3_j_id_jsp_1037428323_4_item0]}


java.lang.IllegalStateException: Client-id :
j_id_jsp_1037428323_3_j_id_jsp_1037428323_4_item0 is duplicated in the
faces tree. Component :
j_id_jsp_1037428323_3_j_id_jsp_1037428323_4_item0, path:
{Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
/duplicatedId.jsp][Class: org.apache.myfaces.custom.div.Div,Id:
navigation][Class: org.apache.myfaces.custom.div.Div,Id:
navigation-inside][Class: javax.faces.component.html.HtmlForm,Id:
j_id_jsp_1037428323_3][Class:
org.apache.myfaces.custom.navmenu.htmlnavmenu.HtmlPanelNavigationMenu,Id:
j_id_jsp_1037428323_4][Class:
org.apache.myfaces.custom.navmenu.htmlnavmenu.HtmlCommandNavigationItem,Id:
j_id_jsp_1037428323_3_j_id_jsp_1037428323_4_item0]}
  at 
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:419)
  at 
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:431)
  at 
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:431)
  at 
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:431)
  at 
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:431)
  at 
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:431)
  at 
org.apache.myfaces.application.jsp.JspStateManagerImpl.saveSerializedView(JspStateManagerImpl.java:372)
  at javax.faces.application.StateManager.saveView(StateManag

RE: [Trinidad] Problem with upgrade to 1.2.x

2009-01-02 Thread Bertrand, Shawn R
Thanks, Stephen.  I did actually realize jsp-api.jar had it, and including that 
jar fixed the problem.  My app is almost working now, if it wasn't for the 
failure of the table to stamp its rows correctly.  It just repeats the binding 
name itself in each cell.  Might be that I don't have all the right JARs in my 
app quite yet.

Thanks for the suggestion,

Shawn


-Original Message-
From: Stephen Friedrich [mailto:trini...@eekboom.com]
Sent: Tuesday, December 30, 2008 5:07 AM
To: MyFaces Discussion
Subject: Re: [Trinidad] Problem with upgrade to 1.2.x

I guess you are using facelets instead of jsp, right?
Sounds similar to TRINIDAD-1215: 
https://issues.apache.org/jira/browse/TRINIDAD-1215
Before that one was fixed my workaround was to simply include jsp-api.jar (that 
contains the JspIdConsumer) with my war.
You might want to try that too, plus maybe create a new issue in Jira.

Bertrand, Shawn R wrote:
> I'm migrating my app from 1.0.2 to 1.2.10 (along with JBoss 4.0.5 to
> 4.2.3 and everything that goes with it, including of course JSF 1.2),
> and I've made all the code changes and such related to
> Bindings->Expressions...
>
>
>
> But I'm running into a problem with a custom component I've subclassed
> from CorePanelGroupLayout.  It keeps wanting to import
> JspIdConsumer.class, which I can't seem to find.
>
>
>
> At the end of the day, I just want to extend tr:panelGroupLayout to
> support an "onscroll" attribute.  What is the right way to do that in
> Trinidad 1.2.x?
>
>
>
> Thanks in advance,
>
>
>
> Shawn
>
>
>



Re: using orchestra with jsf

2009-01-02 Thread Simon Kitching
sarathmavilla schrieb:
> Simon Kitching wrote:
>   
>> Hi Sarath,
>>
>> On Wed, 2008-12-31 at 02:46 -0800, sarathmavilla wrote:
>> 
>>> hi,
>>> iam new to myfaces orchestra and i dont know how to use it in my
>>> application.
>>> i search for samples of conversations, but i cant get it.
>>> can u please give the samples how to use conversation in jsf application
>>> with parent child conversations used in popup windows and tab windows.
>>>
>>> i tried using beans with our own conversation scope.but i cant get the
>>> values from popup windows to my main window.
>>>
>>> where can i get the samples for this whole.
>>>   
>> The "examples" module is listed on the orchestra website:
>> http://myfaces.apache.org/orchestra/myfaces-orchestra-examples-project/index.html
>>
>> There isn't much description there, but the "source repository" link
>> points to here:
>>   http://svn.apache.org/repos/asf/myfaces/orchestra/trunk/examples/
>> from where you can download some examples.
>>
>> As far as I remember, there aren't any examples dealing with multiple
>> windows though.
>>
>> When a new window (or browser tab) is opened, you need to make sure that
>> the URL does NOT contain a "conversationContext" query parameter; the
>> o:separateConversationContext tag can help with this.
>>
>> The new window then runs in its own ConversationContext, ie it cannot
>> access any of the conversation-scoped variables from the original
>> window. Having two separate windows accessing the same conversation data
>> has such nasty consequences that it is just better to avoid this
>> completely.
>>
>> So if you need to pass data "back" to the original conversation somehow,
>> then you need to do it using some way other than modifying objects in
>> conversation-scope. The way I usually do it is the old-fashioned
>> approach of storing data as query-params in the URL.
>>
>> Regards,
>> Simon
>>
>>
>>
>>
>>
>> 
> Hi Simon,
>
> thnks for responding.
> Can u tell me the simple way to get an existing bean in conversation ???
>   

I'm not quite sure what you are asking here. Can you explain your
question more?

Regards, Simon



Re: Possible Leak in MyFaces Orchestrea

2009-01-02 Thread Simon Kitching
Hi Steve,

I've created a bugreport for Orchestra to track this:
   http://issues.apache.org/jira/browse/ORCHESTRA-35

I think your suggestion of using the HttpSessionListener interface is a
good one. Unless someone objects, I will update Orchestra's
ConversationManagerSessionListener to implement this interface and
handle sessionDestroyed directly rather than relying on the container. I
can't see how it could cause problems for other containers. Iterating
over the attrs is a minor performance hit for apps with very large
numbers of http-session attributes, but if the webpp is so complex then
this loop is unlikely to be significant.

I will try to find time to do this in the next few days.

There are a couple of other minor Orchestra fixes that it would be nice
to get addressed, so it is probably time to look at getting an
orchestra-3.1 release out in the next month or so.

Thanks for your very clear problem report..

Regards,
Simon

Steve Ronderos schrieb:
>
> Simon,
>
> Sorry about the top-post I wasn't thinking (and my email client is a
> piece...).
>
> I too looked around for the spec on what should happen when a session
> times out.  We are using OC4J :-( .  I'll file a bug report with them.  
>
> There was a workaround I was toying with that could be added to
> Orchestra if you think it is valuable.
>
> I was essentially going to add an HttpSessionListener that removes
> attributes when the session times out.
>
> *public* *class* AttributeRemovalSessionListener *implements*
> HttpSessionListener {
>
>   *public* *void* sessionCreated(HttpSessionEvent se) {}
>
>   *public* *void* sessionDestroyed(HttpSessionEvent se) {
> Enumeration e = _se.getSession().getAttributeNames()_;
>*while* (e.hasMoreElements()) {
>   se.getSession().removeAttribute(e.nextElement());
> }
>   }
> }
>
> With proper exception handling I believe that these methods and the
> HttpSessionListener interface could instead be added to the
> ConversationManagerSessionListener.  I have tested the above listener
> in OC4J and it works, if you think it is worth looking into I could
> test it out on some other Containers to make sure that it doesn't make
> a mess of things.  
>
> Do you think this kind of solution is worth investigating?  Otherwise
> I can look at other workarounds.
>
> Thanks,
>
> Steve Ronderos
>
>
> From: Simon Kitching 
> To:   MyFaces Discussion 
> Date: 12/31/2008 10:03 AM
> Subject:  Re: Possible Leak in MyFaces Orchestrea
>
>
> 
>
>
>
> Hi Steve,
>
> First, PLEASE do not top-post (ie put your reply at the top of an email)
> when someone has previously used bottom-posting. It is really annoying
> and makes the email almost impossible to read sensibly.
>  See:  http://en.wikipedia.org/wiki/Posting_style
>
> I've double-checked the servlet spec, and while I can't find explicit
> wording that says that session timeout triggers removeAttribute on all
> top-level attributes of the session, the docs here do imply it:
> http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpSessionBindingListener.html
>
> Apache Tomcat is the servlet engine I use mostly, and it certainly does
> do this. So a bugreport to your servlet-container vendor is probably a
> good idea.
>
> I'm happy to add a workaround in orchestra for this problem, though, if
> we can find one. I don't see how adding HttpSessionBindingListener to
> ConversationManager will help though; that will mean the
> ConversationManager needs to be able to obtain a reference to the
> ConversationManagerSessionListener which is not easily done.
>
> Possibly the ConversationManagerSessionListener could add a dummy object
> into each session, and this dummy object can then implement
> HttpSessionBindingListener and contain a reference to the
> ConversationManagerSessionListener. It probably needs to be transient
> though (should't be distributed in clustered environments). And it
> somehow also needs to handle session passivation/activation correctly.
>
> If you can create a suitable patch for this issue, I would be happy to
> review and apply it. Otherwise I'll try to find some time to come up
> with a solution but it won't be for at least a few weeks.
>
> By the way, what servlet container are you using (not that crappy
> Websphere I hope; it's riddled with non-spec-compliant behaviour...)
>
> Regards,
> Simon
>
> On Tue, 2008-12-30 at 10:43 -0600, Steve Ronderos wrote:
> >
> > Simon,
> >
> > Thanks for responding!
> >
> > I didn't know about the ConversationManagerSessionListener, after
> > poking at it for a little, I think I understand how it all works now.
> >  Unfortunately I'm still experiencing the leak.  
> >
> > I see in the Listener that it removes the ConversationManager objects
> > in the method attributeRemoved.  Is it required for an HttpSession to
> > remove it's attributes and therefore cause attributeRemoved to be
> > called?  I believe the web co