Re: Supporting @EJB annotation in Tapestry classes

2011-08-17 Thread Magnus Kvalheim 
I'm are still very interested in moving from tomcat to a EE6 server like
glassfish in order to adopt standards and benefit from the new stuff.

Have not found time to actually replace spring with cdi in our apps.
There were also stuff we need to find a different solution for when moving
away from spring/tomcat to glassfish.

Like:
* how to do opensessioninview (OSIV) pattern with ejb's (were currently
using spring here as well): (this looks promising though
http://ocpsoft.com/java/spring-to-java-ee-a-migration-guide-cdi-jsf-jpa-jta-ejb/
)
* live reload with glassfish - not yet resolved
* some issues where debugging failed with glassfish/wtp plugin for eclipse
(possibly a jdk issue)

I have today revisited the CDIModule I used for integration test/research.

In order to address the 'issue' with Ordering of CDIProvider I attempted to
make a new annotation - @CDI.
The idea was that this would be used for injection instead of tapestry's
@inject.
I took - as you suggested - inspiration from @PersistenceContext in
tapestry-jpa.
This actually worked fine and is now injecting beans from cdi.

Then I revisited the CDIProvider and its ordered contribution
to MasterObjectProvider.
Turns out it is indeed last in chain
 - I have however no idea why it is asked to provide object for a defined
tapestry service though. *Is there something called after that is supposed
to resolve a service after all Objectproviders have been asked?*
If so - then how can I get CDIProvider to come after this?

It is possible to specify exclusions in beans.xml (weld has extensions), but
I'd rather have it's just working out of the box.


So what I have implemented is:
* CDIProvider contributed to MasterObjectProvider - allows for cdi managed
beans to be injected with tapestry's @Inject
* @CDI annotation which can be used as alternative to @Inject. (An @EJB
annotation would have similar implementation). Using this annotation will
also sidestep the Objectprovider conendrum.

I've tested beans with @ApplicationScoped and @RequestScoped and it works
great! Guess @ConversationScoped would work too  - have got to test that
next :)

Perhaps I should upload/host the CDIModule somewhere - seems like others can
benefit from it as well...

--magnus

On Wed, Aug 17, 2011 at 5:28 AM, Lenny Primak lpri...@hope.nyc.ny.uswrote:

 I just took a look at that post, but it leaves a lot of unanswered
 questions,
 actually more questions than answers.

 I know tapestry-jpa made @PersistenceContext work within Tapestry,
 which is similar.  I am going to look at that.
 Perhaps Igor can shed some light on this.

 Thanks again.

 On Aug 14, 2011, at 8:10 AM, Thiago H. de Paula Figueiredo wrote:

  On Sat, 13 Aug 2011 15:37:43 -0300, Lenny Primak lpri...@hope.nyc.ny.us
 wrote:
 
  Hi guys,
 
  Hi!
 
  I am developing a front-end in Tapestry for an EJB application (EJB
 3.1/JEE 6) Its getting really annoying to build Tapestry services for each
 of the EJBs. Do you have any suggestions on how to support @EJB annotation
 instead?
 
  Magnus did something this, but for CDI, and posted in this mailing list:
 http://tapestry.1045711.n5.nabble.com/First-stab-at-CDI-module-for-tapestry-td4469281.html.
 I haven't used CDI nor EJB, so I don't know if its solution can be used for
 EJB without any changes. Even if not, the approach would be very similar.
 
  --
  Thiago H. de Paula Figueiredo
  Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
 and instructor
  Owner, Ars Machina Tecnologia da Informação Ltda.
  http://www.arsmachina.com.br
 


 -
 To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Supporting @EJB annotation in Tapestry classes

2011-08-17 Thread Lenny Primak 




