Last I checked servlets / jsp were part of J2EE.
--
"His comrades fought beside him, Van Owen and the rest...
But of all the thompson gunners- Roland was the best."
Josh McDonald
Analyst Programmer
Information Technology
Ph: 61 7 3006 6460
Email: [EMAIL PROTECTED]
>>> [EMAIL PROTECTED] 14/12/2005 4:31:21 pm >>>
Preston, none of those examples are J2EE. They can be used with J2EE
but
they have nothing to do with anything beyond J2SE.
On 12/13/05, Preston Crawford <[EMAIL PROTECTED]> wrote:
>
> > I don't know what the future will hold. JSF may win the day on
nothing
> > but marketing alone. It has the force of being a "standard", and
while
> > not all standards ultimately succeed, it certainly is a leg up on
other
>
> I would argue that with Java (J2EE specifically) "standards" have
largely
> just "emerged". Think of all the examples.
>
> Tomcat
> Ant
> Struts
> JUnit
> Hibernate
>
> That's, by and large, the "standard" J2EE toolkit. And by that I mean
that
> while we may have WebSphere, Tapestry, Maven, EJBs, etc. there's a
certain
> concensus out there and the tools in the first list are what have
the
> mindshare now.
>
> So my point of interest is this. JSF, from what I'm seeing here
> (especially when the actual developers of Struts talk about their
reasons
> for jumping to JSF) and reading elsewhere is actually succeeding IN
SPITE
> of the fact that it's not sitting in the OpenSource non-standard
seat, as
> Tapestry is. I find this interesting. It was bound to happen
eventually,
> that one of Sun's reference implementations would actually become a
> standard. I know, EJB is a standard. But look how many people have
been
> abandoning that in favor of more lightweight solutions, once those
> solutions presented themselves.
>
> So I think the fact that JSF is getting traction IN SPITE of the fact
that
> it isn't quite as open, hasn't been open sourced as long as Tapestry,
etc.
> is a testament to the fact that developers appear to like it. I just
> wanted to know (and you all have been immensely helpful in this
respect)
> if you could get done with it, what you can with Struts. Thus the
question
> wasn't "Is JSF better than Struts?" The question was "Is JSF ready?"
>
> And that is the question for me. I know what I can and can't do in
Struts.
> I've been programming with it for 5 years. I know its power and I
also
> know I've been involved with some amazingly convoluted hacks to make
it do
> what we needed. A framework that handles more of the
request/response
> plumbing for me is welcome. A framework where *maybe* I can use tools
that
> are WYSIWYG if I want is appealling after 5 years of hand-coding XML
> descriptor files that are gigantic. A framework that handles requests
and
> responses and doesn't push as far back into the business tier is
welcome
> to me.
>
> So I like the idea of JSF. Just like I like the idea of Tapestry and
even
> Ruby on Rails. I just wanted to know if you could write a JSF app
today
> and be reasonably sure that you could do easy validation on the
server, be
> relatively efficient in it and not run into major snafus with
application
> server differences.
>
> Preston
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
"You can lead a horse to water but you cannot make it float on its
back."
~Dakota Jack~
***************************************************************************
Messages included in this e-mail and any of its attachments are those
of the author unless specifically stated to represent WorkCover Queensland. The
contents of this message are to be used for the intended purpose only and are
to be kept confidential at all times.
This message may contain privileged information directed only to the intended
addressee/s. Accidental receipt of this information should be deleted promptly
and the sender notified.
This e-mail has been scanned by Sophos for known viruses.
However, no warranty nor liability is implied in this respect.
****************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
