myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott O'Bryan <darkar...@gmail.com>
Subject Re: Upgrading to MyFace 1.2 in Jboss Portal Server giving problem ...
Date Tue, 22 Apr 2008 05:18:42 GMT
The bridge should work with facelets although I don't know how much  
testing has been done on it.  I'm assuming that you don't have the  
faces servlet listed in your web.xml?

On Apr 21, 2008, at 8:51 PM, souravm <SOURAVM@infosys.com> wrote:

> Solved the issue mentioned below. It was due to mix of myfaces jar  
> in the class path.
>
> Now stuck with the following issue -
>
> The FacesServlet fails to initialize. It says No Mapping Of  
> FacesServlet found. Abort Initializing MyFaces.
>
> I'm using Facelets instead of jsp.
>
> Is that the root cause of the problem ?
>
> Regards,
> Sourav
>
> -----Original Message-----
> From: souravm [mailto:SOURAVM@infosys.com]
> Sent: Monday, April 21, 2008 5:19 PM
> To: dev@myfaces.apache.org
> Subject: FW: Myfaces Portlet does not work when a bean is stored  
> inRequestscope...
>
> Just forwarding the message from user group.
>
> -----Original Message-----
> From: souravm [mailto:SOURAVM@infosys.com]
> Sent: Monday, April 21, 2008 5:00 PM
> To: MyFaces Discussion
> Subject: RE: Myfaces Portlet does not work when a bean is stored in  
> Requestscope...
>
> JBoss Portal Server works fine with JSF 1.2.
>
> The problem starts when I add the portlet-bridge-api-1.0.0- 
> alpha-2.jar and portlet-bridge-impl-1.0.0-alpha-2.jar.
>
> It gives error while parsing the faces-config.xml file in Manifest  
> folder of portlet-bridge-impl-1.0.0-alpha-2.jar. It says Parse Error  
> at line 20 column 14: Document is invalid: no grammar found.
>
> Regards,
> Sourav
>
> -----Original Message-----
> From: Scott O'Bryan [mailto:darkarena@gmail.com]
> Sent: Monday, April 21, 2008 4:15 PM
> To: MyFaces Discussion
> Subject: Re: Myfaces Portlet does not work when a bean is stored in  
> Requestscope...
>
> I would be surprised if JBoss didn't have JSF built in.  Since the  
> RI is
> under development, there is no real good documentation.  On the wiki I
> have a page which outlines getting Pluto installed in Tomcat6,
> presumably you could use the RI or MyFaces with that.
>
> Scott
>
> souravm wrote:
>> Hi Scott,
>>
>> Thanks for the list.
>>
>> Is there any good documentation available anywhere to help starting  
>> with My faces JSF 1.2 and the Portlet Bridge ?
>>
>> I was trying to experiment with them. But at a first step itself  
>> I'm getting problem once we put the respective jars in the jboss  
>> server. The server is not starting up.
>>
>> Regards,
>> Sourav
>>
>> -----Original Message-----
>> From: Scott O'Bryan [mailto:darkarena@gmail.com]
>> Sent: Monday, April 21, 2008 2:45 PM
>> To: MyFaces Discussion
>> Subject: Re: Myfaces Portlet does not work when a bean is stored in  
>> Requestscope...
>>
>> A quick list of items that will be addressed as part of 301 in JSF  
>> 1.2
>> over other bridges are:
>>
>> 1. Better thought through request scope
>> 2. Extendible GenericFacesPortlet allowing custom behavior and  
>> mixture
>> of portlet/jsf generated content while still being able to use the  
>> bridge
>> 3. Much better thought out implementation of the ExternalContext -  
>> The
>> spec amends what is in JSF 1.2 where appropriate.
>> 4. EL Resolvers for portlet specific objects
>> 5. Support for "Bridge Optional" deployments where if you have an
>> application that works both as a portlet AND a servlet, the bridge  
>> jars
>> are only needed at compile time
>> 6. Explicit support for @PreDestroy and @PostCreate annotations which
>> are not supported with in JSR-168
>> 7. Support for JSR-286 eventing, and resource requests that can be  
>> used
>> to open up AJAX.
>> 8. Support for *inline* content without the verbatim tag.  This is  
>> a 1.2
>> feature that didn't work when run from most bridges unless they were
>> integrated into the JSF implementation.
>> .
>> And many many more features.  :)
>>
>> Scott
>>
>> Scott O'Bryan wrote:
>>
>>> souravm wrote:
>>>
>>>> Hi Scott,
>>>>
>>>> Thanks again for clearing some of the basic points.
>>>>
>>>> For the better future reference purpose here I try to summarize our
>>>> discussion/debate points.
>>>>
>>>> 1. Issue # 1 - How to handle initial Portlet request which has
>>>> request parameters.
>>>>
>>>> Yes I do agree with you that " Portals, according to Portlet
>>>> 1.0 spec make an initial call to a portlet through a render
>>>> request.". In the same context, I am also pretty much ok to go by
>>>> your statement " you should do as little in your render request as
>>>> you can, but no less ".
>>>>
>>>> However, if this is the model to be followed, it is an absolute  
>>>> need
>>>> that the original http request parameters should be made  
>>>> available in
>>>> Render request. Only then a specific application context can  
>>>> utilize
>>>> this model efficiently and decide, given a situation, what is the
>>>> minimal processing has to be done in the initial render request.
>>>>
>>>>
>>> Actually this is not the case.  At least not as far as the Portal
>>> people I've talked to are concerned.  For a given render request,  
>>> any
>>> parameters added to that render url WILL be available to the render
>>> request.  This means that if, in your example, you created a
>>> RenderRequest instead of an action, your parameter would be
>>> available.  Portals rely on the action adding their own render
>>> parameters in an action request via the ActionResponse.
>>>
>>>> Even, if I revisit the thought process I went through to address my
>>>> specific scenario, it is the unavailability of original request
>>>> parameter in Render request for which I'm trying to do a work  
>>>> around.
>>>> a) JBoss Portal Server by default always sends a Render Request (as
>>>> it is in Portal spec) as initial call to a Portlet. But the  
>>>> original
>>>> request parameters are not available in Render request. So the  
>>>> bridge
>>>> did not work automatically.
>>>>
>>>>
>>> They should be...  Any parameters added to the RenderURL should be
>>> available to the rest of the render request.  Initially portals  
>>> don't
>>> have any, that's true, but if you have a render url with some
>>> parameters on it, they will be available.
>>>
>>>> b) Hence, I decided to use Action Request as initial call (JBoss
>>>> Portal server gives me a way to achieve that).
>>>> c) Now, since MyFacesGenericPortlet, for the initial call does not
>>>> execute other phases of JSF except render phase (which is, I accept
>>>> that, based on Portlet spec), calling Action Request does not solve
>>>> my issue.
>>>> d) So finally, as you suggested, I need to extend the  
>>>> processAction()
>>>> method of MyFacesGenericPortlet, to add some code which can store  
>>>> the
>>>> map of original http request parameter and the same can be accessed
>>>> in Render Request.
>>>>
>>>> It is good that, now pretty much everyone agrees that Request
>>>> Attribute needs to be preserved. But, in my view, ideally it should
>>>> not be part of JSR 301. Rather it should be part of next Portal  
>>>> spec.
>>>> In that case, there won't be any need at all for supporting Action
>>>> Request as initial Portlet call. This will solve the root problem.
>>>> However, surely for the time being supporting Action Request at
>>>> initial Portlet call in JSR 301 would surely make JSF-Portlet
>>>> people's life easier.
>>>>
>>>>
>>>>
>>> This won't happen because it's against the design they used for
>>> portals and DOES NOT work with the eventing model.  Seriously I  
>>> would
>>> give up on it because the industry as a whole seems to be stacked up
>>> against you on this one.  :)  In short, parameters added to a
>>> RenderURL will be available during render.  Parameters added during
>>> Event or Action requests will not be, you'll have to explicitly set
>>> them on the response.  For what it's worth, nothing is stopping you
>>> from doing this yourself.
>>>
>>>> 2. Issue # 2 - In portal environment, persistence of managed bean,
>>>> which is defined as to be in request scope, in current Action- 
>>>> >Render
>>>> sequence.
>>>>
>>>> I see your point that the managed beans in request scope need to be
>>>> stored not only in current Action->Render sequence but also for
>>>> future direct Render Request for the Portlet.
>>>>
>>>> Also I understand that, currently neither JSF spec nor Portal spec
>>>> dictates that whose responsibility is ensure this requirement.
>>>>
>>>> In this context, my 2 cents would be -
>>>> a) Probably JSR 301 is the right place to enforce it, as this is
>>>> about JSF portlets.
>>>> b) I agree with you that given this overall requirement " most
>>>> efficient use on this is for the request attributes to follow the
>>>> same lifecycle as the render parameters unless they are excluded. "
>>>>
>>>>
>>> 301 enforces that request attributes are preserved between action  
>>> and
>>> render.  It's unfortunate that JSR-168 did not allow this to be
>>> consistent at the container level which is why we decided the bridge
>>> should make it consistent so that all JSF applications could  
>>> depend on
>>> the same behavior.
>>>
>>>> To answer your question about moving to JSF 2.0, currently the
>>>> decision is to stick to JSF 1.1 (with facelets for templating) till
>>>> the JSF 2.0 gets matured enough to use in a production scenario.  
>>>> Can
>>>> you please let me know any feature of JSF 2.0 which can resolve  
>>>> above
>>>> problems out of the box ?
>>>>
>>>>
>>> Sorry, the JSR-301 bridge has 2 specs right now.  One for Portlet  
>>> 1.0
>>> and JSF 1.2 and the other for Portlet 2.0 and JSF 1.2.  JSF 2.0 will
>>> be covered by future specs but should address some of the wierdness
>>> that was present in JSF 1.2 because the portal scenarios were not
>>> properly explored.
>>>
>>> The JSR-301 Spec lead is on the JSF 2.0 Expert Group so he's  
>>> ensuring
>>> some of the insanity won't be there in the next release...  :)  That
>>> said though, upgrading to JSF 1.2 would allow you to use the new
>>> bridge.  It's been out for a while and is pretty stable, the only
>>> issue is that you must use a J2EE 5 container.
>>>
>>>> However, I'll surely go through the JSR 301 spec and let me know my
>>>> comments.
>>>>
>>>>
>>> Very cool, that would be very helpful.  There is a public draft for
>>> the Portlet 1.0 bridge.  You might also want to look through JSR-286
>>> (Portlet 2.0) spec to see what the new portlet spec is going to look
>>> like.
>>>
>>> Scott
>>>
>>>> Regards,
>>>> Sourav
>>>>
>>>> -----Original Message-----
>>>> From: Scott O'Bryan [mailto:darkarena@gmail.com]
>>>> Sent: Friday, April 18, 2008 3:57 PM
>>>> To: MyFaces Discussion
>>>> Subject: Re: Myfaces Portlet does not work when a bean is stored in
>>>> Requestscope...
>>>>
>>>> Eeks I wish these would have been seperate, this is going to be a  
>>>> long
>>>> response and not be as easily referenceable in the archives.
>>>>
>>>> souravm wrote:
>>>>
>>>>
>>>>> Hi Scott,
>>>>>
>>>>> Thanks for the detailed answer/explanation. They were really  
>>>>> helpful
>>>>> to verify my understanding and also enriching the same.
>>>>>
>>>>> My consolidated response to your last 2 mails are embedded below.
>>>>>
>>>>> Regards,
>>>>> Sourav
>>>>>
>>>>> -----Original Message-----
>>>>> From: Scott O'Bryan [mailto:darkarena@gmail.com]
>>>>> Sent: Friday, April 18, 2008 12:27 PM
>>>>> To: MyFaces Discussion
>>>>> Subject: Re: Myfaces Portlet does not work when a bean is stored  
>>>>> in
>>>>> Requestscope ...
>>>>>
>>>>> Souravm,
>>>>>
>>>>> Just a clairification, the request bean you have, is it not  
>>>>> getting
>>>>> preserved between a single Action->Render or is it just not  
>>>>> getting
>>>>> preserved in subsequent renders?
>>>>>
>>>>> <Sourav>
>>>>>
>>>>> It does not get preserved in single Action->Render.
>>>>>
>>>>> I'm not sure
>>>>> - Whether this should be responsibility of the Portal server to
>>>>> preserve the bean within the same request scope when the bean is
>>>>> declared to be of request scope.
>>>>> - Or it is responsibility of the bridge
>>>>>
>>>>>
>>>>>
>>>> Currently is it nobodies responsibility.  I would certainly be
>>>> interested in enforcing consistency here at the bridge level.   
>>>> All I'm
>>>> saying is that in JSF, this isn't defined at all.  In Portlet 1.0  
>>>> it's
>>>> not defined either.  So today, it works as it works.
>>>>
>>>>
>>>>> If it is the responsibility of the bridge, then my take is the  
>>>>> root
>>>>> cause of this problem again goes back the issue#1 (replicating
>>>>> parameters/attributes from ActionRequest to RenderRequest).
>>>>>
>>>>>
>>>>>
>>>> Your first issue and this one are two COMPLETLY different things..
>>>> Attributes are attributes and parameters are parameters.    Why?
>>>> Request attributes in a portal env last though the current  
>>>> request while
>>>> request parameters last through the current request and subsequent
>>>> non-direct render requests.
>>>>
>>>>
>>>>> The entire JSF lifecycle execution (except render) happens within
>>>>> processAction() method which runs with the ActionRequest. So the
>>>>> bean creation, execution of bean's methods (which in turn populate
>>>>> the result to be displayed in the resultant response page  
>>>>> created in
>>>>> render phase) also happen within this scope. So if the bean in its
>>>>> latest state needs to be stored and used in the render phase the
>>>>> bean has to be stored either in session (which works fine in  
>>>>> case of
>>>>> session scoped bean) or it has to be explicitly set in  
>>>>> RenderRequest.
>>>>>
>>>>>
>>>>>
>>>> This is totally incorrect actually.  First off, there is nothing  
>>>> in JSF
>>>> which says the Lifecycle.execute has to happen during an action
>>>> request.  Quite the contrary it CAN'T.  Portals, according to  
>>>> Portlet
>>>> 1.0 spec make an initial call to a portlet through a render  
>>>> request.
>>>> This means that, at the very least, the initial call into the  
>>>> execute
>>>> must be a render request.  When you start adding usecases for  
>>>> Portlet
>>>> 2.0, you cannot tie specific pieces of a lifecycle to specific  
>>>> lifecycle
>>>> phases.  That said, I don't disagree that Request Attributes  
>>>> should be
>>>> preserved.  That's how it was spec'd in JSR-301 because pretty much
>>>> everyone agrees with you.  Pre-JSR-301 beidges did not address this
>>>> usecase though.  It was not a requirement of JSF and the spec  
>>>> simply
>>>> says that the maps reflect what is currently stored on the request.
>>>>
>>>> As such, if you take an attribute, store it on the native Request
>>>> object, and then in the render try to get it, you'll find your  
>>>> portal is
>>>> not preseving that attribute.
>>>>
>>>>
>>>>> </Sourav>
>>>>>
>>>>>
>>>>>
>>>>
>>>>> The first issue, in bridges before JSR-301 is actually a portal  
>>>>> issue.
>>>>> The JSR specification does not say whether request attributes  
>>>>> set in
>>>>> the
>>>>> action request have to be available in the render request.  IMO,  
>>>>> if
>>>>> they
>>>>> are not, request attributes are basically pointless.  Pre-JSR 301
>>>>> bridges were ignorant of this fact and just did what the portal  
>>>>> did.
>>>>> The JSR-301 bridge DOES define this behavior and I believe he have
>>>>> special code to handle these issues.  This code is NOT in the  
>>>>> MyFaces
>>>>> 1.1 bridge.
>>>>>
>>>>> <Sourav>
>>>>>
>>>>> I see your point.
>>>>>
>>>>> However, going back to the comment you made in last mail (whether
>>>>> this is a valid usecase or not, or should this scenario has to be
>>>>> handled through Render URL), I don't think using a RenderURL is a
>>>>> right solution. This is because following reasons -
>>>>>
>>>>> a) RenderURLs are to be directly called only when there is no
>>>>> processing needs to be done for a Portlet, only the previous view
>>>>> has to be rendered. In my understanding, this is to be used
>>>>> especially for the pages with multiple portlets. This ensures that
>>>>> in case one Portlet sends an ActionRequest, all other portlets in
>>>>> the same page does not need to go through the action processing  
>>>>> for
>>>>> the previous request (instead they can just repeat the render  
>>>>> phase
>>>>> of Portlet Lifecycle with the result from previous action).
>>>>>
>>>>>
>>>>>
>>>> You are partially correct.  ProcessAction is designed to be used in
>>>> response to expensive processing operations which are usually  
>>>> caused by
>>>> form submissions.  Portal developers realized that a person will  
>>>> only
>>>> ever interact with one portlet at a time and that, when a person  
>>>> does
>>>> interact with a portlet, they have access to things (like the  
>>>> request
>>>> input stream), that other portlets do not.
>>>>
>>>> Where you are wrong is that this HAS to be the case.  Indeed  
>>>> during the
>>>> initial render of a portlet (which is always a render request)  
>>>> this is
>>>> NOT the case, because some processing has to be done.  The  
>>>> correct way
>>>> to think about it is that you should do as little in your render  
>>>> request
>>>> as you can, but no less.
>>>>
>>>> So why do I think the Render URL is appropriate here?  Let's say  
>>>> you had
>>>> a normal (non-JBOSS) search portlet.  In order to execute it, you  
>>>> would
>>>> need an initial screen (which could absolutely do some  
>>>> processing).  If
>>>> this initial screen was a JSF application, JSF would handle all the
>>>> binding and assignment to the backing beans and everything would  
>>>> work.
>>>>
>>>>
>>>>> b) Secondly, not sure how valid is the assumption that the first
>>>>> request to a Portlet will always be Render Request. Even during
>>>>> first time bringing up the portlet in a page there may be need of
>>>>> doing some processing based on the Portlet Preference which  
>>>>> ideally
>>>>> should be handled in processAction() phase of Portlet lifecycle.  
>>>>> So
>>>>> ideally this assumption should be relooked at.\
>>>>>
>>>>>
>>>>>
>>>> Again, according to the Portlet 1.0 specification, this CANNOT  
>>>> happen.
>>>> The initial request in a portlet is ALWAYS a render request.  It's
>>>> spec'd that way.  Apparently JBoss has added some extensions to  
>>>> change
>>>> that, but it does not fit with JSR-168.
>>>>
>>>>
>>>>> I surely feel this usecase should be supported (standard
>>>>> struts-portlet bridges support it). I'll really appreciate if you
>>>>> can discuss this in next JSR 301 meeting.
>>>>>
>>>>>
>>>>>
>>>> I will, I'll get it added to the agenda..
>>>>
>>>>
>>>>> </Sourav>
>>>>>
>>>>> As for the second issue, this is also something that is now  
>>>>> handled by
>>>>> JSR-301, but the original attempt at JSF to define a bridge did  
>>>>> NOT
>>>>> make
>>>>> this a requirement.  In order to maintain compatibility with  
>>>>> existing
>>>>> applications, the 301 bridge will preserve request attributes on
>>>>> subsequent "non-direct" render requests, but we also had to add a
>>>>> way to
>>>>> disable this functionality for beans that did not expect to be
>>>>> preserved.
>>>>>
>>>>> <Sourav>
>>>>>
>>>>> I've not really tested preserving the request for subsequent
>>>>> non-direct render request. As I mentioned above, I found problem
>>>>> even in storing the same bean within the single Action->Render
>>>>> sequence.
>>>>>
>>>>> However, my view is, if request parameters (in a managed bean)  
>>>>> needs
>>>>> to be stored for subsequent render requests, it crosses the  
>>>>> boundary
>>>>> of a single http request. Then the managed bean has to be scoped  
>>>>> at
>>>>> session level.
>>>>>
>>>>> </Sourav>
>>>>>
>>>>>
>>>>>
>>>> Yeah, I know.  This went back and forth as well.  However, with  
>>>> JSF this
>>>> doesn't make sense.  Let's say you have 2 JSF portlets.  Portlet  
>>>> #1 has
>>>> a search box.  You type in a value into the search box and JSF  
>>>> stores
>>>> the value into a request scoped bean and displays the results.   
>>>> You then
>>>> interact with another portlet.  When your page refreshes, the  
>>>> item you
>>>> were searching for is no longer there.  We've gone though quite a  
>>>> few
>>>> iterations on this and the most efficient use on this is for the  
>>>> request
>>>> attributes to follow the same lifecycle as the render parameters  
>>>> unless
>>>> they are excluded.  The problem with storing everything on the  
>>>> session
>>>> is that it never goes away and this will eat up tons of memory.   
>>>> If your
>>>> application explicitly handled this storing and removing of  
>>>> objects,
>>>> that's one thing.  But JSF does not allow you to easily remove a  
>>>> managed
>>>> bean from a scope.
>>>>
>>>>
>>>>> For issue #1, I think it would probably be appropriate to add  
>>>>> some code
>>>>> to fix this.  What it would entail is storing the RequestMap in a
>>>>> global
>>>>> map with a key that you would set as a render parameter.  You'll
>>>>> need to
>>>>> be careful to clean up anything that might "leak".
>>>>>
>>>>> <Sourav>
>>>>>
>>>>> I agree with you on this. I'm planning to create this map in
>>>>> actionProcess() method in case the VIEW_ID request parameter is  
>>>>> null
>>>>> (the VIEW_ID null is the flag to identify that it is a non-JSF
>>>>> action request).
>>>>>
>>>>> </Sourav>
>>>>>
>>>>> For issue #2, existing portlet applications in the 1.1 space  
>>>>> DEPEND on
>>>>> this behavior.  Changing it would break those applications.  We
>>>>> chose to
>>>>> break it for JSR-301 because we though it more appropriate to  
>>>>> preserve
>>>>> these parameters, but we added several mechanisms (one  
>>>>> annotation based
>>>>> and one FacesConfig based) to allow these attributes to be easily
>>>>> excluded.
>>>>>
>>>>> <Sourav>
>>>>>
>>>>> I see your point. Hope JSR 301 and JSR 286 together can bring more
>>>>> predictable and intuitive behavior for Portal-JSF combination.
>>>>>
>>>>> </Sourav>
>>>>>
>>>>>
>>>>>
>>>> Well it's shaping up to be interesting.  More predictable, I  
>>>> doubt it.
>>>> What 286 will do is add a bunch of functionality, like the  
>>>> ability to
>>>> support AJAX in a standardized fashion.
>>>>
>>>> Is there any reason you can't move to JSF 1.2?  I would be very
>>>> interested in your opinions of the JSR-301 bridge which should  
>>>> run on
>>>> Portlet 1.0 and JSF1.2 just fine.  The spec's are not yet final  
>>>> and so
>>>> there is still time to influence some of the usecases or, at the  
>>>> very
>>>> least, get your head around what will be the Java standard soon.
>>>>
>>>> In the mean time, I'll ask the EG if we need to support an initial
>>>> request being an action request.  I know we've got some JBOSS  
>>>> guys on
>>>> the Expert Group so we may be able to get them to comment.  For now
>>>> though, try generating a render url and I think you'll find that  
>>>> the
>>>> bridge will let it work.
>>>>
>>>>
>>>>> Hope that helps,
>>>>>  Scott
>>>>>
>>>>> souravm wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I have a simple JSF application exposed as Portlet (in JBoss  
>>>>>> Portal
>>>>>> Server 2.6.4) using MyFacesGenericPortlet. The JSF application  
>>>>>> has
>>>>>> a managed bean with Request scope.
>>>>>>
>>>>>> The application works perfectly when it is run outside Portal
>>>>>> environment.
>>>>>>
>>>>>> But within Portal environment it does not work as the Manages  
>>>>>> Bean,
>>>>>> though gets initiated and do all the processing properly during 