On Aug 17, 2011, at 11:08 AM, Magnus Kvalheim mag...@kvalheim.dk wrote:

 I'm are still very interested in moving from tomcat to a EE6 server like
 glassfish in order to adopt standards and benefit from the new stuff.
 
 Have not found time to actually replace spring with cdi in our apps.
 There were also stuff we need to find a different solution for when moving
 away from spring/tomcat to glassfish.
 
 Like:
 * how to do opensessioninview (OSIV) pattern with ejb's (were currently
 using spring here as well): (this looks promising though
 http://ocpsoft.com/java/spring-to-java-ee-a-migration-guide-cdi-jsf-jpa-jta-ejb/
 )
 * live reload with glassfish - not yet resolved
 * some issues where debugging failed with glassfish/wtp plugin for eclipse
 (possibly a jdk issue)
 
 I have today revisited the CDIModule I used for integration test/research.
 
 In order to address the 'issue' with Ordering of CDIProvider I attempted to
 make a new annotation - @CDI.
 The idea was that this would be used for injection instead of tapestry's
 @inject.
 I took - as you suggested - inspiration from @PersistenceContext in
 tapestry-jpa.
 This actually worked fine and is now injecting beans from cdi.
 
 Then I revisited the CDIProvider and its ordered contribution
 to MasterObjectProvider.
 Turns out it is indeed last in chain
 - I have however no idea why it is asked to provide object for a defined
 tapestry service though. *Is there something called after that is supposed
 to resolve a service after all Objectproviders have been asked?*
 If so - then how can I get CDIProvider to come after this?
 
 It is possible to specify exclusions in beans.xml (weld has extensions), but
 I'd rather have it's just working out of the box.
 
 
 So what I have implemented is:
 * CDIProvider contributed to MasterObjectProvider - allows for cdi managed
 beans to be injected with tapestry's @Inject
 * @CDI annotation which can be used as alternative to @Inject. (An @EJB
 annotation would have similar implementation). Using this annotation will
 also sidestep the Objectprovider conendrum.
 
 I've tested beans with @ApplicationScoped and @RequestScoped and it works
 great! Guess @ConversationScoped would work too  - have got to test that
 next :)
 
 Perhaps I should upload/host the CDIModule somewhere - seems like others can
 benefit from it as well...
 
 --magnus
 
 On Wed, Aug 17, 2011 at 5:28 AM, Lenny Primak lpri...@hope.nyc.ny.uswrote:
 
 I just took a look at that post, but it leaves a lot of unanswered
 questions,
 actually more questions than answers.
 
 I know tapestry-jpa made @PersistenceContext work within Tapestry,
 which is similar.  I am going to look at that.
 Perhaps Igor can shed some light on this.
 
 Thanks again.
 
 On Aug 14, 2011, at 8:10 AM, Thiago H. de Paula Figueiredo wrote:
 
 On Sat, 13 Aug 2011 15:37:43 -0300, Lenny Primak lpri...@hope.nyc.ny.us
 wrote:
 
 Hi guys,
 
 Hi!
 
 I am developing a front-end in Tapestry for an EJB application (EJB
 3.1/JEE 6) Its getting really annoying to build Tapestry services for each
 of the EJBs. Do you have any suggestions on how to support @EJB annotation
 instead?
 
 Magnus did something this, but for CDI, and posted in this mailing list:
 http://tapestry.1045711.n5.nabble.com/First-stab-at-CDI-module-for-tapestry-td4469281.html.
 I haven't used CDI nor EJB, so I don't know if its solution can be used for
 EJB without any changes. Even if not, the approach would be very similar.
 
 --
 Thiago H. de Paula Figueiredo
 Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
 and instructor
 Owner, Ars Machina Tecnologia da Informação Ltda.
 http://www.arsmachina.com.br
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: users-h...@tapestry.apache.org
 
 

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Supporting @EJB annotation in Tapestry classes

2011-08-17 Thread Lenny Primak 
Can you create a github project for cdimodule?  I would love to be a part of 
that. 

Regarding live class reloading, my solution to that was to use 'skinny' war 
files and put tapestry jars into domain/lib directory in glassfish. This makes 
redeploys Lightning fast and glassfish saves session state to boot. 
Not quite live reloading but it works well and also works for EJBs and web 
services that are within the app. 

Do you think you can make an EJB annotation so I can test and contribute to 
your module easier?  I have no 'plain' CDI beans to teat with nor do I have 
beans.xml. 

Thanks!

