Torsten, great lead! Thanks for the info, I am going to check it out and if it works
as reported it will save many hours.
Again, thanks for the pointer (oops, this is a Java group, I should have said
"reference" :)
--Steve
> -----Original Message-----
> From: Torsten Terp [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 19, 2001 11:33 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [EJB] java report article says "bye-bye struts"
>
>
> Hi,
>
> You should definetely check out EJBDoclet on sourgeforge.
> (http://sourceforge.net/projects/ejbdoclet/) It is javaDoc plugin
> that creates both valueobjects, remote and home interfaces interfaces,
> primary key classes you name it!! It is independent of the appserver
> (it is basically an ant task which generates the files based on tags
> in your main ejb class. In addition to being appserver independent it
> supports some extra usefull stuff for a couple of appservers
> (cant remember
> which) I use it with jBoss (excellent stuff too :-) and it is pretty
> well integrated since some (or all??) of the developers work on jBoss
> too.
>
> It simply amazing, how much time this little puppy can save you!! I
> thank these guys every day I goto work :-)
>
> ^terp
>
>
> > -----Original Message-----
> > From: Ritter, Steve [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, June 19, 2001 5:13 PM
> > To: '[EMAIL PROTECTED]'
> > Subject: RE: [EJB] java report article says "bye-bye struts"
> >
> >
> > Hi Bob, you make some great comments in this posting. The
> scenario you describe in "keeping value objects in sync with
> > ActionForms" will strike a familiar chord with many developers.
> >
> > Check this out, the Appserver that I am most familiar with
> is unfortunately a very small player in the j2ee appserver
> > market but has some key features that I love to rely on
> (the appserver is PowerTier from Persistence Software). One
> > feature that helps out here is the auto-generation of
> "pass-by-value" objects for each CMPD Entity bean that is generated
> > for you. Although it is a bit "heavy", it is a great time
> saver and allows you to keep entities and value objects in
> > synch transparently. They even generate
> ClassHome.create(ClassValue) methods for you so you can
> create (and update) your
> > entities directly with your Value (state) object. No more
> custom entity methods that simply copy one field to another.
> >
> > How many other ejb containers do this? I don't have a
> whole bunch of experience on other containers and I am really curious.
> >
> > In anycase, I think that for seemless EJB/WebApp
> integration you hit the nail right on the head. We need to automate
> > value bean management and we need standard ways of
> describing our solutions.
> >
> > We'll save "security context passing" and session
> management for later. :)
> >
> > --Steve
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]]
> > > Sent: Tuesday, June 19, 2001 7:45 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: [EJB] java report article says "bye-bye struts"
> > >
> > >
> > >
> > > Just a few comments. I picked up a book while out at JavaOne
> > > called "core
> > > J2EE patterns" which is hot off the press and written by a
> > > few guys that
> > > work at Sun Java Center. Personally, I did not find any
> > > breakthrough ideas
> > > in here, but it is a well written book that also describes
> > > what not to do
> > > and effectively demonstrated how to turn bad design into good
> > > design (and
> > > provides nice pattern names for these design strategies). It
> > > solidifies what
> > > most of us have been doing for the past year or so on J2EE
> > > projects. I think
> > > that any EJB support included in Struts should be structured
> > > around the
> > > patterns in this book.
> > >
> > > For example:
> > > *Value Objects to exchange business data with EJBs
> > > *Business Delegate to reduce coupling between client and
> > > business services
> > >
> > > My greatest concern with Struts-EJB integration is how we
> can minimize
> > > development time, yet still come up with an intuitive and
> > > flexible design.
> > > The ActionForms are the part that is still bothering me.
> > > Proper design would
> > > say that ActionForms belong only on the client, to mirror the
> > > data presented
> > > on HTML forms. But you need to build a similar structure
> > > (Value Object) to
> > > get this data from the client tier to the EJB tier. I
> just completed a
> > > project where we started off doing this, but soon noticed
> > > that ActionForms
> > > and ValueObjects were almost identical, and trying to keep to
> > > two in synch
> > > was a mess. So, we used the ActionForm for both purposes and
> > > passed them
> > > directly to the EJB tier. Coupling could have been slightly
> > > reduced by using
> > > an interface, but then you are back to keeping 2 objects in
> > > synch again. Of
> > > course this design only works well when the EJB data model
> > > are Client data
> > > model are similar, but this is not always the case. There
> > > were a few cases
> > > where we did not have a one-to-one mapping and then things
> > > were not very
> > > pretty. The point I am trying to make here is we need a
> flexible, and
> > > dynamic, way of mapping ActionForms to ValueObjects then
> to EJBs.
> > >
> > > Part of this will be solved if the next version of Struts
> > > supports dynamic
> > > creation of the ActionForms, as listed in the 1.1 to-do (no
> > > volunteer yet?).
> > > (Has it been decided how this will be dynamic? What will be
> > > used to specify
> > > how to build the ActionForms- is the plan to do this directly
> > > from the JSP?)
> > > Then, the developer will need to supply the ValueObjects and
> > > utilize some
> > > sort of mapping mechanism between the DynamicActionForm and
> > > ValueObject
> > > (such as an enhanced version of the PropertyUtils). I think
> > > this would fit
> > > with the idea of a Business Delegate- to decouple the client
> > > from EJBs.
> > >
> > > What do you think?
> > >
> > >
> > > -Bob
> > >
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: SCHACHTER,MICHAEL (HP-NewJersey,ex2)
> [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, June 18, 2001 5:36 PM
> > > To: '[EMAIL PROTECTED]'
> > > Subject: RE: [EJB] java report article says "bye-bye struts"
> > >
> > >
> > > To Anyone It Concerns,
> > >
> > > Although I'm relatively new to EJB's, I'm listed on the
> 1.1 TODO list
> > > to add better EJB support/design patterns. Ideas that anyone
> > > has about
> > > things that they'd like Struts to do with EJB's will
> > > definately help me
> > > along with this and help Struts quiet this EJB fud. I'm
> looking to get
> > > started on this soon, and anyone who wants to is more
> than welcome to
> > > help me out.
> > >
> > > - Mike
> > >
> > > -----Original Message-----
> > > From: Bill G [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, June 18, 2001 5:04 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: java report article says "bye-bye struts"
> > >
> > >
> > > Hi Craig,
> > >
> > > "Although excellent in dealing with Web-based applications,
> > > Struts is not
> > > ready to take on EJB."
> > >
> > > This is a concern of mine as well but as a newbie to this
> > > technology, I am
> > > wondering how to adopt the Struts framework knowing that I
> > > will move to
> > > EJB's. Is it worth starting with Struts with the idea of
> > > moving to EJB's or
> > > what? Any info on this matter is seriously appreciated!
> > >
> > > Thanks
> > > BG...
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, June 18, 2001 11:14 AM
> > > To: '[EMAIL PROTECTED]'
> > > Subject: RE: java report article says "bye-bye struts"
> > >
> > >
> > >
> > >
> > > On Mon, 18 Jun 2001, Ritter, Steve wrote:
> > >
> > > > Hi Hal, yeah I read the same article and couldn't help
> but laugh.
> > > > Prashant really made some outlandish comments and
> hopefully those
> > > > comments will diminish any negative impact his article
> might have on
> > > > Struts (or, the adoption of Struts I should say).
> > > >
> > > > Craig, if you read this thread it might not be a bad
> idea to send a
> > > > quick email to the editor's of Java Report and let them
> know about
> > > > some of the mis-leading statements. Sounds like their
> review board
> > > > needs a little re-org.
> > > >
> > >
> > > Looks like I'll have to go buy a copy -- I don't pay a lot of
> > > attention to
> > > trade magazines in print, because production cycles make them
> > > so far out
> > > of date.
> > >
> > > Judging from the many thank-you's I've received for the 1.0 final
> > > release, I wouldn't worry to much about negative impact on Struts
> > > adoption. :-)
> > >
> > > > --Steve
> > > >
> > >
> > > Craig
> > >
> > > > > -----Original Message-----
> > > > > From: Deadman, Hal [mailto:[EMAIL PROTECTED]]
> > > > > Sent: Monday, June 18, 2001 7:52 AM
> > > > > To: 'Struts List'
> > > > > Subject: java report article says "bye-bye struts"
> > > > >
> > > > >
> > > > > Clearly there are too many java magazines and they will
> > > > > publish anything. In
> > > > > the July issue of Java Report there is an article titled
> > > > > "Writing a Reusable
> > > > > Implementation of the MVC Design Pattern" by Prashant Sarode
> > > > > from Brience.
> > > > > It's interesting because it has a section title of "Bye-Bye
> > > > > Struts". The
> > > > > section starts out as follows:
> > > > >
> > > > > "While the Struts framework is a powerful idea, it is not yet
> > > > > a product.
> > > > > Although excellent in dealing with Web-based applications,
> > > > > Struts is not
> > > > > ready to take on EJB."
> > > > >
> > > > > There are other gems in the article but I won't reproduce
> > > > > them all here.
> > > > >
> > > > > The premise of the article is that the author went
> > > looking for an MVC
> > > > > framework. He found the Blueprint document and liked that but
> > > > > it was too
> > > > > complicated. He then found Struts but apparently it didn't
> > > > > meet his need for
> > > > > "a reusable implementation of the MVC pattern." Prashant must
> > > > > be a hard man
> > > > > to please. I think he wants one framework that can be used
> > > > > for both web
> > > > > applications and desktop applications. Personally I would
> > > > > rather share the
> > > > > model components and let my MVC framworks be a little less
> > > > > abstract and more
> > > > > useful to the task at hand.
> > > > >
> > > > > I couldn't find the article on-line. I just skimmed the rest
> > > > > of the article
> > > > > because it it was hard to concentrate or take it seriously
> > > > > after the Bye-Bye
> > > > > Struts section.
> > > > >
> > > > > Hal
> > > > >
> > > >
> > >
> >
> >
>
