6:34 a.m.
I've started documenting the (uncommitted) performance improvements
I've enabled:
http://www.seamframework.org/Documentation/HTTPClientserverOptimizationSt...
Later this week I'm going to roll out these changes on sfwk.org and
we'll see if it all works as expected. I'm also going to integrate the
Seam Remoting patch that allows caching of JS interfaces of several
components.
Please have a look at the doc and tell me what I've been missing.
There is also one more thing we should discuss at some point for Seam 3:
We are duplicating lots of functionality in Seam that any JAX RS
implementation has. We should probably drop SeamResourceServlet and
maybe even SeamFilter in Seam3 and rebuild what we need on top of JAX-
RS. The downside is that we'd create a dependency on a JAX-RS
implementation. OTOH almost anyone might want one of these in the
future anyway.
12:46 a.m.
Excellent start Christian. I have no doubt the enhancements you are
introducing are going to be well received and perhaps will even stir up some
feedback from Seam users who have gone through the process of optimizing
their Seam-based applications.
One point you may want to mention is that users should not be discouraged if
they put effort into an optimization and it turns out to have no effect.
This disappointment has often discouraged me from pursing optimization
techniques in past projects because I just didn't see any blue sky (time and
money was the devil's advocate). In light of that, you might want to
recommend ways to determine whether you made an improvement. For instance,
is there a bandwidth throttle tool you recommend to emulate a latent network
or a way to route the request through a known latent network? Testing
against localhost often makes it hard to see where things are slow (because
everything is so fast).
-Dan
On Tue, Jul 14, 2009 at 6:34 AM, Christian Bauer
<christian.bauer(a)gmail.com>wrote:
I've started documenting the (uncommitted) performance
improvements I've
enabled:
http://www.seamframework.org/Documentation/HTTPClientserverOptimizationSt...
Later this week I'm going to roll out these changes on sfwk.org and we'll
see if it all works as expected. I'm also going to integrate the Seam
Remoting patch that allows caching of JS interfaces of several components.
Please have a look at the doc and tell me what I've been missing.
There is also one more thing we should discuss at some point for Seam 3:
We are duplicating lots of functionality in Seam that any JAX RS
implementation has. We should probably drop SeamResourceServlet and maybe
even SeamFilter in Seam3 and rebuild what we need on top of JAX-RS. The
downside is that we'd create a dependency on a JAX-RS implementation. OTOH
almost anyone might want one of these in the future anyway.
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
12:48 a.m.
We are duplicating lots of functionality in Seam that any JAX RS
implementation has. We should probably drop SeamResourceServlet and maybe
even SeamFilter in Seam3 and rebuild what we need on top of JAX-RS. The
downside is that we'd create a dependency on a JAX-RS implementation. OTOH
almost anyone might want one of these in the future anyway.
Yes, I think we should do this. JAX-RS has such a low footprint and is vital
to the future of Java EE web apps, so like many other specs that we
"recommend highly" I think this should certainly be one of them. We can
always back off and try to abstract an SPI if the community is uneasy about
the direction.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
6:40 a.m.
Agreed.
On 15 Jul 2009, at 05:48, Dan Allen wrote:
We are duplicating lots of functionality in Seam that any JAX RS
implementation has. We should probably drop SeamResourceServlet and
maybe even SeamFilter in Seam3 and rebuild what we need on top of
JAX-RS. The downside is that we'd create a dependency on a JAX-RS
implementation. OTOH almost anyone might want one of these in the
future anyway.
Yes, I think we should do this. JAX-RS has such a low footprint and
is vital to the future of Java EE web apps, so like many other specs
that we "recommend highly" I think this should certainly be one of
them. We can always back off and try to abstract an SPI if the
community is uneasy about the direction.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
5391
days inactive
5397
days old
3 comments
3 participants
participants (3)
-
Christian Bauer -
Dan Allen -
Pete Muir