On Aug 17, 2011, at 11:08 AM, Magnus Kvalheim mag...@kvalheim.dk wrote:

 I'm are still very interested in moving from tomcat to a EE6 server like
 glassfish in order to adopt standards and benefit from the new stuff.
 
 Have not found time to actually replace spring with cdi in our apps.
 There were also stuff we need to find a different solution for when moving
 away from spring/tomcat to glassfish.
 
 Like:
 * how to do opensessioninview (OSIV) pattern with ejb's (were currently
 using spring here as well): (this looks promising though
 http://ocpsoft.com/java/spring-to-java-ee-a-migration-guide-cdi-jsf-jpa-jta-ejb/
 )
 * live reload with glassfish - not yet resolved
 * some issues where debugging failed with glassfish/wtp plugin for eclipse
 (possibly a jdk issue)
 
 I have today revisited the CDIModule I used for integration test/research.
 
 In order to address the 'issue' with Ordering of CDIProvider I attempted to
 make a new annotation - @CDI.
 The idea was that this would be used for injection instead of tapestry's
 @inject.
 I took - as you suggested - inspiration from @PersistenceContext in
 tapestry-jpa.
 This actually worked fine and is now injecting beans from cdi.
 
 Then I revisited the CDIProvider and its ordered contribution
 to MasterObjectProvider.
 Turns out it is indeed last in chain
 - I have however no idea why it is asked to provide object for a defined
 tapestry service though. *Is there something called after that is supposed
 to resolve a service after all Objectproviders have been asked?*
 If so - then how can I get CDIProvider to come after this?
 
 It is possible to specify exclusions in beans.xml (weld has extensions), but
 I'd rather have it's just working out of the box.
 
 
 So what I have implemented is:
 * CDIProvider contributed to MasterObjectProvider - allows for cdi managed
 beans to be injected with tapestry's @Inject
 * @CDI annotation which can be used as alternative to @Inject. (An @EJB
 annotation would have similar implementation). Using this annotation will
 also sidestep the Objectprovider conendrum.
 
 I've tested beans with @ApplicationScoped and @RequestScoped and it works
 great! Guess @ConversationScoped would work too  - have got to test that
 next :)
 
 Perhaps I should upload/host the CDIModule somewhere - seems like others can
 benefit from it as well...
 
 --magnus
 
 On Wed, Aug 17, 2011 at 5:28 AM, Lenny Primak lpri...@hope.nyc.ny.uswrote:
 
 I just took a look at that post, but it leaves a lot of unanswered
 questions,
 actually more questions than answers.
 
 I know tapestry-jpa made @PersistenceContext work within Tapestry,
 which is similar.  I am going to look at that.
 Perhaps Igor can shed some light on this.
 
 Thanks again.
 
 On Aug 14, 2011, at 8:10 AM, Thiago H. de Paula Figueiredo wrote:
 
 On Sat, 13 Aug 2011 15:37:43 -0300, Lenny Primak lpri...@hope.nyc.ny.us
 wrote:
 
 Hi guys,
 
 Hi!
 
 I am developing a front-end in Tapestry for an EJB application (EJB
 3.1/JEE 6) Its getting really annoying to build Tapestry services for each
 of the EJBs. Do you have any suggestions on how to support @EJB annotation
 instead?
 
 Magnus did something this, but for CDI, and posted in this mailing list:
 http://tapestry.1045711.n5.nabble.com/First-stab-at-CDI-module-for-tapestry-td4469281.html.
 I haven't used CDI nor EJB, so I don't know if its solution can be used for
 EJB without any changes. Even if not, the approach would be very similar.
 
 --
 Thiago H. de Paula Figueiredo
 Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
 and instructor
 Owner, Ars Machina Tecnologia da Informação Ltda.
 http://www.arsmachina.com.br
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: users-h...@tapestry.apache.org
 
 

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Supporting @EJB annotation in Tapestry classes

2011-08-17 Thread Magnus Kvalheim 
Hi Lenny,


On Wed, Aug 17, 2011 at 5:41 PM, Lenny Primak lpri...@hope.nyc.ny.uswrote:

 Can you create a github project for cdimodule?  I would love to be a part
 of that.


I have not yet tried git - so this could be a good excuse for that :)
I'll look into that soon - would be cool to have other try and
possibly contribute as well!


 Regarding live class reloading, my solution to that was to use 'skinny' war
 files and put tapestry jars into domain/lib directory in glassfish. This
 makes redeploys Lightning fast and glassfish saves session state to boot.
 Not quite live reloading but it works well and also works for EJBs and web
 services that are within the app.


Great - I'll have to test that with my setup. Hopefully the turnaround will
be acceptable


 Do you think you can make an EJB annotation so I can test and contribute to
 your module easier?  I have no 'plain' CDI beans to teat with nor do I have
 beans.xml.


The code for CDI annotationworker is simple.

*public class CDIAnnotationWorker implements ComponentClassTransformWorker {
*
* private CDIFactory cdiFactory;*
* public CDIAnnotationWorker(CDIFactory cdiFactory) {*
* this.cdiFactory = cdiFactory;*
* }*
* public void transform(ClassTransformation transformation,*
* MutableComponentModel model) {*
* for(final TransformField field :
transformation.matchFieldsWithAnnotation(CDI.class)) {*
* final CDI annotation = field.getAnnotation(CDI.class);*
* String fieldType = field.getType();*
*Class type = transformation.toClass(fieldType);*
*final Object injectionValue = cdiFactory.get(type);*
**
*if(injectionValue!=null) {*
*field.inject(injectionValue);*
*field.claim(annotation);*
*}*
* } *
* }*
*}*
*
*
 I'm sure you can adapt to support EJB by getting needed info from
annotation values and do the context lookup.
Perhaps use class/interface type as default jndi name so you don't need to
specify annotation values?
If no values are needed for ejb annotation, then an objectprovider could be
contributed to masterobjectprovider as well and you could use standard
@inject

