You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Piero Sartini <li...@pierosartini.de> on 2009/12/19 20:17:15 UTC
JSR-229, JSR-330 and other integrations
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by Sebastian Hennebrueder <us...@laliluna.de>.
Thiago H. de Paula Figueiredo schrieb:
> Em Sun, 20 Dec 2009 11:24:23 -0200, Sebastian Hennebrueder
> <us...@laliluna.de> escreveu:
>
>> I mentioned a couple of weeks ago that I miss the option to get grap
>> of the implementation. Currently you get only the interface and need
>> to put annotations there.
>
> I really miss that too. That's something I really want to solve when I
> have free time, I just don't know when. :( Is there a JIRA for it? I
> guess there was one . . .
>
>> Because it is just to simple. I don't think that there is a need to
>> standardize every couple of lines.
>
> I agree, but these annotations to me look more like code reuse than
> standardization. Why would everyone need to reimplement the @NotNull
> validation? ;)
>
The standard only implement a @Size and not @Min or @Max (as far as I
remember correctly).
The result is that you get an error message for a min value like
You need to input a number between 5 and 29924523523452345
Hibernate already provides extensions (Min and Max).
But anyway, we are cutting hairs. The reuse of the common validators is
already being coded for Tapestry.
--
Best Regards / Viele Grüße
Sebastian Hennebrueder
-----
Software Developer and Trainer for Hibernate / Java Persistence
http://www.laliluna.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sun, 20 Dec 2009 11:24:23 -0200, Sebastian Hennebrueder
<us...@laliluna.de> escreveu:
> I mentioned a couple of weeks ago that I miss the option to get grap of
> the implementation. Currently you get only the interface and need to put
> annotations there.
I really miss that too. That's something I really want to solve when I
have free time, I just don't know when. :( Is there a JIRA for it? I guess
there was one . . .
> Because it is just to simple. I don't think that there is a need to
> standardize every couple of lines.
I agree, but these annotations to me look more like code reuse than
standardization. Why would everyone need to reimplement the @NotNull
validation? ;)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by Sebastian Hennebrueder <us...@laliluna.de>.
Piero Sartini schrieb:
>>> JSR 299 is based on Hibernate Validator, a project that was created after
>>> Hibernate and its support is based on some generic Hibernate hooks. JPA
>>> supports them as ordinary event listeners. Hibernate and JPA weren't written
>>> using any validation framework.
>>>
>> Hibernate Validator 4 is the reference implementation for JSR 299. Of course
>> you are right, that it is not a part of Hibernate or JPA but just a module
>> which can be integrated.
>
> I am sure you meant JSR-303 (Beans Validation).
> But for reference: 299 is Context Dependency and Injection, with weld
> as its reference implementation.
>
> Piero
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
Yes, I did. Those numbers drive me crazy.
--
Best Regards / Viele Grüße
Sebastian Hennebrueder
-----
Software Developer and Trainer for Hibernate / Java Persistence
http://www.laliluna.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by Piero Sartini <li...@pierosartini.de>.
>> JSR 299 is based on Hibernate Validator, a project that was created after
>> Hibernate and its support is based on some generic Hibernate hooks. JPA
>> supports them as ordinary event listeners. Hibernate and JPA weren't written
>> using any validation framework.
>>
> Hibernate Validator 4 is the reference implementation for JSR 299. Of course
> you are right, that it is not a part of Hibernate or JPA but just a module
> which can be integrated.
I am sure you meant JSR-303 (Beans Validation).
But for reference: 299 is Context Dependency and Injection, with weld
as its reference implementation.
Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by Sebastian Hennebrueder <us...@laliluna.de>.
Thiago H. de Paula Figueiredo schrieb:
> Em Sat, 19 Dec 2009 17:56:57 -0200, Sebastian Hennebrueder
> <us...@laliluna.de> escreveu:
>
>> Though, I miss some features in the Tapestry's container which I like
>> in Google Guice,
>
> Which ones? Maybe we can add them to Tapestry-IoC.
I like the approach to add AOP to classes.
The following code filters all classes and adds the interceptor to all
methods annotated with the @Transactional annotation.
binder.bindInterceptor(Matchers.any(), Matchers
.annotatedWith(Transactional.class), methodInterceptor);
I mentioned a couple of weeks ago that I miss the option to get grap of
the implementation. Currently you get only the interface and need to put
annotations there.
>
>> 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.
>
> Regarding services, that's exactly what the Spring integration does.
>
> I see no reason why let other IoC framework to instantiate *page*
> classes. I guess it is inviable, as Tapestry doesn't do post processing
> them, it adds code to it then instantiate.
>
You are correct here.
>> 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.
>
> Why? Some of them are very common (@NotNull, @Length, @Size, etc), and
> you can add your own validations. You do not need to use just the ones
> provided out-of-the-box.
Because it is just to simple. I don't think that there is a need to
standardize every couple of lines.
>
>> 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.
>
> JSR 299 is based on Hibernate Validator, a project that was created
> after Hibernate and its support is based on some generic Hibernate
> hooks. JPA supports them as ordinary event listeners. Hibernate and JPA
> weren't written using any validation framework.
>
Hibernate Validator 4 is the reference implementation for JSR 299. Of
course you are right, that it is not a part of Hibernate or JPA but just
a module which can be integrated.
--
Best Regards / Viele Grüße
Sebastian Hennebrueder
-----
Software Developer and Trainer for Hibernate / Java Persistence
http://www.laliluna.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sat, 19 Dec 2009 17:56:57 -0200, Sebastian Hennebrueder
<us...@laliluna.de> escreveu:
> Though, I miss some features in the Tapestry's container which I like in
> Google Guice,
Which ones? Maybe we can add them to Tapestry-IoC.
> 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.
Regarding services, that's exactly what the Spring integration does.
I see no reason why let other IoC framework to instantiate *page* classes.
I guess it is inviable, as Tapestry doesn't do post processing them, it
adds code to it then instantiate.
> 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.
Why? Some of them are very common (@NotNull, @Length, @Size, etc), and you
can add your own validations. You do not need to use just the ones
provided out-of-the-box.
> 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.
JSR 299 is based on Hibernate Validator, a project that was created after
Hibernate and its support is based on some generic Hibernate hooks. JPA
supports them as ordinary event listeners. Hibernate and JPA weren't
written using any validation framework.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by Piero Sartini <li...@pierosartini.de>.
> I will try to come up with some integration module. What parts do you
> think could be integrated?
> Injecting services sounds doable... but when it comes to scopes I am lost.
OpenWebBeans could be interesting:
http://incubator.apache.org/openwebbeans/
>From their website:
"OpenWebBeans will be an ASL-licensed implementation of the Web Beans
Specification which is defined as JSR-299.
In addition to the implementation of the specification, the project
aims to create a new set of WebBeans components exposing functionality
of other Apache Foundation projects."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sun, 20 Dec 2009 00:27:18 -0200, Thiago H. de Paula Figueiredo
<th...@gmail.com> escreveu:
> Tapestry applications don't need to have any direct dependencies in the
> Servlet API. If someone implements some HTTP server in Java not based in
> the Servlet API (I guess there must be at least one around),
Yes, I've found one of them: http://www.simpleframework.org/
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 24 Dec 2009 13:25:34 -0200, Piero Sartini <li...@pierosartini.de>
escreveu:
> The error message does not get better... (see below).
> SCHWERWIEGEND: java.lang.ClassCastException
Having SCHWERWIEGEND in an error message just adds to my confusion. This
work sounds like something Austin Powers would speak. I only speak
Portuguese and English, not German. :D
By the way, you have a very Italian name and a very German domain. Once I
helped a guy with an Spanish name and a Netherlands domain. Tapestry has a
really diverse user pool . . . :)
> You mentioned that in tapestry it would not work to downcast an
> interface to its implementation because of the proxies.
> Looks like CDI uses proxies as well, and we try to downcast its
> Interface?
>
> "org.jboss.weld.bean-/home/ps/projects/sandbox/tapestry-yaml/target/tapestry-yaml/-ManagedBean-class
> sessionbeans.TestBeanImpl" looks like a proxy to me.
>
> Any thoughts?
I'm not going to have time to take a serious look into CDI and Weld for
the next two months.
Using proxies make a lot of sense for IoC and DI containers as they help
to solve lazy object creation, circular dependencies and method
interceptors.
The issue I'm more curious is whether an annotation placed in a method in
a bean implementation is present in the proxy method. This would give an
insight as how to implement it in Tapestry-IoC. ;)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by Piero Sartini <li...@pierosartini.de>.
>> (Debug code:
>> INFO: Object Type: interface sessionbeans.TestBean
>> INFO: Bean:
>> org.jboss.weld.bean-/home/ps/projects/sandbox/tapestry-yaml/target/tapestry-yaml/-ManagedBean-class
>> sessionbeans.TestBeanImpl
>> INFO: [ERROR] ioc.Registry java.lang.ClassCastException
>
> Have you tried a try/catch block around return objectType.cast(bean)? This
> should provide a better error message.
The error message does not get better... (see below).
You mentioned that in tapestry it would not work to downcast an
interface to its implementation because of the proxies.
Looks like CDI uses proxies as well, and we try to downcast its Interface?
"org.jboss.weld.bean-/home/ps/projects/sandbox/tapestry-yaml/target/tapestry-yaml/-ManagedBean-class
sessionbeans.TestBeanImpl" looks like a proxy to me.
Any thoughts?
Piero
---------------------------------
SCHWERWIEGEND: java.lang.ClassCastException
at java.lang.Class.cast(Class.java:2990)
at org.apache.tapestry5.cdi.CDIModule$2.provide(CDIModule.java:96)
at org.apache.tapestry5.ioc.internal.services.MasterObjectProviderImpl$1.invoke(MasterObjectProviderImpl.java:48)
at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:68)
at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:68)
at org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:941)
at org.apache.tapestry5.ioc.internal.services.MasterObjectProviderImpl.provide(MasterObjectProviderImpl.java:41)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Tue, 22 Dec 2009 05:20:16 -0200, Igor Drobiazko
<ig...@gmail.com> escreveu:
> I had a short look into how to integrate the JSR-330 and I fear it is not
> possible to make the intergation inside a 3rd-party library. You have to
> make some changes inside tapestry-ioc when you implement the integration.
I think JSR 330 is small enough for we to try to implement it instead of
relying in other libraries. And we don't want to lose distributed
configuration when declaring a JSR 330 bean, of course. ;)
> These are simple examples I realized after trying to run the tck of the
> JSR-330:
>
> - javax.inject.Inject may be applied to static members.
> - in tapestry-ioc only public constructors can be used for injection, in
> JSR-330 not.
I guess this additions would not be difficult to do.
> - in tck I saw a line of code in which an interface is downcasted to its
> implementation. This will not work with tapestry-ioc because of the
> proxies.
Tapestry-IoC proxies could have some improvements. They lose the
annotations in the service implementation methods, so implementing
anything that relies on them (like Spring-TX's and EJB's @Transactional)
seems impossibile now. One possible solution is to create proxies as
subclasses (almost like you would implement a hand-written decorator) and
copy the annotations to the proxy methods. I have not tried to implement
it yet, so I don't know if this would work.
> With these few examples it is obvious that the integration requires some
> ioc patches if you want to pass the tck.
There are some more stuff to implement:
* The Provider<T> interface injection:
http://atinject.googlecode.com/svn/trunk/javadoc/javax/inject/Provider.html
* Support for the Qualifier annotation.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by Igor Drobiazko <ig...@gmail.com>.
I had a short look into how to integrate the JSR-330 and I fear it is not
possible to make the intergation inside a 3rd-party library. You have to
make some changes inside tapestry-ioc when you implement the integration.
These are simple examples I realized after trying to run the tck of the
JSR-330:
- javax.inject.Inject may be applied to static members.
- in tapestry-ioc only public constructors can be used for injection, in
JSR-330 not.
- in tck I saw a line of code in which an interface is downcasted to its
implementation. This will not work with tapestry-ioc because of the proxies.
With these few examples it is obvious that the integration requires some ioc
patches if you want to pass the tck.
--
Best regards,
Igor Drobiazko
http://tapestry5.de/blog
Re: JSR-229, JSR-330 and other integrations
Posted by Piero Sartini <li...@pierosartini.de>.
> CDI should not mess with Tapestry-controlled classes at all. They're not
> meant to be injected in other objects and Tapestry-IoC already takes care of
> dependency injection.
> Isn't there any way to prevent packages from being touched by CDI? In Weld?
Yes.. it should not, but it does if you activate it with the empty beans.xml.
See this blog entry from Gavin (and my comment).
-> http://in.relation.to/13347.lace
>> * implementing JSR-330 alone could be dangerous, because in this
>> case two IoC containers will try to handle the same annotation as soon
>> as the beans.xml file is present.
>
> Implementing JSR-330, to me, equals to make Tapestry implement JSR 330
> itself, not using any other container to do that.
Yes, that was what I meant. But if Tapestry IoC implements JSR 330,
there are two DI frameworks that feel responsible. (CDI is using JSR
330 as well).
Right now CDI does not try to inject beans into tapestry managed classes ..
but after implementing JSR 330 this will change...
>> Of course, if you split out the CDI beans into their own jar,
>> everything is fine (just provide the beans.xml file there and not in
>> the webapp).
>
> This is far from ideal, as we would need to package the classes before
> running or testing the application.
Totally agree with you.
>> In my understanding we need to go over the tapestry
>> MasterObjectProvider to be able to inject the beans then. Where I am
>> now is that I contribute an ObjectProvider which queries CDI for the
>> objectType and returns it if successfull. This seems to work.
>
> Have you looked at how the Spring integration is implemented?
Yes - that's where I looked to even find a start. But CDI is quite
different in that it does not mean to bootstrap itself... that means
no custom ServletFilter is needed.
> Have you tried a try/catch block around return objectType.cast(bean)? This
> should provide a better error message.
Nope, thanks for the hint. I will try this tonight.
Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sun, 20 Dec 2009 18:30:29 -0200, Piero Sartini <li...@pierosartini.de>
escreveu:
> Ok.. I played around with this some more. First of all its interesting
> that CDI does not need
> to be instantiated. Only thing neccessary is an empty beans.xml in
> META-INF/ and a JSR-299 aware
> container... this may also be our sweet jetty + 3 jars.
Nice!
> For CDI, everything is a potential bean. Any interface with available
> implementation may become a managed bean and its dependencies
> are resolved. This has some implications:
> * If @javax.inject.Inject is found on any class (including
> tapestry managed), CDI tries to do its work. It may be successfull,
> but because of tapestry's instance pooling and re-use this is not very
> useful. Or do I miss something?
CDI should not mess with Tapestry-controlled classes at all. They're not
meant to be injected in other objects and Tapestry-IoC already takes care
of dependency injection.
Isn't there any way to prevent packages from being touched by CDI? In Weld?
> * implementing JSR-330 alone could be dangerous, because in this
> case two IoC containers will try to handle the same annotation as soon
> as the beans.xml file is present.
Implementing JSR-330, to me, equals to make Tapestry implement JSR 330
itself, not using any other container to do that.
> Of course, if you split out the CDI beans into their own jar,
> everything is fine (just provide the beans.xml file there and not in
> the webapp).
This is far from ideal, as we would need to package the classes before
running or testing the application.
> In my understanding we need to go over the tapestry
> MasterObjectProvider to be able to inject the beans then. Where I am
> now is that I contribute an ObjectProvider which queries CDI for the
> objectType and returns it if successfull. This seems to work.
Have you looked at how the Spring integration is implemented?
> Problem is that this code throws a ClassCastException:
> public <T> T provide(Class<T> objectType, AnnotationProvider
> annotationProvider, ObjectLocator locator) {
> // ... CDI code ...
> return objectType.cast(bean);
>
> (Debug code:
> INFO: Object Type: interface sessionbeans.TestBean
> INFO: Bean:
> org.jboss.weld.bean-/home/ps/projects/sandbox/tapestry-yaml/target/tapestry-yaml/-ManagedBean-class
> sessionbeans.TestBeanImpl
> INFO: [ERROR] ioc.Registry java.lang.ClassCastException
Have you tried a try/catch block around return objectType.cast(bean)? This
should provide a better error message.
> but this code does not throw the exception:
> return (T) bean;
Java generics, in this case, does nothing.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by Piero Sartini <li...@pierosartini.de>.
> I thought of just instantiating Weld, getting all the declared beans and add
> them to a Tapestry registry. You can take a look at tapestry-string to draw
> some inspiration.
Ok.. I played around with this some more. First of all its interesting
that CDI does not need
to be instantiated. Only thing neccessary is an empty beans.xml in
META-INF/ and a JSR-299 aware
container... this may also be our sweet jetty + 3 jars.
For CDI, everything is a potential bean. Any interface with available
implementation may become a managed bean and its dependencies
are resolved. This has some implications:
* If @javax.inject.Inject is found on any class (including
tapestry managed), CDI tries to do its work. It may be successfull,
but because of tapestry's instance pooling and re-use this is not very
useful. Or do I miss something?
* implementing JSR-330 alone could be dangerous, because in this
case two IoC containers will try to handle the same annotation as soon
as the beans.xml file is present.
Of course, if you split out the CDI beans into their own jar,
everything is fine (just provide the beans.xml file there and not in
the webapp).
In my understanding we need to go over the tapestry
MasterObjectProvider to be able to inject the beans then. Where I am
now is that I contribute an ObjectProvider which queries CDI for the
objectType and returns it if successfull. This seems to work.
Problem is that this code throws a ClassCastException:
public <T> T provide(Class<T> objectType, AnnotationProvider
annotationProvider, ObjectLocator locator) {
// ... CDI code ...
return objectType.cast(bean);
(Debug code:
INFO: Object Type: interface sessionbeans.TestBean
INFO: Bean: org.jboss.weld.bean-/home/ps/projects/sandbox/tapestry-yaml/target/tapestry-yaml/-ManagedBean-class
sessionbeans.TestBeanImpl
INFO: [ERROR] ioc.Registry java.lang.ClassCastException
)
but this code does not throw the exception:
return (T) bean;
With the second version, I am getting another error (see below). Any hints?
Piero
INFO: [ERROR] TapestryModule.RequestExceptionHandler Processing of
request failed with uncaught exception:
java.lang.IllegalArgumentException: argument type mismatch
org.apache.tapestry5.internal.services.TransformationException:
java.lang.IllegalArgumentException: argument type mismatch
at org.apache.tapestry5.internal.services.ComponentClassTransformerImpl.createInstantiator(ComponentClassTransformerImpl.java:198)
at $ComponentClassTransformer_125adae3027.createInstantiator($ComponentClassTransformer_125adae3027.java)
at org.apache.tapestry5.internal.services.ComponentInstantiatorSourceImpl.getInstantiator(ComponentInstantiatorSourceImpl.java:284)
at $ComponentInstantiatorSource_125adae3025.getInstantiator($ComponentInstantiatorSource_125adae3025.java)
at org.apache.tapestry5.internal.pageload.PageLoaderImpl.createAssembler(PageLoaderImpl.java:193)
at org.apache.tapestry5.internal.pageload.PageLoaderImpl.getAssembler(PageLoaderImpl.java:183)
at org.apache.tapestry5.internal.pageload.PageLoaderImpl.loadPage(PageLoaderImpl.java:157)
at $PageLoader_125adae305a.loadPage($PageLoader_125adae305a.java)
at org.apache.tapestry5.internal.services.PagePoolCache.checkout(PagePoolCache.java:210)
at org.apache.tapestry5.internal.services.PagePoolImpl.checkout(PagePoolImpl.java:99)
at $PagePool_125adae3059.checkout($PagePool_125adae3059.java)
at org.apache.tapestry5.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:51)
at $RequestPageCache_125adae3058.get($RequestPageCache_125adae3058.java)
at $RequestPageCache_125adae3051.get($RequestPageCache_125adae3051.java)
at org.apache.tapestry5.internal.services.PageRenderRequestHandlerImpl.handle(PageRenderRequestHandlerImpl.java:52)
at org.apache.tapestry5.services.TapestryModule$34.handle(TapestryModule.java:2268)
at $PageRenderRequestHandler_125adae3054.handle($PageRenderRequestHandler_125adae3054.java)
at $PageRenderRequestHandler_125adae303c.handle($PageRenderRequestHandler_125adae303c.java)
at org.apache.tapestry5.internal.services.ComponentRequestHandlerTerminator.handlePageRender(ComponentRequestHandlerTerminator.java:48)
at $ComponentRequestHandler_125adae3041.handlePageRender($ComponentRequestHandler_125adae3041.java)
at org.apache.tapestry5.internal.services.PageRenderDispatcher.dispatch(PageRenderDispatcher.java:45)
at $Dispatcher_125adae3043.dispatch($Dispatcher_125adae3043.java)
at $Dispatcher_125adae3039.dispatch($Dispatcher_125adae3039.java)
at org.apache.tapestry5.services.TapestryModule$RequestHandlerTerminator.service(TapestryModule.java:255)
at org.apache.tapestry5.internal.services.RequestErrorFilter.service(RequestErrorFilter.java:26)
at $RequestHandler_125adae303a.service($RequestHandler_125adae303a.java)
at org.apache.tapestry5.services.TapestryModule$4.service(TapestryModule.java:937)
at $RequestHandler_125adae303a.service($RequestHandler_125adae303a.java)
at org.apache.tapestry5.services.TapestryModule$3.service(TapestryModule.java:926)
at $RequestHandler_125adae303a.service($RequestHandler_125adae303a.java)
at org.apache.tapestry5.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:85)
at $RequestHandler_125adae303a.service($RequestHandler_125adae303a.java)
at de.sartini.tapestry.yaml.services.AppModule$1.service(AppModule.java:90)
at $RequestFilter_125adae3035.service($RequestFilter_125adae3035.java)
at $RequestHandler_125adae303a.service($RequestHandler_125adae303a.java)
at org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:90)
at org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:81)
at org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:85)
at org.apache.tapestry5.internal.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:103)
at $RequestHandler_125adae303a.service($RequestHandler_125adae303a.java)
at $RequestHandler_125adae302f.service($RequestHandler_125adae302f.java)
at org.apache.tapestry5.services.TapestryModule$HttpServletRequestHandlerTerminator.service(TapestryModule.java:206)
at org.apache.tapestry5.internal.gzip.GZipFilter.service(GZipFilter.java:53)
at $HttpServletRequestHandler_125adae3031.service($HttpServletRequestHandler_125adae3031.java)
at org.apache.tapestry5.internal.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:62)
at $HttpServletRequestFilter_125adae302e.service($HttpServletRequestFilter_125adae302e.java)
at $HttpServletRequestHandler_125adae3031.service($HttpServletRequestHandler_125adae3031.java)
at org.apache.tapestry5.services.TapestryModule$2.service(TapestryModule.java:876)
at $HttpServletRequestHandler_125adae3031.service($HttpServletRequestHandler_125adae3031.java)
at $HttpServletRequestHandler_125adae302c.service($HttpServletRequestHandler_125adae302c.java)
at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:127)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:332)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:233)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:165)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.RuntimeException:
java.lang.IllegalArgumentException: argument type mismatch
at org.apache.tapestry5.internal.services.InternalClassTransformationImpl.createInstantiator(InternalClassTransformationImpl.java:1525)
at org.apache.tapestry5.internal.services.ComponentClassTransformerImpl.createInstantiator(ComponentClassTransformerImpl.java:194)
... 75 more
Caused by: java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.apache.tapestry5.internal.services.InternalClassTransformationImpl.createInstantiator(InternalClassTransformationImpl.java:1519)
... 76 more
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sun, 20 Dec 2009 07:32:00 -0200, Piero Sartini <li...@pierosartini.de>
escreveu:
> You would still need to provide tapestry with replacements for
> HttpServletRequest and HttpServletResponse.
> I am not sure, but I could imagine that if you try to adapt tapestry
> to Simple, you will end up rebuilding a good part of the Servlet API.
I don't think so, as Simple already has an API that provides features
similar do the Servlet API.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by Piero Sartini <li...@pierosartini.de>.
> Tapestry applications don't need to have any direct dependencies in the
> Servlet API. If someone implements some HTTP server in Java not based in the
> Servlet API (I guess there must be at least one around), you can adapt
> Tapestry to work on it. Tapestry applications would work out of the box, as
> long as they don't use the Servlet API directly.
You would still need to provide tapestry with replacements for
HttpServletRequest and HttpServletResponse.
I am not sure, but I could imagine that if you try to adapt tapestry
to Simple, you will end up rebuilding a good part of the Servlet API.
That's what servlets are all about: provide an api for developers to
build web apps.
Maybe its just me, but I don't get this whole "dependencies are bad" mindset.
Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sat, 19 Dec 2009 23:31:24 -0200, Piero Sartini <li...@pierosartini.de>
escreveu:
> I will try to come up with some integration module. What parts do you
> think could be integrated?
> Injecting services sounds doable... but when it comes to scopes I am
> lost.
I thought of just instantiating Weld, getting all the declared beans and
add them to a Tapestry registry. You can take a look at tapestry-string to
draw some inspiration.
> It would be great if scopes could be handled by 299 if present.. need
> to dig into the
> code to get a picture of how this works in tapestry.
Open the sources and search for uses of the @Scope annotation and classes
named *Scope.
> You are right. But where do you find pure JavaSE?
Swing and command-line applications also benefit from IoC and DI. ;)
> Not in the web world
> - thats for sure :-)
Tapestry applications don't need to have any direct dependencies in the
Servlet API. If someone implements some HTTP server in Java not based in
the Servlet API (I guess there must be at least one around), you can adapt
Tapestry to work on it. Tapestry applications would work out of the box,
as long as they don't use the Servlet API directly.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by Piero Sartini <li...@pierosartini.de>.
> I've read most of the Weld (JSR 299 implementation) documentation at
> http://docs.jboss.org/weld/reference/1.0.0/en-US/html_single/. There are
> some similar concepts that can be mapped to Tapestry-IoC features, but it's
> a lot to implement still. Don't explect an implementation soon. Better go to
> the integration approach.
I will try to come up with some integration module. What parts do you
think could be integrated?
Injecting services sounds doable... but when it comes to scopes I am lost.
> Tapestry-IoC also has scopes, but AFAIK 299 has some features that are
> absent in T-IoC.
It would be great if scopes could be handled by 299 if present.. need
to dig into the
code to get a picture of how this works in tapestry.
> If something needs EJB, it is not (pure) Java SE. Sun made that distinction,
> not me. ;) I guess it's not a matter of lightweightness. And this word
> doesn't have a single definition either.
You are right. But where do you find pure JavaSE? Not in the web world
- thats for sure :-)
Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sat, 19 Dec 2009 21:58:47 -0200, Piero Sartini <li...@pierosartini.de>
escreveu:
> This is a good question.. I think it could be both.
I've read most of the Weld (JSR 299 implementation) documentation at
http://docs.jboss.org/weld/reference/1.0.0/en-US/html_single/. There are
some similar concepts that can be mapped to Tapestry-IoC features, but
it's a lot to implement still. Don't explect an implementation soon.
Better go to the integration approach.
> Interesting stuff is the context implementation.. I don't know if we
> are able to wire tapestry's scope implementation up with this. Would
> give us a Conversation Scope :-)
Tapestry-IoC also has scopes, but AFAIK 299 has some features that are
absent in T-IoC.
> In this case please forget about what I've said :-)
Forgotten! :)
> Nowadays EJBs are lightweight stuff, so someone could argument they
> are JavaSE as well.
If something needs EJB, it is not (pure) Java SE. Sun made that
distinction, not me. ;) I guess it's not a matter of lightweightness. And
this word doesn't have a single definition either.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by Piero Sartini <li...@pierosartini.de>.
> AFAIK, 299 uses 330, so we I guess we have no option.
Yes, we need 330 anyway.
> It's more interesting but it's more to implement. ;)
> There's a distinction to be done here: Tapestry-IoC integrates with JSR 299
> implementations or Tapestry-IoC implementing 299?
This is a good question.. I think it could be both.
>From the spec:
------------------------------------
Package javax.enterprise.inject.spi
Description
The portable extension integration SPI.
A portable extension may integrate with the container by:
* Providing its own beans, interceptors and decorators to the container
* Injecting dependencies into its own objects using the dependency
injection service
* Providing a context implementation for a custom scope
* Augmenting or overriding the annotation-based metadata with metadata
from some other source
------------------------------------
To me this means we will be able to do all the injection stuff
(tap-ioc to cdi and cdi to tap-ioc) without much problems.
Interesting stuff is the context implementation.. I don't know if we
are able to wire tapestry's scope implementation up with this. Would
give us a Conversation Scope :-)
>> Yes - but in case JSR-299 gives us spring for free, maybe we don't
>> need to maintain two seperate modules.
>
> It seems to me that currently Spring supports 330 but not 299 yet.
In this case please forget about what I've said :-)
> I'm making a distinction between SE and EE because 330 and 303, for example,
> don't need an EJB implementation to run. That's why I don't refer to them as
> part of Java EE. ;)
Nowadays EJBs are lightweight stuff, so someone could argument they
are JavaSE as well. I think they are even smaller than the Spring
dependencies.
Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sat, 19 Dec 2009 20:53:59 -0200, Piero Sartini <li...@pierosartini.de>
escreveu:
> 330 is not much more than standardized DI annotations. It is a good
> starting point, but I am not sure if we gain a lot from it.
We gain a lot actually: a non EJB object can be used as a bean in most IoC
containers without any change.
AFAIK, 299 uses 330, so we I guess we have no option.
> 299 is more interesting.. it defines a SPI for developing portable
> extensions to JavaEE. If I am right, this could be the integration
> point with tapestry-ioc.
It's more interesting but it's more to implement. ;)
There's a distinction to be done here: Tapestry-IoC integrates with JSR
299 implementations or Tapestry-IoC implementing 299?
> Yes - but in case JSR-299 gives us spring for free, maybe we don't
> need to maintain two seperate modules.
It seems to me that currently Spring supports 330 but not 299 yet.
> As far as I know, JSR-299 as well as 330 can be used outside of any
> container.
330 I'm sure, not 100% sure about 299.
> After all, JavaEE is just a bunch of JSRs bundled together.. but if
> you prefer you may put together everything on top of JavaSE as well.
I'm making a distinction between SE and EE because 330 and 303, for
example, don't need an EJB implementation to run. That's why I don't refer
to them as part of Java EE. ;)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by Piero Sartini <li...@pierosartini.de>.
> 330 is a little JSR, so I guess the effort wouldn't be large.
> 299 I haven't read yet, but I guess it's way larger.
330 is not much more than standardized DI annotations. It is a good
starting point, but I am not sure if we gain a lot from it.
299 is more interesting.. it defines a SPI for developing portable
extensions to JavaEE. If I am right, this could be the integration
point with tapestry-ioc.
If you are interested in more detail, there is good documentation
available here:
http://seamframework.org/Weld
>> Not sure, but I think Spring would then be
>> available for free as well...
>
> Spring already is available.
Yes - but in case JSR-299 gives us spring for free, maybe we don't
need to maintain two seperate modules.
> Yes. And we should had a DI standard for Java, not just for Java EE. That's
> what I think was a serious error of 299 that was only corrected (if it was
> corrected) after 330 was started.
As far as I know, JSR-299 as well as 330 can be used outside of any container.
After all, JavaEE is just a bunch of JSRs bundled together.. but if
you prefer you may put together everything on top of JavaSE as well.
Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sat, 19 Dec 2009 20:22:37 -0200, Piero Sartini <li...@pierosartini.de>
escreveu:
> Agreed - my intention never was to force EJB to anyone. But I think
> supporting JSR-299 and -330 would be a good thing, because if I
> understand it correctly we then get integration with EJB for free.
330 is a little JSR, so I guess the effort wouldn't be large.
299 I haven't read yet, but I guess it's way larger.
> Not sure, but I think Spring would then be
> available for free as well...
Spring already is available.
> (This means we finally have a DI standard in each and every JavaEE
> application server..)
Yes. And we should had a DI standard for Java, not just for Java EE.
That's what I think was a serious error of 299 that was only corrected (if
it was corrected) after 330 was started.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by Piero Sartini <li...@pierosartini.de>.
> It's not a good idea to force one framework (EJB3) to the users of another
> framework (Tapestry, Tapestry-IoC). But it's a good idea to add support for
> other frameworks.
Agreed - my intention never was to force EJB to anyone. But I think supporting
JSR-299 and -330 would be a good thing, because if I understand it correctly we
then get integration with EJB for free. Not sure, but I think Spring
would then be
available for free as well...
> A nitpick: JSRs 303 and 330 are targeted at Java SE, not Java EE.
Maybe they were once targetted at JavaSE, but all three of them are
now included in JavaEE 6:
http://java.sun.com/javaee/technologies/index.jsp
(This means we finally have a DI standard in each and every JavaEE
application server..)
Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sat, 19 Dec 2009 18:26:32 -0200, Piero Sartini <li...@pierosartini.de>
escreveu:
> Of course, we could invent solutions on top of tapestry-ioc that would
> be as good or better..
> but then, why re-invent the wheel?
I'm not advocating widespread wheel reinvention, but sometimes the
existing wheel doesn't do what we want or need.
Tapestry-IoC, as stated in its website, was created because Spring doesn't
support distributed configuration, a feature needed and used in Tapestry.
> What I miss most in tapestry are remote services, transactions and
> support for JPA.
I miss transactions support, the only reason I'm still using Spring.
> The question is if we will bake all this ourselfe or integrate with EJB3?
It's not a good idea to force one framework (EJB3) to the users of another
framework (Tapestry, Tapestry-IoC). But it's a good idea to add support
for other frameworks.
> To be honest, it does not matter what is the strategy behind this.
> Fact is that both of these JSRs are part of JavaEE 6.
A nitpick: JSRs 303 and 330 are targeted at Java SE, not Java EE.
> I totally agree that standards are not the solution for everything and
> innovation needs to break out at times.
> But.. standards are useful and important if you want to take advantage
> of things you can't offer yourself.
Point taken. :)
> Hey.. after all we talk about Java. And one argument for a Java Web
> framework is integration with the rest of the huge Java ecosystem,
> isn't it?
Yes, it is. We just need to the pros and the cons of each of this
integrations.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by Piero Sartini <li...@pierosartini.de>.
> 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).
You are right - that is why I mentioned the benefits of integrating
with these standards.
Of course, we could invent solutions on top of tapestry-ioc that would
be as good or better..
but then, why re-invent the wheel?
What I miss most in tapestry are remote services, transactions and
support for JPA.
The question is if we will bake all this ourselfe or integrate with EJB3?
There is a Spring integration.. but well - I don't see the point in
using another abstraction.
> 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.
To be honest, it does not matter what is the strategy behind this.
Fact is that both of these JSRs are part of JavaEE 6.
They are available in many application servers, and they are easily
embedded in pure servlet containers.
> 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.
So you say its totally nonsense to standardize these annotations, but
then you want it because
software is standardized on them? Oh well...
I totally agree that standards are not the solution for everything and
innovation needs to break out at times.
But.. standards are useful and important if you want to take advantage
of things you can't offer yourself.
Hey.. after all we talk about Java. And one argument for a Java Web
framework is integration with the rest of the huge Java ecosystem,
isn't it?
Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by Sebastian Hennebrueder <us...@laliluna.de>.
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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sat, 19 Dec 2009 20:08:52 -0200, Piero Sartini <li...@pierosartini.de>
escreveu:
> You caught me - the spring integration is available. So we need to
> discuss if we want to integrate with JSR-299 (and EJBs, which if I got
> it correct now are sitting on top) as well.
Being the smaller one, I think we need to focus on JSR 330 first, 299
later.
> I've read the discussion about JSR-330, but it stopped. Maybe there
> was not enough interest.
JSR 330 had just been announced at that time. ;)
> I know - but I fear my knowledge about the internals of tapestry are
> not good enough to make s.th. like this happen.
Regarding 330, it's not Tapestry itself, but Tapestry-IoC alone. Read the
sources: you can learn a lot of them, and not just about the framework.
Most of what I know about Tapestry came from reading the sources.
> And that's why I want to be able to use tapestry :-)
> But.. to be fair: Seam and now JSF2 got a lot of things right as well.
But, AFAIK, they can't fix (because of backward compatibility) the very
complex lifecycle. And writing a component in Tapestry is still way
simpler and faster than in JSF 2.
> The comparision with JDO is bad: it was, as far as I know, never
> included in a JavaEE Spec.
My point was about specifications at large, not just the Java EE ones. JDO
is JSR 12: http://jcp.org/aboutJava/communityprocess/first/jsr012/
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by Piero Sartini <li...@pierosartini.de>.
> I think the first question that we need to ask ourselves is which of this
> new stuff is worth to spend some time integrating them into Tapestry and/or
> Tapestry-IoC.
You are right - this is the question we need to answer first. Maybe
this thread can help :)
> Not technically correct. Tapestry is already integrated with Spring. I can
> inject a Tapestry service exactly the same way I would inject a Tapestry-IoC
> service. Tapestry-IoC already has some hooks to plug objects built
> elsewhere.
You caught me - the spring integration is available. So we need to
discuss if we want to integrate with JSR-299 (and EJBs, which if I got
it correct now are sitting on top) as well.
>> Things I really miss are:
>> * JSR-303: Beans validation
>
> This integration has already started, just not released yet. More info here:
> http://tapestry.formos.com/nightly/tapestry5/tapestry-beanvalidator/
Thanks for the hint, great to hear!
>> * JSR-299: Contexts and Dependency Injection
>> * JSR-330: Dependency Injection for Java
>
> There was a discussion about JSR 330 in the dev mailing list. JSR 330 is
> based on Guice. Tapestry-IoC was partly inspired by Guice, so I guess the
> integration will not be difficult to implement. No discussion about 299 yet.
I've read the discussion about JSR-330, but it stopped. Maybe there
was not enough interest.
>> I understand if you say that its not worth the effort or too hard to
>> accomplish -
>
> Everyone is invited to contribute, committers or not.
I know - but I fear my knowledge about the internals of tapestry are
not good enough to make s.th. like this happen.
>> 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.
>
> JSF sucks, by the way. :)
And that's why I want to be able to use tapestry :-)
But.. to be fair: Seam and now JSF2 got a lot of things right as well.
> A question: how many people/organizations/whatever really care for
> standards? How much they care? I don't know the answer.
> These JSRs are very, very young, so we can't be really sure whether they
> will be adopted. JDO is a JSR and very few people use it.
> A standard by itself is as useful as the number of people that use them.
My experience is that people and companies care a lot about standards.
Even small and mid sized companies see the value. It's a lot easier to
find developers, and most decision makers are afraid to be left alone
with their stack in a few years if they don't go with standards.
About the argument that these JSRs are young. Sure they are, but it's
just the specification of something that has proven to be useful and
is already used in a lot of deployments... can't really imagine anyone
using JSF without Seam (but I've heard about some brave people doing
so).
The comparision with JDO is bad: it was, as far as I know, never
included in a JavaEE Spec.
Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JSR-229, JSR-330 and other integrations
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sat, 19 Dec 2009 17:17:15 -0200, Piero Sartini <li...@pierosartini.de>
escreveu:
> Hello list.
Hi!
> 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.
I think the first question that we need to ask ourselves is which of this
new stuff is worth to spend some time integrating them into Tapestry
and/or Tapestry-IoC.
> 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.
Not technically correct. Tapestry is already integrated with Spring. I can
inject a Tapestry service exactly the same way I would inject a
Tapestry-IoC service. Tapestry-IoC already has some hooks to plug objects
built elsewhere.
> Things I really miss are:
> * JSR-303: Beans validation
This integration has already started, just not released yet. More info
here: http://tapestry.formos.com/nightly/tapestry5/tapestry-beanvalidator/
> * JSR-299: Contexts and Dependency Injection
> * JSR-330: Dependency Injection for Java
There was a discussion about JSR 330 in the dev mailing list. JSR 330 is
based on Guice. Tapestry-IoC was partly inspired by Guice, so I guess the
integration will not be difficult to implement. No discussion about 299
yet.
> I understand if you say that its not worth the effort or too hard to
> accomplish -
Everyone is invited to contribute, committers or not.
> 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.
JSF sucks, by the way. :)
> In my oppinion, integrating with these standards is more than
> important for tapestry to survive.
A question: how many people/organizations/whatever really care for
standards? How much they care? I don't know the answer.
These JSRs are very, very young, so we can't be really sure whether they
will be adopted. JDO is a JSR and very few people use it.
A standard by itself is as useful as the number of people that use them.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org