Discussion....What is your favorite web framework?

[Danno]

I like helping people, but this newsgroup needs some discussion
sometimes. So what is your favorite web framework and why?

I'll throw in that mine is Seam. This web framework is the only thing
really close to my idea of a utopian web framework. I always believed
that business functionality should always be stored as a session bean
and never as a web based bean. The reason? reuse. That session bean if
opted should be reused as a webservice if you ever need to.

Seam exposes those business oriented session beans through its resolver
to JSF. By doing so, it also relieves us from managing a huge
faces-config.xml.

Are there problems? Sure, all web frameworks have problems. Seam tends
to have some parts of the web integrated into session beans. If you
look at the hotel logout example you will see what I mean. I think
eventually this will not be the case. There are other minor annoyances
but not big enough to harp on them.

So what is your fave?

 

[Chris Smith]

I like helping people, but this newsgroup needs some discussion
sometimes. So what is your favorite web framework and why?

I'll throw in that mine is Seam.

Is there a good web site to learn about this from a technical
standpoint? I started with Google, which sent me to
http://www.jboss.com/products/seam, but then I stopped after:

JBoss Seam is a powerful new application framework to build next
generation Web 2.0 applications by unifying and integrating popular
service oriented architecture (SOA) technologies like Asynchronous
JavaScript and XML(AJAX), Java Server Faces(JSF), Enterprise Java
Beans(EJB3), Java Portlets and Business Process Management(BPM) and
workflow.

Wow! Someone is either joking, or needs to separate reality from
buzzwords. Not to mention, that, unless I've got my rough assignment of
actual meaning to buzzwords all wrong, none of those things actually
have anything to do with SOA.

I'm listening to the "in-depth webinar" now. We'll see.

 

[Danno]

Is there a good web site to learn about this from a technical
standpoint? I started with Google, which sent me to
http://www.jboss.com/products/seam, but then I stopped after:

JBoss Seam is a powerful new application framework to build next
generation Web 2.0 applications by unifying and integrating popular
service oriented architecture (SOA) technologies like Asynchronous
JavaScript and XML(AJAX), Java Server Faces(JSF), Enterprise Java
Beans(EJB3), Java Portlets and Business Process Management(BPM) and
workflow.

Wow! Someone is either joking, or needs to separate reality from
buzzwords. Not to mention, that, unless I've got my rough assignment of
actual meaning to buzzwords all wrong, none of those things actually
have anything to do with SOA.

I'm listening to the "in-depth webinar" now. We'll see.

I forgot. Is it you or Oliver that is into JSF?

 

[Chris Smith]

I forgot. Is it you or Oliver that is into JSF?

I'm certainly somewhat "into" JSF. Depending on what you mean by that,
I may object a little. I'm not thrilled with all the steps involved in
creating custom components, for example. Outside of that, though, it
works pretty well.

 

[Chris Smith]

So I watched the webinar about Seam, which I'm happy to say contains
considerably more actual meaningful statements than the product web
page.

First of all, that conversation thing is incredibly cool! It's a nice
feeling when something steps in an solves a problem that I didn't even
know I had because I was so accustomed to working around it. As it
turns out, I'm starting a new web application development project pretty
soon, and I'm now deciding whether to look into using Seam, or to try to
re-implement the conversation concept outside of Seam (which doesn't
look too hard). It seems almost silly to go back and do things the hard
way now.

It's also nice (though hardly revolutionary) that they've moved managed
bean declarations out of faces-config and into annotations. That's a
direction that should be encouraged. The JavaScript remoting stuff is
rather nice, as well, though abstraction is lacking and the
implementation is definitely showing.

That said, I'm concerned that Seam tries to push so much functionality
back onto other software, and introduces too many new languages and
dependencies. From that presentation, it looks like in order to be
competent working on a Seam project, a developer now needs to know JSF,
EJB3, Hibernate Validator (which I'm unsure whether it requires the core
Hibernate or not), possibly jBPM (a "business process" description
language), jPDL (a navigation description language), and perhaps more
that I've missed. A lot of complexity seems to arise from integrating
Seam with other EJB and even JBoss-specific APIs and products. This is
a shame.

 

[Danno]

So I watched the webinar about Seam, which I'm happy to say contains
considerably more actual meaningful statements than the product web
page.
LMAO!

First of all, that conversation thing is incredibly cool! It's a nice
feeling when something steps in an solves a problem that I didn't even
know I had because I was so accustomed to working around it. As it
turns out, I'm starting a new web application development project pretty
soon, and I'm now deciding whether to look into using Seam, or to try to
re-implement the conversation concept outside of Seam (which doesn't
look too hard). It seems almost silly to go back and do things the hard
way now.

Fair point.

It's also nice (though hardly revolutionary) that they've moved managed
bean declarations out of faces-config and into annotations. That's a
direction that should be encouraged. The JavaScript remoting stuff is
rather nice, as well, though abstraction is lacking and the
implementation is definitely showing.

Haven't tried that out yet. I am still excited about the regular stuff
and working on that