Without knowing details I think you could possibly reuse
the JNDIObjectLocator from jumpstart for worker and/or masterobjectprovider.
*
*
*From CDIModule configuration*
*...*
@Contribute(ComponentClassTransformWorker.class)
public static void
provideClassTransformWorkers(OrderedConfigurationComponentClassTransformWorker
configuration) {
 configuration.addInstance(CDI, CDIAnnotationWorker.class,
before:Property);
}

Hope that helps a bit. As I mentioned I'll try to get CDIModule up in github
soon...

--magnus


 Thanks!

 On Aug 17, 2011, at 11:08 AM, Magnus Kvalheim mag...@kvalheim.dk wrote:

  I'm are still very interested in moving from tomcat to a EE6 server like
  glassfish in order to adopt standards and benefit from the new stuff.
 
  Have not found time to actually replace spring with cdi in our apps.
  There were also stuff we need to find a different solution for when
 moving
  away from spring/tomcat to glassfish.
 
  Like:
  * how to do opensessioninview (OSIV) pattern with ejb's (were currently
  using spring here as well): (this looks promising though
 
 http://ocpsoft.com/java/spring-to-java-ee-a-migration-guide-cdi-jsf-jpa-jta-ejb/
  )
  * live reload with glassfish - not yet resolved
  * some issues where debugging failed with glassfish/wtp plugin for
 eclipse
  (possibly a jdk issue)
 
  I have today revisited the CDIModule I used for integration
 test/research.
 
  In order to address the 'issue' with Ordering of CDIProvider I attempted
 to
  make a new annotation - @CDI.
  The idea was that this would be used for injection instead of tapestry's
  @inject.
  I took - as you suggested - inspiration from @PersistenceContext in
  tapestry-jpa.
  This actually worked fine and is now injecting beans from cdi.
 
  Then I revisited the CDIProvider and its ordered contribution
  to MasterObjectProvider.
  Turns out it is indeed last in chain
  - I have however no idea why it is asked to provide object for a defined
  tapestry service though. *Is there something called after that is
 supposed
  to resolve a service after all Objectproviders have been asked?*
  If so - then how can I get CDIProvider to come after this?
 
  It is possible to specify exclusions in beans.xml (weld has extensions),
 but
  I'd rather have it's just working out of the box.
 
 
  So what I have implemented is:
  * CDIProvider contributed to MasterObjectProvider - allows for cdi
 managed
  beans to be injected with tapestry's @Inject
  * @CDI annotation which can be used as alternative to @Inject. (An @EJB
  annotation would have similar implementation). Using this annotation will
  also sidestep the Objectprovider conendrum.
 
  I've tested beans with @ApplicationScoped and @RequestScoped and it works
  great! Guess @ConversationScoped would work too  - have got to test that
  next :)
 
  Perhaps I should upload/host

Re: Supporting @EJB annotation in Tapestry classes

2011-08-17 Thread Magnus Kvalheim 
On Wed, Aug 17, 2011 at 6:12 PM, Thiago H. de Paula Figueiredo 
thiag...@gmail.com wrote:

 On Wed, 17 Aug 2011 12:08:12 -0300, Magnus Kvalheim mag...@kvalheim.dk
 wrote:

 I'm are still very interested in moving from tomcat to a EE6 server like
 glassfish in order to adopt standards and benefit from the new stuff.


 Why not EJB 3.1's embedded mode? This way, you can run EJB like a package
 instead as a container. At least OpenEJB supports that.


Yes sure, if that's feasible. I was attracted to glassfish as it's battle
tested, with great features and tooling, but it's worth having a look at
other options like OpenEJB. Thanks I'll check it out :)


  In order to address the 'issue' with Ordering of CDIProvider I attempted
 to
 make a new annotation - @CDI.
 The idea was that this would be used for injection instead of tapestry's
 @inject.


 Why not javax.injection.@Inject from JSR 330? Tapestry already supports
 that: http://tapestry.apache.org/**using-jsr-330-standard-**
 annotations.htmlhttp://tapestry.apache.org/using-jsr-330-standard-annotations.html
  and http://blog.tapestry5.de/**index.php/2011/01/17/javax-**
 inject-inject-support-in-**tapestry/http://blog.tapestry5.de/index.php/2011/01/17/javax-inject-inject-support-in-tapestry/


Aren't those interchangeable so that it will work same as tapestry's
@inject? wouldn't that conflict with tapestry 5.3?
@CDI annotation is the alternative that don't go though the
masterobjectprovider for providing injection.



  - I have however no idea why it is asked to provide object for a defined
 tapestry service though. *Is there something called after that is supposed
 to resolve a service after all Objectproviders have been asked?*


 I'm not sure, but I guess that's exactly how Tapestry-IoC deals with
 ObjectProviders.


