Seam and (or vs) Tapestry 5

[mgrouch]

Can Seam coexist and work with Tapestry 5? Does this kind of integration even make sense? I haven't used Tapestry but I've heart good things about it
(esp performance) compared to JSF.
There are some IOC/hibernate/Spring modules in Tapestry 5 and it is also annotation based. I didn't find anything about Seam with Tapestry 5.
Any thoughts about it?

Thanks

[tony.herstell1]

These are different paradigms.

I have used tapestry and Seam (JSF) and Seam has a number of significant advantages over tapestry in my opinion...

I would recommend you do a spike of your main program thread in both Seam and Tapestry and by then you would be able to tell for yourself.

A point to consider is that Seam/JSF is pretty much where Sun (JAVA EE) is going as even Seam is a reference implementation of a JSR (http://jcp.org/en/jsr/detail?id=299) so its very "mainstream" and transportable.

I hope this helps.

[tony.herstell1]

Sorry...
> reference implementation
Thats a bit strong.. but it's helping form the spec I believe.

[norman.richards]

As far as I know, nobody has looked at Tapestry support. Seam core is more and more separate from JSF now (see the GWT support) that it wouldn't surprise me if it is close to being a reasonable thing. My personal recommendation is to stick with JSF. I have nothing bad to say about Tapestry, but JSF works really well now and has the momentum of standardization behind it improving it.

That being said, we'd definitely welcome anyone interested in tapestry integration to give it a shot.

[thejavafreak]

Yes you can. But you'll need to do some extra work integrating Tapestry with Seam.

[mgrouch]

Seam doesn't support injection into servlets ans JSP lifecycle methods.
It only does it for JSF. Would it possible (or make sense) to have this type of functionality?

[norman.richards]

You can use the seam filter to make sure you have seam initialized around a servlet. I suppose it wouldn't take much effort to add another filter to handle bijection, but I'm not entirely sure why someone would want to do that.

[mgrouch]

Tapestry has some advantages over JSF. One of them is performance.
AFAIK it compiles code against bean code so no reflection overhead +
more errors can be discovered at compile time compared to facelets.
JSF performance is one of the issues which prevents its wider adoption.
JSF also requires much more memory on server side.

Tapestry 5 seems to be major rewrite of tapestry so use annotations, etc.
So I wonder in which applications it would make sense to use it vs
Seam/JSF combo.

[norman.richards]

Based in my experience with production applications, JSF is not a significant performance concern. I don't know if that is true across the board, but that's my experience. Honestly, I would suspect the overhead of Seam itself is larger than the overhead of JSF, but again I don't see any performance issues in production apps because of it.

[michael.yuan]

Reflection by itself should not introduce a big performance hit. As Norman said, Seam uses much more reflection than JSF. Yet, in our tests, adding Seam only decrease performance by 5% to 10%.

The big performance problem in JSF is the need to serialize objects. You can reduce that by using server side state saving but than you need more server memory and reduce clustering performance. However, as Norman said, we do not see "performance" as a big issue for JSF at all. It performs "good enough" for the vast majority of web applications.

Having said that, I'd love to see Seam integrated with other web frameworks because not everyone is sold on JSF. But given the resources we have, this type of integration will probably need to come from the community ...

[mgrouch]

We always use server side state saving but still observe slow performance with JSF. I'm pretty sure it is attributed to JSF (and not Seam). JSF needs to operate on a tree of components (do various searches on it) and there are 6 phases when it could do that. There seems to be some HTML reformatting happening on server side as well (by ajax4jsf). All of it makes it (in my experience) 5 times slower than same tasks with JSP.
(yes it is that bad).
All of it makes people to look for new alternatives. Tapestry 5 (which is new, annotation based) looks interesting as well as using Seam with no JSF. In JSF world pages are NOT COMPILED against beans so many errors can't be discovered at build time.

[michael.yuan]

So, mgrouch, are you volunteering to help us out with Tapestry integration? :) It should not be too hard since as Norman indicated, the Seam core has no dependency on JSF ...

Do you want to give it a try? We'd appreciate it. :)

[mgrouch]

My current work schedule makes it impossible. Might be someone from tapestry developers team would be interested in doing it...

[mgrouch]

BTW in tapestry 5 they are building brand new IoC controller based on annotations and javassist byte code manipulation. Might be you guys
could convince them to stop doing it and just use Seam for it.

[epbernard]

"mgrouch" wrote:
All of it makes it (in my experience) 5 times slower than same tasks with JSP.

Do you mean your 200ms task involving html, ejb, database access now takes 1s, or do you mean your 200ms now takes 220ms?