That said, I'm concerned that Seam tries to push so much functionality
back onto other software, and introduces too many new languages and
dependencies. From that presentation, it looks like in order to be
competent working on a Seam project, a developer now needs to know JSF,
EJB3, Hibernate Validator (which I'm unsure whether it requires the core
Hibernate or not), possibly jBPM (a "business process" description
language), jPDL (a navigation description language), and perhaps more
that I've missed. A lot of complexity seems to arise from integrating
Seam with other EJB and even JBoss-specific APIs and products. This is
a shame.

Well, I guess that is one perspective.

One thing I have always wanted was validation at the entity pojo level.
Which can optionally be adhered to on the web level.

I am excited about using jBPM and jPDL, and I don't consider that
acronym overload. I t just extracts out the business process and page
navigation layer away from web programming. I would like to use jBPM
and jPDL more though the need for me to use it has not come up yet.
Gavin King is trying to make Seam agnostic, and not rely on JBoss,
though it quite a bit is still married to JBoss products.

Lately, Gavin submitted JSR 299 for Web Beans, which is JBoss' attempt
to make it a product that's not exclusive to JBoss.

http://jcp.org/en/jsr/detail?id=299

I'll be keeping an eye out on this one.

Danno

 

[Chris Smith]

Well, I guess that is one perspective.

One thing I have always wanted was validation at the entity pojo level.
Which can optionally be adhered to on the web level.

This may relate to where we're coming from. I'm used to doing Java
server-side development without the big J2EE behemoth. From this
perspective, EJB is the point at which one really has to abandon
flexibility and commit to the one true way. EJB 3 claims to fix this,
and it may succeed to a point. I'm not terribly familiar with the
version 3 spec at this point.

Still, I get nervous when Seam's primary stated goal is to integrate JSF
with EJBs. Some things have not changed with EJB3, and I don't really
want to integrate with EJBs. It appears likely that Seam either forces
this, or makes it sufficiently difficult to avoid that it's not a
worthwhile option. So what does that mean? I am not allowed to use
threads. I am not allowed to install a security manager. I am not
allowed to use a custom class loaders. I am not allowed to load a
library with JNI. All of these things are still present in the EJB 3
spec, and these are severely crippling limitations which I don't want to
invite upon myself (especially the bit about threads... what were they
thinking?!?).

I am excited about using jBPM and jPDL, and I don't consider that
acronym overload. It just extracts out the business process and page
navigation layer away from web programming.

I've yet to get a good idea of what these pieces do, and how their
language is superior to Java for defining processes like this. In any
case, I'll just say I'm extremely skeptical about the idea of
abstracting page navigation away from web programming. What would page
navigation even mean in the absence of web programming?

Lately, Gavin submitted JSR 299 for Web Beans, which is JBoss' attempt
to make it a product that's not exclusive to JBoss.

http://jcp.org/en/jsr/detail?id=299

I'll keep an eye on it as well, but it's still married to EJB. I may
just try to take the nice bits of Seam (namely, the conversation stuff)
and implement them for plain JSF via EL resolvers.

 

[Danno]

This may relate to where we're coming from. I'm used to doing Java
server-side development without the big J2EE behemoth. From this
perspective, EJB is the point at which one really has to abandon
flexibility and commit to the one true way. EJB 3 claims to fix this,
and it may succeed to a point. I'm not terribly familiar with the
version 3 spec at this point.

Still, I get nervous when Seam's primary stated goal is to integrate JSF
with EJBs.

Some things have not changed with EJB3, and I don't really
want to integrate with EJBs. It appears likely that Seam either forces
this, or makes it sufficiently difficult to avoid that it's not a
worthwhile option. So what does that mean? I am not allowed to use
threads. I am not allowed to install a security manager. I am not
allowed to use a custom class loaders. I am not allowed to load a
library with JNI. All of these things are still present in the EJB 3
spec, and these are severely crippling limitations which I don't want to
invite upon myself (especially the bit about threads... what were they
thinking?!?).

JNI?!?!?!?! WOW! Well, in a J2EE world, I believe you can create a JMX
object that uses JNI, you can then patch that through into a session
bean. Never attempted it, but for me, it's worth a gander.

I've yet to get a good idea of what these pieces do, and how their
language is superior to Java for defining processes like this. In any
case, I'll just say I'm extremely skeptical about the idea of
abstracting page navigation away from web programming. What would page
navigation even mean in the absence of web programming?


I'll keep an eye on it as well, but it's still married to EJB. I may
just try to take the nice bits of Seam (namely, the conversation stuff)
and implement them for plain JSF via EL resolvers.

What ORM, do you use, if you do?

 

[Chris Smith]

JNI?!?!?!?! WOW! Well, in a J2EE world, I believe you can create a JMX
object that uses JNI, you can then patch that through into a session
bean. Never attempted it, but for me, it's worth a gander.

JNI is rather a minor concern for me. Threads are a huge concern, as
are class loaders and security managers.

What ORM, do you use, if you do?

Of the two web-based projects I'm involved in, one uses Hibernate 3, and
the other uses a mix between a home-grown object-relational mapper for
certain tasks and plain SQL for others.