hmm.. so perhaps I need to do it some other way. I'll debug and look closer
to whats actually going on when resolving dependencies and see if I can find
a better solution.
Please let me know if anyone has suggestions :)


 --
 Thiago H. de Paula Figueiredo
 Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
 and instructor
 Owner, Ars Machina Tecnologia da Informação Ltda.
 http://www.arsmachina.com.br



On Wed, Aug 17, 2011 at 9:45 PM, Magnus Kvalheim mag...@kvalheim.dk wrote:

 Hi Lenny,


 On Wed, Aug 17, 2011 at 5:41 PM, Lenny Primak lpri...@hope.nyc.ny.uswrote:

 Can you create a github project for cdimodule?  I would love to be a part
 of that.


 I have not yet tried git - so this could be a good excuse for that :)
 I'll look into that soon - would be cool to have other try and
 possibly contribute as well!


 Regarding live class reloading, my solution to that was to use 'skinny'
 war files and put tapestry jars into domain/lib directory in glassfish. This
 makes redeploys Lightning fast and glassfish saves session state to boot.
 Not quite live reloading but it works well and also works for EJBs and web
 services that are within the app.


 Great - I'll have to test that with my setup. Hopefully the turnaround will
 be acceptable


 Do you think you can make an EJB annotation so I can test and contribute
 to your module easier?  I have no 'plain' CDI beans to teat with nor do I
 have beans.xml.


 The code for CDI annotationworker is simple.

 *public class CDIAnnotationWorker implements ComponentClassTransformWorker
 {*
 * private CDIFactory cdiFactory;*
 * public CDIAnnotationWorker(CDIFactory cdiFactory) {*
 * this.cdiFactory = cdiFactory;*
 * }*
 * public void transform(ClassTransformation transformation,*
 * MutableComponentModel model) {*
 * for(final TransformField field :
 transformation.matchFieldsWithAnnotation(CDI.class)) {*
 * final CDI annotation = field.getAnnotation(CDI.class);*
 * String fieldType = field.getType();*
 *Class type = transformation.toClass(fieldType);*
 *final Object injectionValue = cdiFactory.get(type);*
 **
 *if(injectionValue!=null) {*
 *field.inject(injectionValue);*
 *field.claim(annotation);*
 *}*
 * } *
 * }*
 *}*
 *
 *
  I'm sure you can adapt to support EJB by getting needed info from
 annotation values and do the context lookup.
 Perhaps use class/interface type as default jndi name so you don't need to
 specify annotation values?
 If no values are needed for ejb annotation, then an objectprovider could be
 contributed to masterobjectprovider as well and you could use standard
 @inject

 Without knowing details I think you could possibly reuse
 the JNDIObjectLocator from jumpstart for worker and/or masterobjectprovider.
 *
 *
 *From CDIModule configuration*
 *...*
 @Contribute(ComponentClassTransformWorker.class)
 public static void
 provideClassTransformWorkers(OrderedConfigurationComponentClassTransformWorker
 configuration) {
  configuration.addInstance(CDI, CDIAnnotationWorker.class,
 before:Property);
 }

 Hope that helps a bit. As I mentioned I'll try to get CDIModule up in

Re: Supporting @EJB annotation in Tapestry classes

2011-08-17 Thread Lenny Primak 
The biggest advantage of using glassfish is that everything is pre-configured 
for you,
you don't need to deal with any dependencies, no putting stuff together 
yourself,
it 'just works' and y you get everything - Tapestry, REST, WebServices, EJB,
the whole stack with zero effort.