>>>>>> the
>>>>>> initial lifecycle phases, during the render phase it further gets
>>>>>> initiated and the previous instance gets lost.
>>>>>>
>>>>>> The same works perfectly fine in Portal environment when the
>>>>>> Managed Bean is declared in session scope.
>>>>>>
>>>>>> Not sure whether this is the problem of MyFacesGenericPortlet or
>>>>>> the Portal Server where it is running. Or is it by design ?
>>>>>>
>>>>>> Any insight/viewpoint on this would be highly appreciated.
>>>>>>
>>>>>> Regards,
>>>>>> Sourav
>>>>>>
>>>>>> **************** CAUTION - Disclaimer *****************
>>>>>> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION
>>>>>> intended solely for the use of the addressee(s). If you are not 

>>>>>> the
>>>>>> intended recipient, please notify the sender by e-mail and delete
>>>>>> the original message. Further, you are not to copy, disclose, or
>>>>>> distribute this e-mail or its contents to any other person and  
>>>>>> any
>>>>>> such actions are unlawful. This e-mail may contain viruses.  
>>>>>> Infosys
>>>>>> has taken every reasonable precaution to minimize this risk,  
>>>>>> but is
>>>>>> not liable for any damage you may sustain as a result of any  
>>>>>> virus
>>>>>> in this e-mail. You should carry out your own virus checks before
>>>>>> opening the e-mail or attachment. Infosys reserves the right to
>>>>>> monitor and review the content of all messages sent to or from  
>>>>>> this
>>>>>> e-mail address. Messages sent to or from this e-mail address  
>>>>>> may be
>>>>>> stored on the Infosys e-mail system.
>>>>>> ***INFOSYS******** End of Disclaimer ********INFOSYS***
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
>>
>

Mime
View raw message