Hello Piero,
a standard is not useful because it is a standard but because it
provides us with an advantage. From a business point of view being a
standard provider is a good reason to sell things to enterprise
customer. Enterprise love standards not because they are innovative but
because they are stable and you are able to switch to a different vendor
(at least the sales brochure is telling you this).
The strategy behind 299, 303 and 330 is in my opinion to describe
features in a standard in order to attract enterprise customers. Red Hat
influences 303 (Hibernate Validation 4 is the reference implementation)
and 299 (former Web Beans, the DI part of JBoss Seam, now Weld project),
Spring Source attacks from the other side by standardizing their stuff
in JSR 330. Google worked with Red Hat first and then moved over to
support JSR 330.
Of course it is not negative to attract enterprise customer but it comes
with a very expensive downside, which is currently (my guess) not
recognized by any of the named companies. Standards do not progress and
Red Hat by binding their full development stack to standards puts itself
on the leash. They won't be able to innovate as they did before because
the leash is controlled by other companies as well.
If we have a look at the application stacks of Red Hat and Spring
source, then it becomes visible as well, that implementing a standard is
not there to be interchangeable. You have to decide for a full
application stack, which might implement some standard things but in
fact all the weaving together is not standardized. You go JBoss Seam or
you go Spring source. It could be a very clever strategy to be different
then those and to provide light and elegant integration with other
containers without connecting us strongly to standards.
Though, I miss some features in the Tapestry's container which I like in
Google Guice, I am not sure if it is a viable solution to make the
container interchangeable. May be we could improve the integration with
other containers by letting them instantiating Service and Page classes
and post processing the classes with Tapestry.
I only agree that it would be nice to support JSR 303 (Validation
framework). This is not becauce it is standardized. I believe that it is
totally nonsense to standardize a couple of validations. The reason is
that JPA and Hibernate uses those validations and as a matter of fact 95
% (my guess) of all persistence layers are written with those technologies.
--
Best Regards / Viele Grüße
Sebastian Hennebrueder
-----
Software Developer and Trainer for Hibernate / Java Persistence
http://www.laliluna.de
The idea of JSR 299
Piero Sartini schrieb:
Hello list.
This mail is inspired from the wishlist thread and the discussion
about persistence, transactions and EJB. Now that JavaEE 6 is out, I
think it is time to think about how tapestry will integrate with this
shiny new stuff. There already was a discussion about this, but it
stopped with no conclusion.
Current status is that tapestry has its own IoC container which is a
wonderful peace of software.. but it also isolates us from all the
evolution that is going on in the Java world. Things I really miss
are:
* JSR-303: Beans validation
* JSR-299: Contexts and Dependency Injection
* JSR-330: Dependency Injection for Java
Let me explain why I miss them - some of you may say we have tapestry
equivalents of most of these things.
What would Tapestry win by integrating with these standards?
* JSR-299 / JSR-330:
Supporting these specifications would allow us to make use of EJB3.1
without additional work. This gives transactions as well as JPA2.0
integration for free. Scopes are defined as well, so EJBs could be
tied to the request. I am not sure if all of this is even possible
with tapestry's current architecture.. but the benefits would be huge
and IMHO its worth to think about it.
* JSR-303:
Supporting this spec would allow us to build a tapestry independent
backend. Think about EJBs again - tapestry annotations really should
not go into the backend... in case of remote session beans, tapestry
is not even available to annotate my beans. With JSR-303 I could have
validations that are enforced in the backend as well as in the
frontend... Sometimes the web is just one of the clients!
I understand if you say that its not worth the effort or too hard to
accomplish - but then I need to ask the question how tapestry wants to
stand up against the competition in the future?
Let's take a look at Wicket, the main competitior: they already have
it. Struts2 also has a experimental implementation of JSR-299. Seam /
JSF2 is the source of all this.
In my oppinion, integrating with these standards is more than
important for tapestry to survive. It would become a real alternative
to JSF, playing out its strength: building the frontend, leaving the
backend stuff to the standard: EJB. (Spring integration would benefit
as well, as Spring 3 is completely JSR-330 compatible)
WDYAT?
Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