On Aug 17, 2011, at 4:20 PM, Magnus Kvalheim wrote:

 On Wed, Aug 17, 2011 at 6:12 PM, Thiago H. de Paula Figueiredo 
 thiag...@gmail.com wrote:
 
 On Wed, 17 Aug 2011 12:08:12 -0300, Magnus Kvalheim mag...@kvalheim.dk
 wrote:
 
 I'm are still very interested in moving from tomcat to a EE6 server like
 glassfish in order to adopt standards and benefit from the new stuff.
 
 
 Why not EJB 3.1's embedded mode? This way, you can run EJB like a package
 instead as a container. At least OpenEJB supports that.
 
 
 Yes sure, if that's feasible. I was attracted to glassfish as it's battle
 tested, with great features and tooling, but it's worth having a look at
 other options like OpenEJB. Thanks I'll check it out :)
 
 
 In order to address the 'issue' with Ordering of CDIProvider I attempted
 to
 make a new annotation - @CDI.
 The idea was that this would be used for injection instead of tapestry's
 @inject.
 
 
 Why not javax.injection.@Inject from JSR 330? Tapestry already supports
 that: http://tapestry.apache.org/**using-jsr-330-standard-**
 annotations.htmlhttp://tapestry.apache.org/using-jsr-330-standard-annotations.html
 and http://blog.tapestry5.de/**index.php/2011/01/17/javax-**
 inject-inject-support-in-**tapestry/http://blog.tapestry5.de/index.php/2011/01/17/javax-inject-inject-support-in-tapestry/
 
 
 Aren't those interchangeable so that it will work same as tapestry's
 @inject? wouldn't that conflict with tapestry 5.3?
 @CDI annotation is the alternative that don't go though the
 masterobjectprovider for providing injection.
 
 
 
 - I have however no idea why it is asked to provide object for a defined
 tapestry service though. *Is there something called after that is supposed
 to resolve a service after all Objectproviders have been asked?*
 
 
 I'm not sure, but I guess that's exactly how Tapestry-IoC deals with
 ObjectProviders.
 
 
 hmm.. so perhaps I need to do it some other way. I'll debug and look closer
 to whats actually going on when resolving dependencies and see if I can find
 a better solution.
 Please let me know if anyone has suggestions :)
 
 
 --
 Thiago H. de Paula Figueiredo
 Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
 and instructor
 Owner, Ars Machina Tecnologia da Informação Ltda.
 http://www.arsmachina.com.br
 
 
 
 On Wed, Aug 17, 2011 at 9:45 PM, Magnus Kvalheim mag...@kvalheim.dk wrote:
 
 Hi Lenny,
 
 
 On Wed, Aug 17, 2011 at 5:41 PM, Lenny Primak lpri...@hope.nyc.ny.uswrote:
 
 Can you create a github project for cdimodule?  I would love to be a part
 of that.
 
 
 I have not yet tried git - so this could be a good excuse for that :)
 I'll look into that soon - would be cool to have other try and
 possibly contribute as well!
 
 
 Regarding live class reloading, my solution to that was to use 'skinny'
 war files and put tapestry jars into domain/lib directory in glassfish. This
 makes redeploys Lightning fast and glassfish saves session state to boot.
 Not quite live reloading but it works well and also works for EJBs and web
 services that are within the app.
 
 
 Great - I'll have to test that with my setup. Hopefully the turnaround will
 be acceptable
 
 
 Do you think you can make an EJB annotation so I can test and contribute
 to your module easier?  I have no 'plain' CDI beans to teat with nor do I
 have beans.xml.
 
 
 The code for CDI annotationworker is simple.
 
 *public class CDIAnnotationWorker implements ComponentClassTransformWorker
 {*
 * private CDIFactory cdiFactory;*
 * public CDIAnnotationWorker(CDIFactory cdiFactory) {*
 * this.cdiFactory = cdiFactory;*
 * }*
 * public void transform(ClassTransformation transformation,*
 * MutableComponentModel model) {*
 * for(final TransformField field :
 transformation.matchFieldsWithAnnotation(CDI.class)) {*
 * final CDI annotation = field.getAnnotation(CDI.class);*
 * String fieldType = field.getType();*
 *Class type = transformation.toClass(fieldType);*
 *final Object injectionValue = cdiFactory.get(type);*
 **
 *if(injectionValue!=null) {*
 *field.inject(injectionValue);*
 *field.claim(annotation);*
 *}*
 * } *
 * }*
 *}*
 *
 *
 I'm sure you can adapt to support EJB by getting needed info from
 annotation values and do the context lookup.
 Perhaps use class/interface type as default jndi name so you don't need to
 specify annotation values?
 If no values are needed for ejb annotation, then an objectprovider could be
 contributed to masterobjectprovider as well and you could use standard
 @inject
 
 Without knowing details I think you could possibly reuse
 the JNDIObjectLocator from jumpstart for worker and/or

Re: Supporting @EJB annotation in Tapestry classes

2011-08-17 Thread Thiago H. de Paula Figueiredo 
On Wed, 17 Aug 2011 17:20:27 -0300, Magnus Kvalheim mag...@kvalheim.dk  
wrote:



Aren't those interchangeable so that it will work same as tapestry's
@inject?


Yes.


wouldn't that conflict with tapestry 5.3?


I don't think so, but I haven't tried it yet. What about you trying it and  
posting the results, as you already started? ;) :)



@CDI annotation is the alternative that don't go though the
masterobjectprovider for providing injection.


From what I've seen in the Tapestry mailing lists, this would be a case of  
just contributing an ObjectProvider to MasterObjectProvider, nothing more.  
I guess you already did that and it worked. I'm not following you.


