Subject: Re: Value object doubt !!! From: Vic C <[EMAIL PROTECTED]> === And no need to panic, anyone can build a web app. But a software engineer can help you use less resources and effort and make it more scalable and maintainable.
Vic C wrote: > Don't kill the messenger. That's what some of this is about. I do not > know of any contradictions documents or comments and my and other > consultants experience is inline with this. See point 95, I think that > is why there are a few vocal sales people who say the emperor IS wearing > some clothing. > This is why I did what is says on page 4, 2nd sentence. > The working full realistic example webPIM is Struts specific. However > the choice I did to implement the dao (DAO has nothing to do with > Struts. Struts only defines the form Bean and MVC ) is what is says on > page 4 2nd sentence. > > JDO got recently delayed or pulled. You cant do XML joins (as JDO > implies), and have some of the same EQL issues. On news.strutsplus.com > there is a newsgroup Castor a leading JDO implementation. I wish there > was a better place than Struts MVC to talk about the M at length. > Anyway, my implementation works well at several client's production > sites and ... I am the only one to share a public realistic full example > with tiles, validation, master detail, CRUD, model, navigation, options, > formatting, etc. which I think kind of makes me a bit of a target. Some > day there will be a better practice to CRUD Master/Detail applications > that are better than webPIM. My goal was webPIM as a Struts MVC example, > but by separating the DAO outside of the bean, people can implement the > DAO anyway they chose, and not follow my design. Or they can refractor > and improved DAO and not break the bean. > > They only good choice, for people that hire me to advise them or recover > their project, is to roll your own beans. I had to show a working > realistic M in webPIM and did so. > > Nice thing about open standards is that any potential weakens is > publicized and criticized and a road to improvements is open, by those > wiling to implement it. When MS has a weakness, it is "forbade to > criticize the HQ". Cathedral and the Bazaar book shows why open standard > will defeat the "Cathedral approach. > > Vic > > > > Michael Delamere wrote: > >> Hi, >> >> I´ve just read the "EJB_101Damnations.pdf". Could somebody lead me to an >> article that may contradict the 101Damnations pdf. If the specified >> pdf is >> overall correct, what are the alternatives? JDO?? >> >> Could someone please clarify me on this issue. >> >> Thanks, >> >> Michael >> >> >> ----- Original Message ----- >> From: "Struts Newsgroup" <@[EMAIL PROTECTED]> >> To: <[EMAIL PROTECTED]> >> Sent: Friday, May 24, 2002 7:25 PM >> Subject: Re: Value object doubt !!! >> >> >> >>> Subject: Re: Value object doubt !!! >>> From: Vic C <[EMAIL PROTECTED]> >>> === >>> Fat fingered "do not look at" >>> http://www.softwarereality.com/programming/ejb/EJB_101Damnations.pdf >>> >>> >>> Vic Cekvenich wrote: >>> >>>> STEVE WILKINSON wrote: >>>> 2 each his own. I understand you view on EJB's and would apprechiate if >>>> you keep that on your site and don't put that here. >>>> >>>> Should I say do not look at >>>> http://www.bad-managers.com/Features*/ejb/i*ndex.shtml ? >>>> Not sure how to respond to this. EJB's is something I used in the >>>> model; and now I don't. You don't think people should be exposed as >>>> to why that is? Certainly new users and new managers should be aware >>>> that you can do MVC and J2EE without EJB and at least some feel that >>>> this is better. My guess is EJBs are going to go the way of the >>>> client side Java, that is to say, they will not be used. I predict >>>> that the silent majority used to use EJB's and don't use EJB anymore >>>> and very soon that will be conventional wisdom not to use EJB. I >>>> would say people that argue EJB is good lose some credibility with >>>> me (and you could say people that argue EJB are not good lose >>>> credibility with you. 2 each his own) I do ask for comments on >>>> http://www.bad-managers.com/Features/ejb/index.shtml here or at >>>> mvc-programmers. >>>> >>>> >>>> We are using the EJB technology, but we also use DataAccessObjects >>>> (DAO), the problem is that the data in the database is needed by both >>>> web clients and other interfaces, XML/SOAP, and Java Swing Clients. We >>>> are using the transformation process strickly on the web tier to >>>> eliminate some of the manual coding within the Action class. We have >>>> JUnit tests for Form Beans and ValueObjects (DTO) to remind us that >>>> when >>>> we update one we need to update the other. >>>> >>>> :-\ , You can look at a post in the mvc-programmers news group on >>>> how it is benefitial to have a single model beans for use by SOAP, >>>> Swing, etc. >>>> >>>> >>>> I'm just trying to give someone a peek at how we are planning on doing >>>> that. >>>> >>>> >>>> It looked like a question. >>>> >>>> >>>> >>>> >>>> If you have "been there done, done that, got the T-shirt" I would be >>>> interested in hearing how you did the conversion from ValueObject (DTO) >>>> to FormBean and return. >>>> >>>> I have a post of the code on the strutsplus.com home page. Again, >>>> feel free to comment on the implemented design. >>>> >>>> >>>> To the newbies, you don't want to sub-class a mixed type object >>>> within a >>>> FormBean because of validation issues that Craig covered in prior >>>> posts. >>>> If you want to do it automatically in a layered tier, I've described an >>>> approach that we are trying. >>>> >>>> ?? >>>> >>>> >>>> >>>> >>>> I by not way mean to imply this is the best way or the only way. If you >>>> want an option there are plenty on this list to provide it. >>>> >>>> BTW, it's Friday. >>>> >>>> I just need not to look at this list on Fridays. ;-) >>>> Vic >>>> >>>> >>>> >>>>> >>>>>> From: Struts Newsgroup (@Basebeans.com) <[EMAIL PROTECTED]> >>>>>> Reply-To: "Struts Users Mailing List" >>>>>> <[EMAIL PROTECTED]> >>>>>> To: [EMAIL PROTECTED] >>>>>> Subject: Re: Value object doubt !!! >>>>>> Date: Fri, 24 May 2002 08:10:02 -0700 >>>>>> >>>>>> Subject: Re: Value object doubt !!! >>>>>> From: Vic C <[EMAIL PROTECTED]> >>>>>> === >>>>>> Been there done that, got the T-Shirt. I used to do the same thing. >>>>>> And I found a simpler, better approach and have a tested production >>>>>> designs and fully functional sample code to show! Other designs are >>>>> >>>>> >> not >> >>>>>> showing fully functional code. >>>>>> I do project recovery for a living. >>>>>> For your consideration: >>>>>> >>>>>> Craig support light weight frameworks MVC I think and not forcing >>>>> >>>>> >> people >> >>>>>> to do things one way.(Are you using EJB? How are you addressing some >>>>> >>>>> >> of >> >>>>>> the issues in Software Reality EJB 101 that I and others found?) >>>>>> I hope to persuade Craig and others one way to look at a practical >>>>>> and >>>>>> simple and light weight alternative for model direction. I think it >>>>> >>>>> >> all >> >>>>>> stems from the old discussion of should form beans be a base class or >>>>> >>>>> >> an >> >>>>>> interface. (I think one of the reasons for Struts success is that it >>>>> >>>>> >> is >> >>>>>> light weight, simple and practical). >>>>>> >>>>>> The point of using a framework it to use it, and not build a >>>>> >>>>> >> framework. >> >>>>>> Analogy I use it you can wake up in the morning and drive a car, >>>>>> or go >>>>>> under the car and thinker with the combustion engine and the brakes. >>>>> >>>>> >> No >> >>>>>> need to mess with the technology. Use the force Luke, to make your >>>>>> project more productive. >>>>>> >>>>>> The larger the project the more the risk, so use Struts and don't do >>>>>> technology. ValueObject are just another bean. Transformation helper? >>>>>> You will get lost in the woods. >>>>>> >>>>>> Based on WebPIM from home page of StrutsPlus.com: >>>>>> Here is a repost on an alterntative design for your consideration, >>>>>> repost from news.strutsplus.com: >>>>>> >>>>>> [EMAIL PROTECTED] >>>>>> >>>>>>> Inline: >>>>>>> >>>>>>> >>>>>>>> Rick Reumann wrote: >>>>>>>> I'm still new to trying to comprehend the various ways the Model >>>>>>> >>>>>>> >>>>>> layer >>>>>> >>>>>>>> can be implemented in a J2EE app, so I want to make sure I'm >>>>>>>> understanding a few things in relation to the webPIM sample app at >>>>>>>> www.basebeans.com. >>>>>>> >>>>>>> >>>>>>> It is possible to use J2EE without EJB and it is possible and >>>>>> >>>>>> >>>>>> desirable >>>>>> >>>>>>> to use MVC with a less complexity. (No need for Business objects or >>>>>>> Value Objects in some cases, if they do nothing for you if only a >>>>>> >>>>>> >> DAO >> >>>>>>> would do). Doing things right means more scalability and faster to >>>>>>> develop with less effort. >>>>>>> >>>>>>> >>>>>>>> 1) I was under the impression that you want to have your Data >>>>>>> >>>>>>> >>>>>> Transfer >>>>>> >>>>>>>> Objects (or Value Objects) to be as reusable as possible. It looks >>>>>>>> like in the case of the webPIM app that a typical bean (ie >>>>>>> >>>>>>> >>>>>> NameLstBean >>>>>> >>>>>>>> ) is tightly coupled with the table columns found in the DAO that >>>>>>> >>>>>>> >>>>>> the >>>>>> >>>>>>>> bean has as a member. >>>>>>> >>>>>>> >>>>>>> Nope. This is a form bean; it should reflect the page properties, >>>>>> >>>>>> >> not >> >>>>>>> the physical data model. The bean is bound to the presentation. How >>>>>> >>>>>> >>>>>> the >>>>>> >>>>>>> physical DB does not matter to the public interface of the bean. >>>>>>> Idea here is that a requriment or html page would be the spec. You >>>>>> >>>>>> >>>>>> would >>>>>> >>>>>>> create a bean that follows it logicaly, with getters and setters >>>>>>> matching page properties. >>>>>>> (What confused you is the physical data model design, which a good >>>>>>> design follows the outputs and uses of the web app.) >>>>>>> So: Bean maps to the page logically. It hides the physical >>>>>>> implementation inside of it. Changes to the data model do affect the >>>>>>> implementation but not the "use" of the bean. >>>>>>> (Complex example: A bean getter could call another beans getter or >>>>>>> setter so you can have a bean that contains other beans for a >>>>>> >>>>>> >> complex >> >>>>>> page) >>>>>> >>>>>>> >>>>>>>> The design seems to be: call a populate method >>>>>>>> on a particular bean which in turn will return a DAO to the bean >>>>>>> >>>>>>> >>>>>> that >>>>>> >>>>>>>> contains a cached rowset of the columns returned from the query. >>>>>>> >>>>>>> >>>>>> Then >>>>>> >>>>>>>> in order to get back say a First Name the bean will actually get a >>>>>>>> handle to the DAO stored in the bean and then call a method like >>>>>>>> nameLstDAO.getCRString("first_name"). (Forgive me Vic if I >>>>>>> >>>>>>> >> explained >> >>>>>>>> that all wrong ). >>>>>>> >>>>>>> >>>>>>> You got it. Very simple delegation. You can unit test the beans >>>>>> >>>>>> >> CRUD, >> >>>>>>> and properties before you ever use it. And you can later make the >>>>>> >>>>>> >>>>>> beans >>>>>> >>>>>>> soapy. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> So my question is under this model it seems like if >>>>>>>> the underlying implementation changes, such as the column names in >>>>>>> >>>>>>> >> a >> >>>>>>>> table change, you end up having to fix all your beans plus all of >>>>>>> >>>>>>> >>>>>> your >>>>>> >>>>>>>> DAOs (as opposed to only having to change it one place if the >>>>>>> >>>>>>> >>>>>> DAOs are >>>>>> >>>>>>>> used to directly populate the beans). >>>>>>> >>>>>>> >>>>>>> The public interface of the bean stays the same. So the users of the >>>>>>> data model layer are not affected. The whole point of separating the >>>>>>> data layer is that if it changes, the other 2 layers are unaffected. >>>>>>> You would only fix the implementation of the bean or the dao that >>>>>> >>>>>> >> has >> >>>>>>> the changed table. Of course once you have data in the DB, you would >>>>>>> with the changed db have to do data conversion, so changes to the >>>>>>> physical db are very rare. >>>>>>> More realistic is that you would add a column or maybe a table, and >>>>>> >>>>>> >>>>>> add >>>>>> >>>>>>> a bean or a bean property. >>>>>>> >>>>>>> >>>>>>>> I'm guessing the reason for >>>>>>>> calling the db columns in the cached rowset might be so that the >>>>>>> >>>>>>> >>>>>> bean >>>>>> >>>>>>>> doesn't have to be populated in the DAO (although I'm not so sure >>>>>>> >>>>>>> >>>>>> why >>>>>> >>>>>>>> that would be so negative ). >>>>>>> >>>>>>> >>>>>>> DAO does retrieve and store in a disconnected row set. It just >>>>>> >>>>>> >>>>>> holds it >>>>>> >>>>>>> there. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> 2) If each bean ( ie ListNmBean ) is responsible for populating >>>>>>> >>>>>>> >>>>>> itself >>>>>> >>>>>>>> where do you put SQL to populate a Collection of beans? ( I >>>>>>> >>>>>>> >>>>>> apologize >>>>>> >>>>>>>> Vic if you do this somewhere in the application that I haven't >>>>>>> >>>>>>> >>>>>> found). >>>>>> >>>>>>>> In your architecture it looks like the DAOs are only really called >>>>>>>> from within beans themselves, so in order to get a Collection of >>>>>>>> ListNmBeans would I need to create a CollectionOfNameBeans object >>>>>>>> which would call a DAO that would populate me with ListNmBeans? >>>>>>>> >>>>>>> >>>>>>> That's the beauty. Most retrievals are multi row. The DAO has the ( >>>>>>> disconnected ) rowset. The rowset is your "collection" of rows. (No >>>>>> >>>>>> >>>>>> need >>>>>> >>>>>>> for a collection, when the rowset has the full metadata and is >>>>>>> disconnected) It contains multiple rows (no need for multiple beans >>>>>> >>>>>> >>>>>> and >>>>>> >>>>>>> garbage collection load). The Bean has iterate. It iterates the DAO >>>>>> >>>>>> >>>>>> ('s >>>>>> >>>>>>> rowset). Multi row retrievals like nameLst or multi row updates are >>>>>> >>>>>> >> a >> >>>>>>> synch. and easily unit testable at the bean level (with not web app >>>>>>> needed to unit test, the whole point of unit test it to test one >>>>>> >>>>>> >>>>>> thing). >>>>>> >>>>>>> >>>>>>>> 3) Using an architecture such as the webPIM app it looks like you >>>>>>>> would only need one type of bean to hold your main object's >>>>>>> >>>>>>> >> fields. >> >>>>>>>> For example I'd only need an EmployeeBean, and wouldn't need an >>>>>>>> EmployeeBean plus a Data Transfer Object EmployeeBean. >>>>>>> >>>>>>> >>>>>>> Yes. KISS >>>>>>> >>>>>>> >>>>>>>> In the webPIM >>>>>>>> app am I correct in assuming objects such as the NameLstBean act >>>>>>> >>>>>>> >>>>>> as a >>>>>> >>>>>>>> Data Transfer Object or Value Object and also acts as what I hear >>>>>>>> other's mention as an Entity or Session bean? >>>>>>> >>>>>>> >>>>>>> Value Object and Data Transfer Object and Business Objects are just >>>>>>> Beans. The less you do, the faster you write it, the less code, the >>>>>> >>>>>> >>>>>> less >>>>>> >>>>>>> has to go trough CPU, the less code, the less bugs, less GC. >>>>>> >>>>>> >> Benefits >> >>>>>>> pile on. Plus easier to debug. >>>>>>> >>>>>>> EJBs (and design patterns to try to make them palatable) is >>>>>> >>>>>> >>>>>> something I >>>>>> >>>>>>> r USED TO USE, but I do not use them anymore (in fact my new and >>>>>>> existing clients that might have them are having the EJBs removed). >>>>>> >>>>>> >>>>>> You >>>>>> >>>>>>> do not need EJB to do J2EE. Look at some of my post about software >>>>>>> reality . com and the first 101 reasons not to use EJB. EJB only >>>>>> >>>>>> >>>>>> work in >>>>>> >>>>>>> lab conditions and most organizations remove them eventually. EJB is >>>>>> >>>>>> >> a >> >>>>>>> technology in search of a problem. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> 4) I take it each bean would contain all different overloaded >>>>>>> >>>>>>> >>>>>> populate >>>>>> >>>>>>>> methods for different ways you would want to return an Employee? >>>>>>> >>>>>>> >> For >> >>>>>>>> example "populate( int employeeId )" or "populate( String >>>>>>> >>>>>>> >> firstName, >> >>>>>>>> String Last Name )" ? >>>>>>> >>>>>>> >>>>>>> Yup. >>>>>>> Do you see how simple this design is? (especially compare to pet >>>>>> >>>>>> >> store >> >>>>>>> type designs) >>>>>>> A bean and a DAO (DAO with a "collection" of rows") >>>>>>> It is always better to look at a real application and code. >>>>>>> Most clients can be talked into removing EJB and other objects they >>>>>> >>>>>> >> do >> >>>>>>> not use, if it is helpful to them. >>>>>>> Simple = flexible = less effort. >>>>>>> >>>>>>> Actually, anyone can build a web app. But a software engineer can >>>>>> >>>>>> >> help >> >>>>>>> you use less resources and effort and make it more scalable and >>>>>>> maintainable. >>>>>>> >>>>>>> Hth, V. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks for any help with this. >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> STEVE WILKINSON wrote: >>>>>> >>>>>>> Given the comments from Craig on not using Value Objects as form >>>>>> >>>>>> >> beans >> >>>>>>> our project is taking the following approach. >>>>>>> >>>>>>> We are creating a "helper" class to transform our ValueObject (Data >>>>>>> Transfer Object as we call it) into a form bean (Strings, Boolean, >>>>>> >>>>>> >> and >> >>>>>>> boolean types only) and the reverse. I started this effort by >>>>>> >>>>>> >> looking >> >>>>>>> at the code within the beanutil package that is part of commons. >>>>>>> Unfortunately, object composition is not supported (User object >>>>>> >>>>>> >>>>>> contains >>>>>> >>>>>>> an Address object) within the commons code base. So, I've taken to >>>>>>> writing our own transformation helper and take advantage reflection >>>>>> >>>>>> >>>>>> and >>>>>> >>>>>>> the convertion utilities provided in the commons package. Granted >>>>>> >>>>>> >> this >> >>>>>>> is not an approach that a small project should take, but ours is a >>>>>>> fairly large project and we wanted to create a "Helper class" to >>>>>> >>>>>> >>>>>> assist >>>>>> >>>>>>> in transforming the data between tiers. The idea is that each >>>>>> >>>>>> >>>>>> interface >>>>>> >>>>>>> (Struts being the HTTP interface) will have it's own helper class to >>>>>>> assist in this. I will reduce a little coding, but provide easy >>>>>>> tranformation of the data between tiers. >>>>>>> >>>>>>> Currently, the transformation helper class is dependent on our own >>>>>>> package structure. :-( I'm hoping to be able to refactor this so >>>>>> >>>>>> >> that >> >>>>>>> it's configurable like the ConvertUtils does and I'll offer it up if >>>>>>> people are >>>>>>> interested. Also, since we are only prototyping right now, I don't >>>>>>> provide support for Collections, but I do provide support for Object >>>>>>> Array types (e.g. User[] user). The intent is to provide Collection >>>>>>> support in the future, but I must utilize a "type safe" collection >>>>>> >>>>>> >>>>>> that >>>>>> >>>>>>> is initalized with "type" or it's class that will be stored at >>>>>>> initialization in the target object so the transformation utility >>>>>> >>>>>> >>>>>> knows >>>>>> >>>>>>> what class to create when transforming an object from one >>>>>> >>>>>> >>>>>> collection to >>>>>> >>>>>>> the other. We are using the same names for our attributes and >>>>>> >>>>>> >> classes, >> >>>>>>> it's just different data types. The DTO (VO) contains mixed type, >>>>>>> java.sql.Date, java.lang.Float, etc. The FormBean >>>>>>> currently only has String, Boolean and boolean types. >>>>>>> >>>>>>> Hope this helps give an idea on another approach. >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> From: Ted Husted <[EMAIL PROTECTED]> >>>>>>>> Reply-To: [EMAIL PROTECTED] >>>>>>>> To: Struts Users Mailing List <[EMAIL PROTECTED]> >>>>>>>> Subject: Re: Value object doubt !!! >>>>>>>> Date: Fri, 24 May 2002 08:47:27 -0400 >>>>>>>> >>>>>>>> The best stategy will depend on what else is going on with your >>>>>>>> application. >>>>>>>> >>>>>>>> The ActionForm is really part of the control layer and so can >>>>>>> >>>>>>> >>>>>> interact >>>>>> >>>>>>>> with objects on both the presentation and business layers. >>>>>>>> >>>>>>>> A generally useful approach is to put a factory method on the >>>>>>> >>>>>>> >>>>>> ActionForm >>>>>> >>>>>>>> that returns your value object. >>>>>>>> >>>>>>>> This neatly encapsulates the data transfer. All the Action has to >>>>>>> >>>>>>> >>>>>> do is >>>>>> >>>>>>>> call the method and pass along the result. >>>>>>>> >>>>>>>> Which I guess is your #2. >>>>>>>> >>>>>>>> -- Ted Husted, Husted dot Com, Fairport NY US >>>>>>>> -- Developing Java Web Applications with Struts >>>>>>>> -- Tel: +1 585 737-3463 >>>>>>>> -- Web: http://husted.com/about/services >>>>>>>> >>>>>>>> >>>>>>>> Radhika Nadkarni wrote: >>>>>>>> >>>>>>>>> hi, >>>>>>>>> Im having an action Form. Im using Value object for data >>>>>>>> >>>>>>>> >>>>>> conversions. >>>>>> >>>>>>>>> Now my problem is i have two scenarios for implementing the same >>>>>>>> >>>>>>>> >>>>>> : - >>>>>> >>>>>>>>> 1) Value object will be separate >>>>>>>>> 2) Value object will be composed within the Form Bean. >>>>>>>>> Can anyone tell me which is the best strategy out of the two ? >>>>>>>>> >>>>>>>>> _________________________________________________________________ >>>>>>>>> Get your FREE download of MSN Explorer at >>>>>>>> >>>>>>>> >>>>>>>> http://explorer.msn.com/intl.asp. >>>>>>>> >>>>>>>>> -- >>>>>>>>> To unsubscribe, e-mail: >>>>>>>> >>>>>>>> >>>>>>>> <mailto:[EMAIL PROTECTED]> >>>>>>>> >>>>>>>>> For additional commands, e-mail: >>>>>>>> >>>>>>>> >>>>>>>> <mailto:[EMAIL PROTECTED]> >>>>>>>> >>>>>>>> -- >>>>>>>> To unsubscribe, e-mail: >>>>>>>> <mailto:[EMAIL PROTECTED]> >>>>>>>> For additional commands, e-mail: >>>>>>>> <mailto:[EMAIL PROTECTED]> >>>>>>>> >>>>>>> >>>>>>> _________________________________________________________________ >>>>>>> Chat with friends online, try MSN Messenger: >>>>>> >>>>>> >> http://messenger.msn.com >> >>>>>>> >>>>>>> -- >>>>>>> To unsubscribe, e-mail: >>>>>>> <mailto:[EMAIL PROTECTED]> >>>>>>> For additional commands, e-mail: >>>>>>> <mailto:[EMAIL PROTECTED]> >>>>>>> >>>>>> >>>>>> -- >>>>>> To unsubscribe, e-mail: >>>>>> <mailto:[EMAIL PROTECTED]> >>>>>> For additional commands, e-mail: >>>>>> <mailto:[EMAIL PROTECTED]> >>>>>> >>>>> >>>>> _________________________________________________________________ >>>>> Join the world's largest e-mail service with MSN Hotmail. >>>>> http://www.hotmail.com >>>>> >>>>> >>>>> -- >>>>> To unsubscribe, e-mail: >>>>> <mailto:[EMAIL PROTECTED]> >>>>> For additional commands, e-mail: >>>>> <mailto:[EMAIL PROTECTED]> >>>>> >>>> >>>> >>>> -- >>>> To unsubscribe, e-mail: >>>> <mailto:[EMAIL PROTECTED]> >>>> For additional commands, e-mail: >>>> <mailto:[EMAIL PROTECTED]> >>>> >>> >>> -- >>> To unsubscribe, e-mail: >> >> >> <mailto:[EMAIL PROTECTED]> >> >>> For additional commands, e-mail: >> >> >> <mailto:[EMAIL PROTECTED]> >> >> >> >> -- >> To unsubscribe, e-mail: >> <mailto:[EMAIL PROTECTED]> >> For additional commands, e-mail: >> <mailto:[EMAIL PROTECTED]> >> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
