Hi Sébastien, If you hate IE6, take a look at http://ie6funeral.com/.
Hmm. I know, but on MyFaces 1.2 I guess there is not really a better way to do this. Also the disable attribute is only taken into account for the rendered HTML. Not for more. And of course, you are still able to make a request that includes disabled select item values manually. So you have to take care of them! Regards, Jakob 2010/3/9 <[email protected]> > Hello Jakob, > > At the beginning of this, there was the need to add disabled items in a > menu. The "-1" value was used because, by default, Firefox disables such > option values. These are not selectionables in many browsers except for > Internet Explorer 6, which we must support. :-( > > I tried your suggestion, which works but forces me to have a list of > business objects that is "polluted" with an Integer. > > Since these "-1" items are disabled, does it make sense to validate their > value? I thought about this while looking at the code of SelectItemsUtils, > which blindingly validates all elements: shouldn't this class be patched > to ignore the values whose items are disabled? > > Sébastien > > > > Sébastien Pennec > Lombard Odier Darier Hentsch & Cie > T +41 22 709 2601 - F +41 22 709 3782 > www.lombardodier.com > > > > > > > > Jakob Korherr <[email protected]> > Sent by: [email protected] > > > 09.03.2010 13:54 > Please respond to > "MyFaces Discussion" <[email protected]> > > > > To > MyFaces Discussion <[email protected]> > cc > > Subject > Re: Trouble upgrading from 1.1.2 to 1.1.7 > > > > > > > Hi Sébastien, > > Oh ok. In that case you could return "-1" in your converter and change the > setter in your managed bean to accept Object. There you can check if you > have "-1" or a valid Enum and in the latter case, set it! Then you > shouldn't > have the validation problem. > > In MyFaces 2.0 such scenarios are solved with a new attribute on the > SelectItem and f:selectItem(s) called noSelectionOption or > noSelectionValue. > > Of course it would be great to have such great version numbers, but it's > really hard to do that over an open source community. We'll try for 2.0 to > document those changes in a better way! > > Regards, > Jakob > > > 2010/3/9 <[email protected]> > > > Hi Jakob, > > > > Actually this change has other implications, like the following one: > > > > In a form, I use a double-SelectManyMenu. One lists all possible values, > > and the other lists the selected values. Two buttons allow the user to > > place a value from one menu to the other. > > > > The business values are listed in a java Enum, and use a converter. To > > make things clearer for our users, the values in the first menu, where > all > > possible values are stored, are separated with two "titles". These > > elements actually are SelectItems, with a "-1" value, added as follows: > > > > public List<SelectItem> buildComboContentForSomeBusinessValue() { > > List<SelectItem> items = new ArrayList<SelectItem>(); > > items.add(new SelectItem("-1","Some title")); > > items.addAll(buildSomeSelectItemsBasedOnMyBusinessValues()); > > items.add(new SelectItem("-1","Some other title")); > > items.addAll(buildOtherSelectItemsBasedOnMyBusinessValues()); > > return items; > > } > > > > My converter does the following: > > public Object getAsObject(FacesContext facesContext, UIComponent > > uiComponent, String s) throws ConverterException { > > > > if ("-1".equals( s)) { > > return null; > > } > > return MyBusinessEnum.valueOf( s); > > } > > (and the same in the other way round, Enum -> String) > > > > This way, if the user selects one of the titles, we do nothing with it. > > But if the user selects one of the real business values, then it is > > processed, added to a list, etc... > > > > This behavior used to work with version 1.1.2, and does not anymore. > That > > because the converter is not called anymore during the validation. We're > > comparing for equality "null" and "-1" which would map to the same value > > if the converter was called, but are obviously different without > > conversion. From where I stand, the validation process should not take > the > > responsability to decide if objects are the same or not when a converter > > is involved, but should delegate the conversion to the converter before > > testing for equality. > > > > I now have two options: add the titles to the business enum, which is > > ugly, or find a way to make the validation work again as it used to... > If > > you think about it, quite a lot of people add elements in a business > > menus. Think of the "All" or "None" options that many menus display. In > > that case, I guess (or... hope :-) that the developpers do not include > > "All" and "None" values in their business enums... > > > > Do you have any hints to help me work around this change? Or am I doing > > something wrong here? > > > > On another topic: since your are following the spec version with the > first > > two digits of MyFaces versions, shouldn't you make it a 4-digits > version, > > with the third incrementing when breaking changes occur, and the fourth > > incrementing when you are simply patching the code? I'm not opposed to > > breaking changes in the libs I include in my apps, there's no other way > to > > evolve sometimes... but I'd just like to know when it's going to > happen... > > :-) > > > > Thanks again for your support, > > > > Best regards, > > > > Sébastien > > > > > > > > > > > > > > > > Jakob Korherr <[email protected]> > > Sent by: [email protected] > > > > > > 08.03.2010 17:20 > > Please respond to > > "MyFaces Discussion" <[email protected]> > > > > > > > > To > > MyFaces Discussion <[email protected]> > > cc > > > > Subject > > Re: Trouble upgrading from 1.1.2 to 1.1.7 > > > > > > > > > > > > > > Hi Sébastien, > > > > It's great that you were able to figure out the real problem :) > > > > To explain it a little further: the <f:selectItem itemValue="1" .../> > > creates a SelectItem with the String value of "1". If you want to > provide > > an > > Integer value you have to provide it via a property in a managed bean > that > > returns the integer 1. maybe also #{1} will work, but I'm not really > > sure... > > > > I totally agree that there should be a document (wiki-page etc.) that > > describes such changes. Unfortunately this was far before my time.. > > However, > > if we apply similar changes to MyFaces 2.0, I will write them down on a > > wiki > > page, I promise ;) > > > > Regards, > > Jakob > > > > 2010/3/8 <[email protected]> > > > > > Hello Jakob, > > > > > > Don't worry for the delay, that's great to have support for this kind > of > > > problems :-) > > > > > > First, I changed all the attributes that did not work to String, so > that > > > the page worked again. Then I chose one of the attributes and tried > the > > > following configurations: > > > > > > - int property -> KO > > > - Integer property -> KO > > > - Integer property and explicit converter: > > > (javax.faces.convert.IntegerConverter registered in my own > > > faces-config.xml) -> KO > > > - String property -> OK > > > > > > Since the field was mapping to a "greater or smaller than" filter > value, > > I > > > had not set the page to display an error corresponding to this field. > So > > I > > > added the following line to my JSPX: > > > <ice:message for="myOperator" styleClass="errorMsg"/> > > > > > > With this line, I can now see an error message, saying that my value > is > > > not a valid option. Here is how the field is written in the JSPX: > > > > > > <ice:selectOneMenu value="#{listController.filter.myOperator}" id= > > > "myOperator"> > > > <f:selectItem itemValue="1" itemLabel="#{msg.search_filter_greater}" > > /> > > > <f:selectItem itemValue="-1" itemLabel="#{msg.search_filter_less}" /> > > > </ice:selectOneMenu> > > > > > > I see the call in the IntegerConverter, and can trace it until it is > in > > > the UIInput.java class: > > > > > > if (!isValid()) return; > > > validateValue(context, convertedValue); > > > if (!isValid()) return; > > > > > > The first call to "isValid()" returns true, and the second call > returns > > > false. > > > > > > By digging a little bit further, I found this, in UISelectOne.java, in > > > method "validateValue(FacesContext context, Object value)" : > > > // selected value must match to one of the available options > > > if (!_SelectItemsUtil.matchValue(value, new > _SelectItemsIterator(this))) > > > { > > > _MessageUtils.addErrorMessage(context, this, INVALID_MESSAGE_ID, new > > > Object[] {getId()}); > > > setValid(false); > > > } > > > > > > The condition here returns true, meaning that the validation fails. > And > > > ever further down in SelectItemsUtil.java, method "matchValue(Object > > > value, Iterator selectItemsIter)": > > > Object itemValue = item.getValue(); > > > if (value==itemValue || (itemValue.equals(value))) { > > > return true; > > > } > > > > > > In this condition, the Integer value that has just been created is > > tested > > > for equality with the String value that is in the SelectItem. The > > > validation obviously cannot pass. In version 1.1.2, the same method > > > contained the following code: > > > > > > Object itemValue = item.getValue(); > > > if(converter != null && itemValue instanceof String) > > > { > > > itemValue = converter.getConvertedValue(context, (String)itemValue); > > > } > > > if (value==itemValue || value.equals(itemValue)) > > > { > > > return true; > > > } > > > > > > This code changed the value of the variable "itemValue" to the > converted > > > value when a converter was available, and thus tested two Integer > > objects > > > for equality. > > > I think this explains why setting the property to String works in > 1.1.7, > > > and leaving the property as an int or Integer, as it used to work in > > > 1.1.2, doesn't work anymore. > > > Searching through MyFaces' JIRA, with a clearer view of the problem > lead > > > me to this issue: [1], which explicitly changed the code that is > printed > > > here above. Several persons pointed out the fact that this change of > > > behavior would be an upgrade problem for users migrating MyFaces. But > > > since the change was making MyFaces behave more closer to the RI, I > > guess > > > it made sense to do it anyway. > > > > > > More generally speaking, I think that somebody at MyFaces should build > > and > > > maintain a document listing all upgrade-breaking changes that are > found > > as > > > the development goes on. It is time-consuming to have to diagnose a > > > problem like I had to do, and seeing that the code has been changed > > > knowing that it would cause upgrade problems is just plain annoying. > > Maybe > > > this document already exists, but my search for upgrade problems with > > > MyFaces did not lead me to it. > > > > > > Anyway, thanks Jakob for your support :-) > > > > > > Best regards, > > > > > > Sébastien > > > > > > [1] http://issues.apache.org/jira/browse/MYFACES-1328 > > > > > > > > > > > > > > > > > > > > > > > > Jakob Korherr <[email protected]> > > > Sent by: [email protected] > > > > > > > > > 06.03.2010 09:56 > > > Please respond to > > > "MyFaces Discussion" <[email protected]> > > > > > > > > > > > > To > > > MyFaces Discussion <[email protected]> > > > cc > > > > > > Subject > > > Re: Trouble upgrading from 1.1.2 to 1.1.7 > > > > > > > > > > > > > > > > > > > > > Hi Sébastien, > > > > > > Sorry for the long delay - I had to learn a lot last week for a > > university > > > exam... > > > > > > Anyway, the thing with iceSubmit() was just a guess. I thought that > > maybe > > > ICEfaces causes some kind of a wrong submit data or something like > that. > > > However, it really bugs me that this does not work out for you! A > > version > > > upgrade should not be a loss of functionality! > > > > > > The next thing you/we could take a look at is the conversion > mechanism. > > > Maybe this does not work right, because your String properties work > > > (right?) > > > and your int properties don't. Have you tried setting a converter > > manually > > > at the component which is bound to the int property? The standard > > integer > > > converter's class is javax.faces.convert.IntegerConverter. Altough > this > > > class is registered in the standard-faces-config.xml for type int and > > > java.lang.Integer, it may not be applied (why ever..). > > > > > > Another thing you could try is changing the property from the native > int > > > type to java.lang.Integer. Maybe this will work. > > > > > > Hope this helps! > > > > > > Regards, > > > Jakob > > > > > > 2010/3/3 <[email protected]> > > > > > > > Hi Jakob, > > > > > > > > I guess that the javascript in iceSubmit() might not the cause of > the > > > > problem... The int binding that used to work doesn't work anymore, > and > > > > this is what caused the interface to "freeze". Correcting the java > > code > > > to > > > > accept a String made the interface work correctly again.... > > > > > > > > I fail to understand how does the javascript iceSubmit() fits in > > this... > > > > but I certainly am not the most knowledgable person on the matter. > > Could > > > > you explain what makes you think that the javascript might be a good > > > > suspect? > > > > > > > > Since I have a release planned in a quite short time, I won't be > able > > to > > > > rewrite the whole form using only MyFaces components... sorry about > > > > that... :( But I might have the time to build a sample-app that > shows > > > that > > > > the binding that used to work doesn't work anymore. As I understood > > > them, > > > > the release notes of MyFaces do not show anything related to this > > change > > > > of behavior. Do you think it might be a bug? > > > > > > > > Regards, > > > > > > > > Sébastien > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jakob Korherr <[email protected]> > > > > Sent by: [email protected] > > > > > > > > > > > > 02.03.2010 23:39 > > > > Please respond to > > > > "MyFaces Discussion" <[email protected]> > > > > > > > > > > > > > > > > To > > > > MyFaces Discussion <[email protected]> > > > > cc > > > > > > > > Subject > > > > Re: Trouble upgrading from 1.1.2 to 1.1.7 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > You're welcome ;) > > > > > > > > Hmm. Maybe the submitting via the javascript function iceSubmit() > does > > > not > > > > function properly. It's really hard to say from this point of > view... > > > > > > > > Have you tried using some of the standard MyFaces components > (without > > > > ICEFaces)? > > > > > > > > Regrads, > > > > Jakob > > > > > > > > 2010/3/2 <[email protected]> > > > > > > > > > Hello Jakob, > > > > > > > > > > Here is the generated HTML of (a part of) a search form. It > includes > > a > > > > > "Bigger than/smaller than" field that was bound to an int in my > Java > > > > code. > > > > > > > > > > The binding was not working anymore, untill I modified the setter > of > > > the > > > > > attribute to take a String and converted to an int afterwards > (just > > as > > > a > > > > > quick way of testing if a String binding would work). > > > > > > > > > > I then changed several other bindings similar to this one to use > > > > Strings, > > > > > and the app seems to run way better now :-) but anyway further > > testing > > > > > will be necessary. > > > > > > > > > > HTML: > > > > > > > > > > <tr class="icePnlGrdRow2"> > > > > > <td class="icePnlGrdCol editrQ" > id="searchForm:_id1068-1-0"> > > > > > <label class="iceOutLbl bold" > > > > > for="searchForm:aValueToFilter" id="searchForm:_id1075">Label of > the > > > > value > > > > > to filter</label> > > > > > </td> > > > > > > > > > > <td class="icePnlGrdCol editrR" > id="searchForm:_id1068-1-1"> > > > > > <div class="icePnlGrp" id="searchForm:_id1076"> > > > > > <select style="" class="iceSelOneMnu" > > > > > id="searchForm:valueToFilterOperator" > > > > > name="searchForm:valueToFilterOperator" > > > > > onblur="setFocus('');" > > > > > onfocus="setFocus(this.id);" size="1"> > > > > > <option value="1">Bigger than or equal > > > > > to</option> > > > > > <option value="-1">Smaller than/option> > > > > > </select> > > > > > > > > > > <input style="" class="iceInpTxt" > > > > > id="searchForm:aValueToFilter" name="searchForm:aValueToFilter" > > > > > onblur="setFocus('');" > > > > > onfocus="setFocus(this.id);" > > onkeypress="iceSubmit(form,this,event);" > > > > > onmousedown="this.focus();" > > > > > size="15" value="" type="text"> > > > > > <label class="iceOutLbl" > > > id="searchForm:_id1079"> > > > > > unit of the value to filter</label> > > > > > > > > > > <span id="searchForm:_id1080"></span> > > > > > </div> > > > > > </td> > > > > > </tr> > > > > > > > > > > Does it help? > > > > > > > > > > Thanks a lot for your help... > > > > > > > > > > Best regards, > > > > > > > > > > Sébastien > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jakob Korherr <[email protected]> > > > > > Sent by: [email protected] > > > > > > > > > > > > > > > 01.03.2010 17:50 > > > > > Please respond to > > > > > "MyFaces Discussion" <[email protected]> > > > > > > > > > > > > > > > > > > > > To > > > > > MyFaces Discussion <[email protected]> > > > > > cc > > > > > > > > > > Subject > > > > > Re: Trouble upgrading from 1.1.2 to 1.1.7 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Can you provide some generated HTML (not JSP!!), which includes > > > > components > > > > > that do not work. This could be a great help! > > > > > > > > > > Regards, > > > > > Jakob > > > > > > > > > > 2010/3/1 <[email protected]> > > > > > > > > > > > Hello, > > > > > > > > > > > > My guess is that the problem is more general than just a > > javascript > > > > > issue. > > > > > > > > > > > > In my previous message, I gave the "form submit" situation only > as > > > an > > > > > > example. The problem actually touches more than just this: I > > cannot > > > > sort > > > > > > my table content by clicking on one column header, I cannot > switch > > > > from > > > > > a > > > > > > StackPanel to another, etc... > > > > > > > > > > > > By searching a little bit further, I found out that the values > > that > > > I > > > > > used > > > > > > in combo boxes to show a "greater or smaller" choice (for > example, > > > age > > > > > > greater or smaller than 30) are not bound to their java > > counterpart > > > > > > anymore. For example: > > > > > > > > > > > > <ice:selectOneMenu value="#{someController.filter.ageOperator}" > > id= > > > > > > "ageOperator"> > > > > > > <f:selectItem itemValue="1" > > > itemLabel="#{msg.search_filter_greater}" > > > > /> > > > > > > <f:selectItem itemValue="-1" > > itemLabel="#{msg.search_filter_less}" > > > /> > > > > > > </ice:selectOneMenu> > > > > > > > > > > > > This menu was bound to a Java integer as follows: > > > > > > > > > > > > private int ageOperator; > > > > > > > > > > > > With 1.1.7, the value is not bound anymore. I needed to change > the > > > > type > > > > > of > > > > > > the attribute in my Java class to String for the binding to work > > > > again. > > > > > Is > > > > > > there a special converter that I should add, which was not > needed > > in > > > > > 1.1.2 > > > > > > ? I can assure you that this runs fine with 1.1.2 :-) > > > > > > > > > > > > I am fairly new to MyFaces. Is there something I should do to > make > > > the > > > > > > upgrade easier? > > > > > > > > > > > > Thanks a lot for your help :-) > > > > > > > > > > > > Sébastien > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jakob Korherr <[email protected]> > > > > > > Sent by: [email protected] > > > > > > > > > > > > > > > > > > 01.03.2010 12:25 > > > > > > Please respond to > > > > > > "MyFaces Discussion" <[email protected]> > > > > > > > > > > > > > > > > > > > > > > > > To > > > > > > MyFaces Discussion <[email protected]> > > > > > > cc > > > > > > > > > > > > Subject > > > > > > Re: Trouble upgrading from 1.1.2 to 1.1.7 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > Maybe there's a problem with the javascript that submits the > form. > > I > > > > saw > > > > > > However this is just a shot in the blue... > > > > > > > > > > > > Regards, > > > > > > Jakob > > > > > > > > > > > > 2010/3/1 <[email protected]> > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > I am experiencing quite a lot of trouble while upgrading from > > > > MyFaces > > > > > > > 1.1.2 to 1.1.7. > > > > > > > > > > > > > > My application uses IceFaces 1.8.2, Spring 2.5.2 and Hibernate > > > > 3.4.0. > > > > > > > > > > > > > > The only thing that I changed in my Maven 2 build is the > version > > > of > > > > > > > MyFaces. > > > > > > > This had an impact on the following jars: > > > > > > > > > > > > > > Added: > > > > > > > myfaces-api-1.1.7.jar > > > > > > > myfaces-impl-1.1.7.jar > > > > > > > commons-digester-1.8.jar > > > > > > > commons-beanutils-1.8.0.jar > > > > > > > > > > > > > > Removed: > > > > > > > myfaces-api-1.1.2.jar > > > > > > > myfaces-impl-1.1.2.jar > > > > > > > commons-digester-1.6.jar > > > > > > > commons-beanutils-1.7.0.jar > > > > > > > commons-codec-1.3.jar > > > > > > > > > > > > > > When I build and deploy my application in Weblogic 9.2.3, the > > > deploy > > > > > > goes > > > > > > > fine, but the actions in the app do not work anymore. > > > > > > > More precisely: as soon as I try to use JSF components like > if > > I > > > > > submit > > > > > > a > > > > > > > form, then nothing happens. This behaviour can be observed > with > > > > > several > > > > > > > browsers. > > > > > > > > > > > > > > I tried to find some upgrading guide but didn't find any guide > > > > related > > > > > > to > > > > > > > these versions. And since the version change is minor, I > > expected > > > my > > > > > > > application to run fine with the new jars. > > > > > > > > > > > > > > I tried also tried to override some jar versions, putting back > > the > > > > > > > Digester to version 1.6, and the BeanUtils to version 1.7.0, > but > > > > this > > > > > > > didn't change anything. At this point, the only thing that had > > > > changed > > > > > > in > > > > > > > my EAR were the two MyFaces jars. > > > > > > > > > > > > > > Another attempt to find the problem was to upgrade the version > > > > > > gradually. > > > > > > > I switched to MyFaces 1.1.4, and everything worked fine. > That's > > > when > > > > I > > > > > > > switched to MyFaces 1.1.5 that the problem appeared. However, > I > > > > > haven't > > > > > > > seen anything in the changes from 1.1.4 to 1.1.5[1] that seems > > > > > suspect. > > > > > > > > > > > > > > Is there some configuration changes that I might have missed? > Or > > > > some > > > > > > > known compatibility problems regarding this upgrade? Again, I > > > > couldn't > > > > > > > find anything precisely related to these versions up to now, > but > > > I'm > > > > > > still > > > > > > > looking. > > > > > > > > > > > > > > Any help would be highly appreciated! :-) > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > Sébastien > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=10600&fixfor=12312310&sorter/field=summary&sorter/order=ASC&sorter/field=resolution&sorter/order=ASC&sorter/field=status&sorter/order=ASC&sorter/field=priority&sorter/order=DESC > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ************************ DISCLAIMER ************************ > > > > > > > This message is intended only for use by the person to > > > > > > > whom it is addressed. It may contain information that is > > > > > > > privileged and confidential. Its content does not > > > > > > > constitute a formal commitment by Lombard Odier > > > > > > > Darier Hentsch & Cie or any of its branches or affiliates. > > > > > > > If you are not the intended recipient of this message, > > > > > > > kindly notify the sender immediately and destroy this > > > > > > > message. Thank You. > > > > > > > > > ***************************************************************** > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ************************ DISCLAIMER ************************ > > > > > > This message is intended only for use by the person to > > > > > > whom it is addressed. It may contain information that is > > > > > > privileged and confidential. Its content does not > > > > > > constitute a formal commitment by Lombard Odier > > > > > > Darier Hentsch & Cie or any of its branches or affiliates. > > > > > > If you are not the intended recipient of this message, > > > > > > kindly notify the sender immediately and destroy this > > > > > > message. Thank You. > > > > > > > ***************************************************************** > > > > > > > > > > > > > > > > > > > > > > > > > > ************************ DISCLAIMER ************************ > > > > > This message is intended only for use by the person to > > > > > whom it is addressed. It may contain information that is > > > > > privileged and confidential. Its content does not > > > > > constitute a formal commitment by Lombard Odier > > > > > Darier Hentsch & Cie or any of its branches or affiliates. > > > > > If you are not the intended recipient of this message, > > > > > kindly notify the sender immediately and destroy this > > > > > message. Thank You. > > > > > ***************************************************************** > > > > > > > > > > > > > > > > > > > > > ************************ DISCLAIMER ************************ > > > > This message is intended only for use by the person to > > > > whom it is addressed. It may contain information that is > > > > privileged and confidential. Its content does not > > > > constitute a formal commitment by Lombard Odier > > > > Darier Hentsch & Cie or any of its branches or affiliates. > > > > If you are not the intended recipient of this message, > > > > kindly notify the sender immediately and destroy this > > > > message. Thank You. > > > > ***************************************************************** > > > > > > > > > > > > > > > > ************************ DISCLAIMER ************************ > > > This message is intended only for use by the person to > > > whom it is addressed. It may contain information that is > > > privileged and confidential. Its content does not > > > constitute a formal commitment by Lombard Odier > > > Darier Hentsch & Cie or any of its branches or affiliates. > > > If you are not the intended recipient of this message, > > > kindly notify the sender immediately and destroy this > > > message. Thank You. > > > ***************************************************************** > > > > > > > > > > > ************************ DISCLAIMER ************************ > > This message is intended only for use by the person to > > whom it is addressed. It may contain information that is > > privileged and confidential. Its content does not > > constitute a formal commitment by Lombard Odier > > Darier Hentsch & Cie or any of its branches or affiliates. > > If you are not the intended recipient of this message, > > kindly notify the sender immediately and destroy this > > message. Thank You. > > ***************************************************************** > > > > > > ************************ DISCLAIMER ************************ > This message is intended only for use by the person to > whom it is addressed. It may contain information that is > privileged and confidential. Its content does not > constitute a formal commitment by Lombard Odier > Darier Hentsch & Cie or any of its branches or affiliates. > If you are not the intended recipient of this message, > kindly notify the sender immediately and destroy this > message. Thank You. > ***************************************************************** >