--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor

Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Supporting @EJB annotation in Tapestry classes

2011-08-17 Thread Chris Mylonas 
This is true.

On 18/08/2011, at 6:26 AM, Lenny Primak wrote:

 The biggest advantage of using glassfish is that everything is pre-configured 
 for you,
 you don't need to deal with any dependencies, no putting stuff together 
 yourself,
 it 'just works' and y you get everything - Tapestry, REST, WebServices, EJB,
 the whole stack with zero effort.
 

And there's no (sic) JBoss5ClasspathURL fixing to do.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Supporting @EJB annotation in Tapestry classes

2011-08-17 Thread Lenny Primak 
That's why I switched to Glassfish from JBoss for this project.
Don't regret it one bit!

On Aug 17, 2011, at 5:50 PM, Chris Mylonas wrote:

 This is true.
 
 On 18/08/2011, at 6:26 AM, Lenny Primak wrote:
 
 The biggest advantage of using glassfish is that everything is 
 pre-configured for you,
 you don't need to deal with any dependencies, no putting stuff together 
 yourself,
 it 'just works' and y you get everything - Tapestry, REST, WebServices, EJB,
 the whole stack with zero effort.
 
 
 And there's no (sic) JBoss5ClasspathURL fixing to do.
 -
 To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: users-h...@tapestry.apache.org
 


-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Supporting @EJB annotation in Tapestry classes

2011-08-16 Thread Lenny Primak 
I just took a look at that post, but it leaves a lot of unanswered questions,
actually more questions than answers.

I know tapestry-jpa made @PersistenceContext work within Tapestry,
which is similar.  I am going to look at that.
Perhaps Igor can shed some light on this.

Thanks again.

On Aug 14, 2011, at 8:10 AM, Thiago H. de Paula Figueiredo wrote:

 On Sat, 13 Aug 2011 15:37:43 -0300, Lenny Primak lpri...@hope.nyc.ny.us 
 wrote:
 
 Hi guys,
 
 Hi!
 
 I am developing a front-end in Tapestry for an EJB application (EJB 3.1/JEE 
 6) Its getting really annoying to build Tapestry services for each of the 
 EJBs. Do you have any suggestions on how to support @EJB annotation instead?
 
 Magnus did something this, but for CDI, and posted in this mailing list: 
 http://tapestry.1045711.n5.nabble.com/First-stab-at-CDI-module-for-tapestry-td4469281.html.
  I haven't used CDI nor EJB, so I don't know if its solution can be used for 
 EJB without any changes. Even if not, the approach would be very similar.
 
 -- 
 Thiago H. de Paula Figueiredo
 Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and 
 instructor
 Owner, Ars Machina Tecnologia da Informação Ltda.
 http://www.arsmachina.com.br
 


-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Supporting @EJB annotation in Tapestry classes

2011-08-16 Thread Chris Mylonas 
I'm using ejb3.1/jee6 on a new project -  on jee5 i used the jumpstart method 
of integration - works a treat! 
http://jumpstart.doublenegative.com.au/jumpstart/examples/state/ejb3

sorry if it's been pointed out before

On 17/08/2011, at 1:28 PM, Lenny Primak wrote:

 I just took a look at that post, but it leaves a lot of unanswered questions,
 actually more questions than answers.
 
 I know tapestry-jpa made @PersistenceContext work within Tapestry,
 which is similar.  I am going to look at that.
 Perhaps Igor can shed some light on this.
 
 Thanks again.
 
 On Aug 14, 2011, at 8:10 AM, Thiago H. de Paula Figueiredo wrote:
 
 On Sat, 13 Aug 2011 15:37:43 -0300, Lenny Primak lpri...@hope.nyc.ny.us 
 wrote:
 
 Hi guys,
 
 Hi!
 
 I am developing a front-end in Tapestry for an EJB application (EJB 3.1/JEE 
 6) Its getting really annoying to build Tapestry services for each of the 
 EJBs. Do you have any suggestions on how to support @EJB annotation instead?
 
 Magnus did something this, but for CDI, and posted in this mailing list: 
 http://tapestry.1045711.n5.nabble.com/First-stab-at-CDI-module-for-tapestry-td4469281.html.
  I haven't used CDI nor EJB, so I don't know if its solution can be used for 
 EJB without any changes. Even if not, the approach would be very similar.
 
 -- 
 Thiago H. de Paula Figueiredo
 Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and 
 instructor
 Owner, Ars Machina Tecnologia da Informação Ltda.
 http://www.arsmachina.com.br
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: users-h...@tapestry.apache.org
 


-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Supporting @EJB annotation in Tapestry classes

