Re: [ANNOUNCE] Tapestry-cdi contribution
I do believe that the same could be said for tapestry-cdi and by extension FlowLogix Magnus, can you comment on this? I think that you have to rely on a specific container's implementation to exclude classes from scanning and avoid conficts between CDI and Tapestry IOC. I can be wrong. Also, I didn't see how qualifiers are handled. Can you release an alpha version on maven central? will take a look on that even if it not in our priorities list at the moment There is a case (EAR file, for example) where some modules use CDI (beans.xml exists) and some don't (no beans.xml), yet have the same classpath, i.e. have tapestry CDI module on the classpath. This would cause the Tapestry module to fail, and stop the application startup in its tracks. This would be a big problem for us. Hope that makes it clearer we need to test this use case What about having Tapestry-IoC as a CDI portable extension which registers T-IoC services as CDI beans? This way, we can still have the best of two worlds without Tapestry-IoC implementing CDI and with way less work. Currently, CDI beans can be served as tapestry services but the opposite is not true. Your idea is interesting, need some investigation to see the feasability. I am very glad to see CDI is supported in Tapestry, but I viewed the pom.xml, it depended on openejb(not standard CDI api), and tomee(for test). To avoid java.lang.ClassFormatError during unit tests, we have to choose a specific api for javaee (standard api is crippled). See http://stackoverflow.com/questions/15518148/maven-javaee-api-vs-jboss-javaee-6-0. Maybe we could add some maven profiles for that. But we implement only standard CDI api (no code tied to openejb) and tomee is only used for tests. I wish Apache DeltaSpike(which is the successor of MyFaces CODI and JBoss Seam3 and others) can be considered as dependency, it is also from Apache.org. yes, it's in our mind, especially since DeltaSpike just moved out of the apache incubator! Besides @Inject, more features from CDI and Deltaspike can be considered. 1. CDI Event 2. Messages(fire message as event payload and Tapetry components observe it and display it in page) 3. Conversation(I have asked such a question before, I dream there is a simple solution to group several Tapestry pages to complete a wizard like task easily) Totally agree. I hope those features for next releases (though, currently there is no explicit roadmap for that) - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [ANNOUNCE] Tapestry-cdi contribution
Yeah, I don't know if that's doable now, but we could do some work on Tapestry-IoC so the Registry object could provide a method that returns a list of services, something which isn't done yet AFAIK. Maybe this service could help us for that : http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/services/ServiceActivityScoreboard.html This was container specific, but remember reading somewhere that it would be a standard way to specify exclusions in cdi 1.1. Couldn't find the reference, but here is a commit though: https://github.com/pmuir/cdi/commit/a4061ffd0ef52e4028e8cb5727335e7e25f1d493 Good to know ! tapestry-cdi should be portable across containers, think there was only an issue when including a beans.xml in tapestry app where the weld extensions could be used. BTW, we managed to exclude tapestry resources from CDI management at server's start with spi extension : https://github.com/got5/tapestry-cdi/blob/master/src/main/java/org/got5/tapestry5/cdi/extension/TapestryExtension.java 2013/5/16 Bård Magnus Kvalheim mag...@kvalheim.eu: On Thu, May 16, 2013 at 12:08 PM, Nourredine Khadri nourredine.kha...@atos.net wrote: I do believe that the same could be said for tapestry-cdi and by extension FlowLogix Magnus, can you comment on this? I think that you have to rely on a specific container's implementation to exclude classes from scanning and avoid conficts between CDI and Tapestry IOC. I can be wrong. This was container specific, but remember reading somewhere that it would be a standard way to specify exclusions in cdi 1.1. Couldn't find the reference, but here is a commit though: https://github.com/pmuir/cdi/commit/a4061ffd0ef52e4028e8cb5727335e7e25f1d493 tapestry-cdi should be portable across containers, think there was only an issue when including a beans.xml in tapestry app where the weld extensions could be used. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
[ANNOUNCE] Tapestry-cdi contribution
Hi, Atos is proud to announce the first release of Tapestry-cdi, part of the got5[1] project. This library is based on work of Romain Manni Bucau[2] and inspired from other contributions (Magnus Kvalheim[3] and FlowLogix projects[4]). We have updated the dependencies of this library to use Tapestry 5.3.7 Tapestry-CDI module allows injecting all kind of JSR 299 managed beans (POJO, EJB, web service, ...) as they are managed by the CDI-container This library also supports: - CDI beans injection @Inject CDI beans into pages, components and tapestry services. Both @Inject annotations are handled (@javax.inject.Inject and @org.apache.tapestry5.ioc.annotations.Inject) - Injection by constructor @Inject CDI beans into tapestry services constructors. Beans can then be injected by field or by constructor. - Qualifiers To disambiguate when injecting same type but different implementations, the module provides support for qualifier which is part of CDI specification. You can use qualifiers into pages, components and services. Just use @javax.inject.Named annotation - Helpers Add method helpers to ease the cdi bean instantiation (uncommon but useful if you want to declare some CDI beans in your AppModule to let tapestry manage them) - IOC isolation The module assures to have no conflict with the tapestry's IOC (Inversion of Control). Indeed, as there are beans managed by the java EE container and others beans managed by the framework, work has been made to prevent one to take control over the beans it is not supposed to manage. Code is available at https://github.com/got5/tapestry-cdi If you want to see it in action, you just need to: - Download the sources and mvn install the project - Add the module as a maven dependency for your project - In your project, @Inject your CDI beans into pages, components or services, and that’s pretty much it. *@Inject* *private MyCdiBean bean;* * * *@Inject* *@MyQualifier* *private MyQualifiedBean qualifiedBean;* For other use cases, you can already take a look at the unit tests. A demo project is coming soon. Stay tuned... The contributors of this release are : - Romain Manni Bucau - Nourredine Khadri - Pierre Marot - François Facon Feedbacks are welcome ! Best Regards [1] https://github.com/got5 [2] https://github.com/rmannibucau/cdi-tapestry-contribution [3] https://github.com/magnuskvalheim/tapestry-cdi [4] http://code.google.com/p/flowlogix https://github.com/magnuskvalheim/tapestry-cdi
Re: [ANNOUNCE] Tapestry-cdi contribution
No need to delete your contribution Lenny : ) This module was first implemented to fulfill our need and to replace our internal IOC framework. Now we want to share it. We have been focused on a Tomee environment, though the implementation is not container specific. We also need to handle CDI qualifiers, keep the implementation standard (not Weld specific for instance) and ease its use (no additional configuration other than adding the maven dependency, no conflict with Tapestry IOC, no custom annotation) We would be happy if you can share your experience (maybe you could test it with Glassfish?) and your thoughts. To answer to the previous questions : - It's used in some internal projects and we intend to generalize its use for all our projects. - Is it works even if CDI is turned off ? I'm not sure I understood - I just can say that the tapestry project that use our module doesn't need any beans.xml file (and obviously, if CDI is not used, no need to use the module) - Is the got5 module in Maven central? not for the moment, as it's still a snapshot version - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Prevent overriding services implementation
Hi Howard, Some precisions. I think the term security that i've used can be misleading and maybe inappropriate here. Actually, the purpose is to share an existing common complex business layer (BL) and to expose parts of it depending on the GUIs that uses it (admin, front, segmented by sector/business, ...). It can be useful for big projects, with lot of developers, to be sure that services are used in the dedicated context to help them in their development, frame the process and for a better maintenability without modifying the existant BL. In my mind, it's more a matter of Is the service or method I'm using suits to the GUI i'm developing ? (In the GUI developer point of view as a service user, not mine as a service provider). In development mode, an error message can help him to know : This service or method is not suitable for this GUI (a simple advisor in a module that we would provide for the concerned GUI) But, here , thanks to the easy tapestry extensibility, the developer can redeclare the service in its appModule and works around the rule (even unintentionally :)). So, providing a preventOverriding() method in the ServiceBinder class could be a plus in tapestry-ioc ? or, to a lesser extent, a preventAdvice() method (like the existing preventDecoration()) ? Just a suggestion. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Prevent-overriding-services-implementation-tp3415241p3424766.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Prevent overriding services implementation
Hi, Is there a way to prevent overriding some custom tapestry services implementation? I would want to provide to the developer a third-party library that contains some not-overridable services for security issues (prevent from another implementation, decorators , advisors, ... ). Thus, i would restrict the usage of my services to some functionalities. Thanks. Nourredine. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Prevent-overriding-services-implementation-tp3415241p3415241.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Prevent overriding services implementation
Thiago H. de Paula Figueiredo wrote: I don't think so. You can file a JIRA for that. Done : https://issues.apache.org/jira/browse/TAP5-1471 Thanks for the answer Nourredine. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Prevent-overriding-services-implementation-tp3415241p3415666.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Pb in 'getOrCreateMethod()' ?
Hi,
I'm using page/component inheritence and I noticed a pb since I migrated an
app from Tapestry 5.1 to 5.2.
I try to render 'ComponentB' that extends 'ComponentA' (using extension
points). Both have a property with same name but with a different type
('EntityB' extends 'EntityA'). The error message says that 'EntityA' does
not contain a property named 'bla'. It's true but it is supposed to get
'EntityB' which contains the 'bla' property.
Actually, the problem comes from the 'PropertyWorker' and especially from
'getOrCreateMethod()' method : it is supposed to create a getter on a
property but, instead, it gets it.
The issue is that 'getOrCreateMethod()' does not check the return type (see
method 'match()' in 'InternalClassTransformationImpl'). Indeed, there is a
'TODO' comment about this.
Everything works fine in Tapestry 5.1.
For 5.2, the workaround is to not use the @Property annotation but the issue
remains for workers that use the 'getOrCreateMethod()' method in
page/component inheritence context.
Is it scheduled to check also the return type ? Do I fill a jira ?
Nourredine.
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Pb-in-getOrCreateMethod-tp3403357p3403357.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Pb in 'getOrCreateMethod()' ?
It is to provide GUI extensibility such as extended forms - Here a rough
description :
Entity models :
public class EntityA {
private String foo;
//accessors
...
}
public class EntityB extends EntityA{
private String bla;
//accessors
...
}
ComponentA :
t:form t:id=myForm
foo : input t:type=textfield t:id=foo t:value=myEntity.foo
name=foo/
t:extension-point id=formExtension/
//submit button...
...
/t:form
public class ComponentA.java {
@Persist
private EntityA myEntity;
@OnEvent(EventConstants.PREPARE_FOR_RENDER)
public void init(){
myEntity = new EntityA();
}
@OnEvent(EventConstants.SUCCESS)
public Object success(){
//call manager to persist data
return List.class;
}
//myEntity accessors
...
}
ComponentB :
t:extend xmlns:t=http://tapestry.apache.org/schema/tapestry_5_1_0.xsd;
t:replace id=formExtension
bla : input t:type=textfield t:id=bla
t:value=myEntity.bla
name=bla /
/t:replace
/t:extend
public class ComponentB extends ComponentA {
@Persist
@Property //works with tapestry 5.1, not with 5.2
private EntityB myEntity;
@OnEvent(EventConstants.PREPARE_FOR_RENDER)
public void init(){
myEntity = new EntityB();
//Use setter from the superclass
setEntity(myEntity);
}
// override onsuccess event
@OnEvent(EventConstants.SUCCESS)
public Object sucess(){
//call manager to store data
return List.class;
}
...
}
ComponentA is part of a component library that runs as a standalone app (i
mean it is not a simple base class).
Nourredine.
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Pb-in-getOrCreateMethod-tp3403357p3403616.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Pb in 'getOrCreateMethod()' ?
Thanks Thiago. Yes it will work like you propose even with the @Property annotation in the subclass (avoiding getEntityB()). The fact that we use the same property name is mainly a convenience for developers according to some internal guidelines. By the way, is it ok that the 'getOrCreateMethod()' does not check the return type for a given method signature or that deserves a JIRA ? The initial pb was that the code works with 5.1, not with 5.2 because of the new class transformation implementation. Nourredine. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Pb-in-getOrCreateMethod-tp3403357p3403686.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