2011-08-16 Thread Lenny Primak 
This kind of method is what I am currently using.
My application is a big integration project and code bloat using the method is 
becoming nasty.
I want an elegant method to do this, i.e. @EJB annotation.

On Aug 16, 2011, at 11:33 PM, Chris Mylonas wrote:

 I'm using ejb3.1/jee6 on a new project -  on jee5 i used the jumpstart method 
 of integration - works a treat! 
 http://jumpstart.doublenegative.com.au/jumpstart/examples/state/ejb3
 
 sorry if it's been pointed out before
 
 On 17/08/2011, at 1:28 PM, Lenny Primak wrote:
 
 I just took a look at that post, but it leaves a lot of unanswered questions,
 actually more questions than answers.
 
 I know tapestry-jpa made @PersistenceContext work within Tapestry,
 which is similar.  I am going to look at that.
 Perhaps Igor can shed some light on this.
 
 Thanks again.
 
 On Aug 14, 2011, at 8:10 AM, Thiago H. de Paula Figueiredo wrote:
 
 On Sat, 13 Aug 2011 15:37:43 -0300, Lenny Primak lpri...@hope.nyc.ny.us 
 wrote:
 
 Hi guys,
 
 Hi!
 
 I am developing a front-end in Tapestry for an EJB application (EJB 
 3.1/JEE 6) Its getting really annoying to build Tapestry services for each 
 of the EJBs. Do you have any suggestions on how to support @EJB annotation 
 instead?
 
 Magnus did something this, but for CDI, and posted in this mailing list: 
 http://tapestry.1045711.n5.nabble.com/First-stab-at-CDI-module-for-tapestry-td4469281.html.
  I haven't used CDI nor EJB, so I don't know if its solution can be used 
 for EJB without any changes. Even if not, the approach would be very 
 similar.
 
 -- 
 Thiago H. de Paula Figueiredo
 Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, 
 and instructor
 Owner, Ars Machina Tecnologia da Informação Ltda.
 http://www.arsmachina.com.br
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: users-h...@tapestry.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: users-h...@tapestry.apache.org
 


-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Supporting @EJB annotation in Tapestry classes

2011-08-16 Thread Chris Mylonas 
I know what you mean :)

On 17/08/2011, at 1:36 PM, Lenny Primak wrote:

 This kind of method is what I am currently using.
 My application is a big integration project and code bloat using the method 
 is becoming nasty.
 I want an elegant method to do this, i.e. @EJB annotation.
 
 On Aug 16, 2011, at 11:33 PM, Chris Mylonas wrote:
 
 I'm using ejb3.1/jee6 on a new project -  on jee5 i used the jumpstart 
 method of integration - works a treat! 
 http://jumpstart.doublenegative.com.au/jumpstart/examples/state/ejb3
 
 sorry if it's been pointed out before
 
 On 17/08/2011, at 1:28 PM, Lenny Primak wrote:
 
 I just took a look at that post, but it leaves a lot of unanswered 
 questions,
 actually more questions than answers.
 
 I know tapestry-jpa made @PersistenceContext work within Tapestry,
 which is similar.  I am going to look at that.
 Perhaps Igor can shed some light on this.
 
 Thanks again.
 
 On Aug 14, 2011, at 8:10 AM, Thiago H. de Paula Figueiredo wrote:
 
 On Sat, 13 Aug 2011 15:37:43 -0300, Lenny Primak lpri...@hope.nyc.ny.us 
 wrote:
 
 Hi guys,
 
 Hi!
 
 I am developing a front-end in Tapestry for an EJB application (EJB 
 3.1/JEE 6) Its getting really annoying to build Tapestry services for 
 each of the EJBs. Do you have any suggestions on how to support @EJB 
 annotation instead?
 
 Magnus did something this, but for CDI, and posted in this mailing list: 
 http://tapestry.1045711.n5.nabble.com/First-stab-at-CDI-module-for-tapestry-td4469281.html.
  I haven't used CDI nor EJB, so I don't know if its solution can be used 
 for EJB without any changes. Even if not, the approach would be very 
 similar.
 
 -- 
 Thiago H. de Paula Figueiredo
 Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, 
 and instructor
 Owner, Ars Machina Tecnologia da Informação Ltda.
 http://www.arsmachina.com.br
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: users-h...@tapestry.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: users-h...@tapestry.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: users-h...@tapestry.apache.org
 


-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Supporting @EJB annotation in Tapestry classes

2011-08-13 Thread Lenny Primak 
Hi guys,

I am developing a front-end in Tapestry for an EJB application (EJB 3.1/JEE 6)
Its getting really annoying to build Tapestry services for each of the EJBs.
Do you have any suggestions on how to support @EJB annotation instead?

Thanks!


-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org