1 2 3 4 Previous Next 59 Replies Latest reply on Oct 15, 2012 6:43 AM by chrisharris Go to original post
      • 15. Re: How do I get a JPA EntityManager reference in Weld?
        nickarls

        They shouldn't be confused. I never though, Oh, now I'm using the stuff from seam-core.jar and now I'm using stuff from...


        You could build a web app on plain JSF 1 (sure, it was no fun). You can build a web app on top of JSF 2 and CDI too (fun) or with frameworks that build on these (even more fun)


        Why should Weld support anything outside the CDI spec? That would be plain wrong, that's the job of other layers as Gavin said.


        I don't think (hope) the confusion is that wide-spread ;-)

        • 16. Re: How do I get a JPA EntityManager reference in Weld?
          gavin.king

          Steven,


          You asked for it, so here it is :-)


          Here is a portable extension that will create a managed JPA persistence context of any scope if you declare a producer field like this:


          @Produces @ApplicationScoped 
          @PersistenceContext(unitName="foo")
          EntityManager em;



          In one of your beans. (As long as you have a META-INF/persistence.xml file with a persistence unit named "foo".)


          package org.seamframework.persistence;
          
          import java.lang.annotation.Annotation;
          import java.lang.reflect.Type;
          import java.util.Collections;
          import java.util.HashSet;
          import java.util.Set;
          
          import javax.enterprise.context.ApplicationScoped;
          import javax.enterprise.context.spi.CreationalContext;
          import javax.enterprise.event.Observes;
          import javax.enterprise.inject.Alternative;
          import javax.enterprise.inject.Any;
          import javax.enterprise.inject.Default;
          import javax.enterprise.inject.spi.AfterBeanDiscovery;
          import javax.enterprise.inject.spi.AnnotatedField;
          import javax.enterprise.inject.spi.Bean;
          import javax.enterprise.inject.spi.BeanManager;
          import javax.enterprise.inject.spi.Extension;
          import javax.enterprise.inject.spi.InjectionPoint;
          import javax.enterprise.inject.spi.ProcessProducer;
          import javax.enterprise.inject.spi.Producer;
          import javax.enterprise.util.AnnotationLiteral;
          import javax.inject.Qualifier;
          import javax.persistence.EntityManager;
          import javax.persistence.EntityManagerFactory;
          import javax.persistence.Persistence;
          import javax.persistence.PersistenceContext;
          
          /**
           * Support for managed persistence contexts in Java SE environment.
           * 
           * @author Gavin King
           * 
           */
          public class PersistenceContextExtension implements Extension {
               
               private Bean<EntityManagerFactory> emfBean;
               
               /**
                * For @PersistenceContext producer fields, make a bean for the EMF, then
                * wrap the producer CDI creates, to get the EM from the EMF bean we made
                * instead of trying to get it from the Java EE component environment.
                */
               void processProducer(@Observes ProcessProducer<?, EntityManager> pp, final BeanManager bm) {
                              
                    if ( pp.getAnnotatedMember().isAnnotationPresent(PersistenceContext.class) ) {
                         
                         if (emfBean==null) {
                              AnnotatedField<?> field = (AnnotatedField<?>) pp.getAnnotatedMember();
                              final String unitName = field.getAnnotation(PersistenceContext.class).unitName();
                              final Class<?> module = field.getJavaMember().getDeclaringClass();
                              final Set<Annotation> qualifiers = new HashSet<Annotation>();
                              for (Annotation ann: field.getAnnotations()) {
                                   Class<? extends Annotation> annotationType = ann.annotationType();
                                   //if ( bm.isQualifier(annotationType)) {
                                   if ( annotationType.isAnnotationPresent(Qualifier.class) ) { //work around bug in Weld
                                        qualifiers.add(ann);
                                   }
                              }
                              if ( qualifiers.isEmpty() ) {
                                   qualifiers.add( new AnnotationLiteral<Default>() {} );
                              }
                              qualifiers.add( new AnnotationLiteral<Any>() {} );
                              final boolean alternative = field.isAnnotationPresent(Alternative.class);
                              final Set<Type> types = new HashSet<Type>() { { 
                                   add(EntityManagerFactory.class);
                                   add(Object.class);
                              } };
                              
                              //create a bean for the EMF
                              emfBean = new Bean<EntityManagerFactory>() {
                                   @Override
                                   public Set<Type> getTypes() {
                                        return types;
                                   }
                                   @Override
                                   public Class<? extends Annotation> getScope() {
                                        return ApplicationScoped.class;
                                   }
                                   @Override
                                   public EntityManagerFactory create(CreationalContext<EntityManagerFactory> ctx) {
                                        return Persistence.createEntityManagerFactory(unitName);
                                   }
                                   @Override
                                   public void destroy(EntityManagerFactory emf, CreationalContext<EntityManagerFactory> ctx) {
                                        emf.close();
                                        ctx.release();
                                   }
                                   @Override
                                   public Class<?> getBeanClass() {
                                        return module;
                                   }
                                   @Override
                                   public Set<InjectionPoint> getInjectionPoints() {
                                        return Collections.EMPTY_SET;
                                   }
                                   @Override
                                   public String getName() {
                                        return null;
                                   }
                                   @Override
                                   public Set<Annotation> getQualifiers() {
                                        return qualifiers;
                                   }
                                   @Override
                                   public Set<Class<? extends Annotation>> getStereotypes() {
                                        return Collections.EMPTY_SET; //TODO!
                                   }
                                   @Override
                                   public boolean isAlternative() {
                                        return alternative;
                                   }
                                   @Override
                                   public boolean isNullable() {
                                        return false;
                                   }
                              };
          
                         }
                         else {
                              throw new RuntimeException("Only one EMF per application is supported");
                         }
                         
                         Producer<EntityManager> producer = new Producer<EntityManager>() {
                              @Override
                              public Set<InjectionPoint> getInjectionPoints() {
                                   return Collections.EMPTY_SET;
                              }
                              @Override
                              public EntityManager produce(CreationalContext<EntityManager> ctx) {
                                   return getFactory(ctx).createEntityManager();
                              }
                              private EntityManagerFactory getFactory(CreationalContext<EntityManager> ctx) {
                                   return (EntityManagerFactory) bm.getReference(emfBean, EntityManagerFactory.class, ctx);
                              }
                              @Override
                              public void dispose(EntityManager em) {
                                   if (em.isOpen()) //work around what I suspect is a bug in Weld
                                        em.close();
                              }
                         };
                         pp.setProducer(producer);
                    }
               }
               
               /**
                * Register the EMF bean with the container.
                */
               void afterBeanDiscovery(@Observes AfterBeanDiscovery abd) {
                    abd.addBean(emfBean);
               }
               
          }



          Heres an interceptor that will manage the EntityTransaction for you if you annotate a method @Transactional:


          package org.seamframework.tx;
          
          import javax.enterprise.inject.Any;
          import javax.inject.Inject;
          import javax.interceptor.AroundInvoke;
          import javax.interceptor.Interceptor;
          import javax.interceptor.InvocationContext;
          import javax.persistence.EntityManager;
          
          /**
           * Declarative JPA EntityTransactions
           * 
           * @author Gavin King
           *
           */
          @Transactional @Interceptor
          public class EntityTransactionInterceptor {
               
               private @Inject @Any EntityManager em;
               
               @AroundInvoke
               public Object aroundInvoke(InvocationContext ic) throws Exception {
                    boolean act = !em.getTransaction().isActive();
                    if (act) em.getTransaction().begin();
                    try {
                         Object result = ic.proceed();
                         if (act) em.getTransaction().commit();
                         return result;
                    }
                    catch (Exception e) {
                         if (act) em.getTransaction().rollback();
                         throw e;
                    }
               }
          }



          package org.seamframework.tx;
          
          import static java.lang.annotation.ElementType.METHOD;
          import static java.lang.annotation.ElementType.TYPE;
          import static java.lang.annotation.RetentionPolicy.RUNTIME;
          
          import java.lang.annotation.Documented;
          import java.lang.annotation.Retention;
          import java.lang.annotation.Target;
          
          import javax.interceptor.InterceptorBinding;
          
          @Retention(RUNTIME)
          @Target({METHOD, TYPE})
          @Documented
          @InterceptorBinding
          public @interface Transactional {}

          • 17. Re: How do I get a JPA EntityManager reference in Weld?
            nickarls

            Nice! We relly need that Weld Shop section on sfwk so that these don't get scattered around the forums and in.relation.to

            • 18. Re: How do I get a JPA EntityManager reference in Weld?
              sboscarine

              Nicklas Karlsson wrote on Nov 19, 2009 08:48:


              Why should Weld support anything outside the CDI spec? That would be plain wrong, that's the job of other layers as Gavin said.

              I don't think (hope) the confusion is that wide-spread ;-)


              Let me respond to your question with another question. 


              Who is the intended audience of weld? 


              If Weld is nothing more than a tool for framework developers, then I'd say you're absolutely right.  You should clearly state that Weld is not meant for end users but for framework developers.  You should go a step further and put in your announcements and documentation.  End users, please wait for either your container to fully support JEE6 or Seam3. 


              The only reason I or any business developer I know uses dependency injection is to decouple an application from externally configured resources, usually an external service, such as a DB, web service, or SMTP server, or password (usually for encryption) of some sort.


              Why does anyone use DI? 


              I've only seen it used to switch configurations between a test and production setting.  I see it frequently for changing between a JNDI-managed resources, such as a datasource, and a local version for a test.  On extremely large projects, I occasionally  see it for swapping a mock implementation for the real thing.  If it wasn't for testing, I don't think many people would use DI at all.  We don't use DI because we hate constructors.  We use DI because we need to test code (mostly DB) outside a container. 


              As far as spec vs implementation, Hibernate and the MyFaces bundle have extensions that are not part of JSF or JPA.  Nobody really cares whether a feature is part of the spec or not.  They want a tool that makes their job easier.  If you think JPA and JNDI integration doesn't belong in the core spec and implementation, add it to weld-servlet or create a new bundle and name it something like weld-extensions.  If you want, put in the documentation that this is just an adapter because your container is inferior, for a REAL container, use JEE6.  No one cares about these spec distinctions.  Our employers want solutions.  Most developers are just looking for an efficient route to satisfying their customers. 


              Regarding confusion, people are expecting this to replace Spring.  When they think DI, they think Spring and Spring is very effective at injecting dependencies like EntityManagers, JNDI resources, etc.  I think it is very safe to say that Arbi and I will not be the only ones confused that you created DI framework that doesn't inject the actual resources we adopted DI to inject in the first place. 



              I think it is also safe to say that any user you have right now is an early adopter and most of us are sincerely trying to help the weld team make this framework a success.  You put a lot of effort into creating this framework and promoted it to users as if it is meant for regular developers to solve business problems.  The lack of an adapter to handle JPA is a huge omission in usability.  The majority of Java developers use Tomcat.  Most of us could not change the container if we wanted to.  That decision is made by customers and IT managers, not the folks that actually implement solutions.  We certainly cannot use beta containers like JBoss6 or Glassfish v3. 


              Weld could be very successful if you gave it adequate extensions so that today's users can get started with it.  A lot of people are looking to adopt JSF2 will be impressed with its features for JSF integration.  You'll also build up the CDI community and get a lot of people eager to adopt JEE 6 when it is ready for production use. 

              • 19. Re: How do I get a JPA EntityManager reference in Weld?

                Steven Boscarine wrote on Nov 19, 2009 14:50:



                Nicklas Karlsson wrote on Nov 19, 2009 08:48:


                Why should Weld support anything outside the CDI spec? That would be plain wrong, that's the job of other layers as Gavin said.

                I don't think (hope) the confusion is that wide-spread ;-)





                It is not, I for example, want a thinner Weld





                Let me respond to your question with another question. 

                Who is the intended audience of weld? 

                If Weld is nothing more than a tool for framework developers, then I'd say you're absolutely right.  You should clearly state that Weld is not meant for end users but for framework developers.  You should go a step further and put in your announcements and documentation.  End users, please wait for either your container to fully support JEE6 or Seam3. 



                Weld is the core of Seam, it is like Spring without Spring-MVC, Spring-JDBC, Spring-ORM, etc, etc. You can use just the core, or you can use one of the extensions that integrate the core with a particular technology. If what Weld provide is enough for your app, then use it, if it is not, well, create an extension or wait of Seam 3 (and even then some of what Seam 3 might not be what you expect, maybe you prefer AribaWeb over Wicket for presentation, or IBATIS over JPA, in that case, you have 2 choices: Create your own extension, or wait and see if someone else creates them)




                The only reason I or any business developer I know uses dependency injection is to decouple an application from externally configured resources, usually an external service, such as a DB, web service, or SMTP server, or password (usually for encryption) of some sort.

                Why does anyone use DI? 

                I've only seen it used to switch configurations between a test and production setting. I see it frequently for changing between a JNDI-managed resources, such as a datasource, and a local version for a test.





                I guess you are having a problem with the meaning of the word only, first, the only reason is to decouple an application from externally configured resources now the only reason is to switch configurations between a test and production next the only reason will be...



                On extremely large projects, I occasionally  see it for swapping a mock implementation for the real thing.  If it wasn't for testing, I don't think many people would use DI at all.


                Yes, but testing is an unavoidable reality (unless you know the secret for perfect software without testing). So even if DI were only for testing that would mean it is here to stay.



                  We don't use DI because we hate constructors.


                Well, I do not like Java constructors that much...



                We use DI because we need to test code (mostly DB) outside a container. 


                Yes, that is one reason. Clean code that follows the open closed principle is another...



                As far as spec vs implementation, Hibernate and the MyFaces bundle have extensions that are not part of JSF or JPA.  Nobody really cares whether a feature is part of the spec or not.


                I do. And Weld authors do... and I guess the authors of the other specs do... lets change that to some people do not cares whether a feature is part of the spec or not



                  They want a tool that makes their job easier.


                Yes, but they also know tools rarely are perfect, and a tool with a clean architecture is easier to extend and fix. At least in my case one of the reasons I did not contribute to Seam was that it was hard for me to see the boundaries between the core and the extensions (and therefore I did not know how to create one without messing with the core)



                If you think JPA and JNDI integration doesn't belong in the core spec and implementation, add it to weld-servlet or create a new bundle and name it something like weld-extensions.


                Or maybe name it Seam 3? ;-). Now I can see how waiting until all of Seam 3 is ready can be too much. I do not like that idea either... maybe Seam 3 could be released incrementally (extension by extension)?



                If you want, put in the documentation that this is just an adapter because your container is inferior, for a REAL container, use JEE6.  No one cares about these spec distinctions.


                Someone does care. Even if to avoid most of JEE I do care.



                Our employers want solutions.  Most developers are just looking for an efficient route to satisfying their customers. 


                That I agree with. It is probably one of the reasons of the success of spring: it grew fast, and organically, if the Spring guys would have waited until all that is on top of the core was perfect to release it as whole product I think they would not have been as successful.



                Regarding confusion, people are expecting this to replace Spring.


                In some way, yes, but Weld is only a replacement for the core, not for all the Spring extensions that are on top of that core, that, IMO is the job of Seam and of the the community



                When they think DI, they think Spring and Spring is very effective at injecting dependencies like EntityManagers, JNDI resources, etc.  I think it is very safe to say that Arbi and I will not be the only ones confused that you created DI framework that doesn't inject the actual resources we adopted DI to inject in the first place. 


                Spring does not help with JDBC, Spring does not help with MVC, Spring does not do Batching, or help with ORMs, Spring-JDBC, Spring-MVC, Spring-Batch and Spring-ORM do all those things, IMO you need to wait for those to be migrated to Weld.



                I think it is also safe to say that any user you have right now is an early adopter and most of us are sincerely trying to help the weld team make this framework a success.


                I agree with this.



                You put a lot of effort into creating this framework and promoted it to users as if it is meant for regular developers to solve business problems.  The lack of an adapter to handle JPA is a huge omission in usability.


                Yes, it is a huge omission in usability, but not it is not Weld responsibility. It is Seam job.



                The majority of Java developers use Tomcat.  Most of us could not change the container if we wanted to.  That decision is made by customers and IT managers, not the folks that actually implement solutions.


                That is true sometimes. In my case, I still have not found anything better than Tomcat for my particular needs.



                We certainly cannot use beta containers like JBoss6 or Glassfish v3. 


                I agree.



                Weld could be very successful if you gave it adequate extensions so that today's users can get started with it.


                Maybe Seam 3 could be released instead of as one big chunk, as little pieces... incrementally... and Seam releases could convert in to something like the synchronization of plugins that the Eclipse project does every year.



                A lot of people are looking to adopt JSF2 will be impressed with its features for JSF integration.  You'll also build up the CDI community and get a lot of people eager to adopt JEE 6 when it is ready for production use. 


                If the guys at Eclipse tried to do all that the Eclipse community does as a single project, IMO they would spiral out of control really fast. Maybe now that thanks to Weld we have a cleaner architecture Seam should be converted in the syncronized and QA-tested-by-JBoss release of all extensions for Weld. That way we do not need to wait until all of Seam 3 is production ready to have good JPA support, but, if we are willing to wait, we also know that each year we will get a release with all the plugins tested so that they integrate well and provide and unified development experience... what do you think?

                • 20. Re: How do I get a JPA EntityManager reference in Weld?
                  sboscarine

                  Gavin King wrote on Nov 19, 2009 10:03:


                  Steven,

                  You asked for it, so here it is :-)



                  Thank you Gavin.  I really do appreciate your help and quick turnaround time.  I can't wait to test it out.


                  I think a significant part of your first wave of CDI and weld users will want to drop Spring in their applications and start using CDI.  I think you'll really help out CDI if extensions like this were in a jar that could be downloaded from a maven repo. 


                  Do you see a possibility in JBoss creating an extensions module and publishing and maintaining it (with help from the community, of course)?  I think it'll go a long way to making your project successful. 


                  Nickolas,

                  I don't think this belongs in a weld shop.  I think an appstore for CDI is a good idea, but it should be for less conventional integrations. 


                  I think it's safe to say that the majority of your users want JPA, JNDI, and transactions.  I personally think you'll do your users a huge favor if JBoss released a bundle for Tomcat users to bring CDI up to parity with Spring's basic features.  If you have every user maintain their own JPA integration, you're begging for lots of bugs in the wild.  You don't want CDI associated with buggy implementations. 


                  I see weld shop as great for exotic technologies, like  a Berkeley DB DPL extension (that I may write someday) or Francisco's JDBC extension. 




                  I fully understand that @PersistenceContext injection is typically handled by JEE and may not be a good idea for the CDI spec, but JEE wasn't very successful.  Most of us aren't on JEE5. 




                  I can't stress enough that developers rarely pick containers.  Containers are chosen for us by the time we're hired.




                  Suggesting a container upgrade or a switch is huge risk for us in most organizations.  It's a difficult process that can take a year or more in a large company.  With the regression testing and QA needed, it becomes VERY expensive. 


                  Most of us will want to use JEE6 and will have a much greater chance of justifying the switch if we can start our projects in our current containers and show our customers and managers how beneficial it'll be. 



                  Helping us non-JEE users out with pre-built useful extensions, will drastically increase adoption.  With CDI and appropriate, easy-to-use extensions, you have an opportunity to make CDI very successful.  I think you'll get much greater adoption of CDI and JEE6 if you embrace those of use looking to transition, especially Tomcat users. 

                  • 21. Re: How do I get a JPA EntityManager reference in Weld?
                    sboscarine

                    I'm glad you weighed in Francisco. 



                    Francisco Peredo wrote on Nov 19, 2009 16:36:

                    Spring does not help with JDBC, Spring does not help with MVC, Spring does not do Batching, or help with ORMs, Spring-JDBC, Spring-MVC, Spring-Batch and Spring-ORM do all those things, IMO you need to wait for those to be migrated to Weld.


                    I'd argue that injecting a JNDI datasource into my code helps greatly with JDBC.  Spring has done that from day one.  Spring also injects EntityManagers and gives JTA support to tomcat users. Also, I don't care which module provides the capability.  I just want to get my job done efficiently.  I don't even know all the modules I import from Spring and neither I, nor my employer, care. 


                    Do you think many people care if you call something Weld or Seam3?  Do you really care if a module is called Seam3-JPA-apapter-preview or weld?  Most of us want something that helps us do our jobs. 


                    The bottom line is we need JPA.  Most of us Tomcat users rely on Spring to do these things for us.  If we cannot accomplish these tasks in Weld, we can't drop Spring.  If your ultimate goal is JBoss6 and JEE6 adoption, I think they'll be more successful by giving us viable alternatives to Spring so we can transition. 


                    I think the Weld team has a huge opportunity to make this technology successful by providing a solution that can solve business problems, such as JNDI and JPA integration easily.  I'm very thankful Gavin is helping by pasting that code in this forum.  I'm just pushing for them to go a step further and make it readily available and easy to use  because I think small details like can make a huge difference in your adoption. 


                    • 22. Re: How do I get a JPA EntityManager reference in Weld?

                      Steven Boscarine wrote on Nov 19, 2009 16:36:



                      Gavin King wrote on Nov 19, 2009 10:03:


                      Steven,

                      You asked for it, so here it is :-)



                      Thank you Gavin.  I really do appreciate your help and quick turnaround time.  I can't wait to test it out.

                      I think a significant part of your first wave of CDI and weld users will want to drop Spring in their applications and start using CDI.  I think you'll really help out CDI if extensions like this were in a jar that could be downloaded from a maven repo. 



                      That is not a bad idea. That .jar could be the first .jar of what will become Seam 3: Synchronized Release of Weld Extensions 2010



                      Do you see a possibility in JBoss creating an extensions module and publishing and maintaining it (with help from the community, of course)?  I think it'll go a long way to making your project successful. 


                      I guess he does... it is named Seam 3, maybe you have heard about it? ;-)



                      Nickolas,

                      I don't think this belongs in a weld shop.  I think an appstore for CDI is a good idea, but it should be for less conventional integrations. 


                      What is conventional and what is not, is IMO, a matter of opinion.



                      I think it's safe to say that the majority of your users want JPA, JNDI, and transactions.  I personally think you'll do your users a huge favor if JBoss released a bundle for Tomcat users to bring CDI up to parity with Spring's basic features.  If you have every user maintain their own JPA integration, you're begging for lots of bugs in the wild.  You don't want CDI associated with buggy implementations. 


                      That I agree with (although I do not see why it would be useful only for Tomcat).



                      I see weld shop as great for exotic technologies, like  a Berkeley DB DPL extension (that I may write someday) or Francisco's JDBC extension. 


                      Exactly, which is why maybe we should shift Seam 3 focus form being a monolithic solution, to been the result of the coordination of all the extensions for Weld. IMO that approach has worked very well for Eclipse and its ecosystem of plug-ins.




                      I fully understand that @PersistenceContext injection is typically handled by JEE and may not be a good idea for the CDI spec, but JEE wasn't very successful.  Most of us aren't on JEE5. 


                      I agree.



                      I can't stress enough that developers rarely pick containers.  Containers are chosen for us by the time we're hired.


                      Again, this is relative, but I agree that one of the things that made Spring succesful is that it makes it really easy to switch your cointainer.



                      Suggesting a container upgrade or a switch is huge risk for us in most organizations.  It's a difficult process that can take a year or more in a large company.  With the regression testing and QA needed, it becomes VERY expensive. 


                      I agree too.



                      Most of us will want to use JEE6 and will have a much greater chance of justifying the switch if we can start our projects in our current containers and show our customers and managers how beneficial it'll be. 


                      Exactly, JBoss used to have the ability to embed inself into tomcat without modifying tomcat, but, sadly, that feature was dropped, now, if I want to run JBoss in Tomcat I need to modify Tomcat, and the admin of Tomcat in my company will not let me even touch the shared lib folder. So, there is no way to gradually introduce JBoss. We tried to use JBoss only for new project, but quickly realized that a combination of Seam and Spring gave us as much power but it was much more lightweight



                      Helping us non-JEE users out with pre-built useful extensions, will drastically increase adoption.  With CDI and appropriate, easy-to-use extensions, you have an opportunity to make CDI very successful.  I think you'll get much greater adoption of CDI and JEE6 if you embrace those of use looking to transition, especially Tomcat users. 


                      Yes, I agree too. It should be possible to incrementally add the JEE features you need for a particular applicatoin. The fact that Spring is easy to introduce incrementally is IMO one of the reasons of its success (which is why I am so interested in making Weld compatible with JSP and plaing JDBC, so that I can easily introduce it anywhere)

                      • 23. Re: How do I get a JPA EntityManager reference in Weld?

                        Steven Boscarine wrote on Nov 19, 2009 17:01:


                        I'm glad you weighed in Francisco. 


                        Francisco Peredo wrote on Nov 19, 2009 16:36:

                        Spring does not help with JDBC, Spring does not help with MVC, Spring does not do Batching, or help with ORMs, Spring-JDBC, Spring-MVC, Spring-Batch and Spring-ORM do all those things, IMO you need to wait for those to be migrated to Weld.


                        I'd argue that injecting a JNDI datasource into my code helps greatly with JDBC.  Spring has done that from day one.  Spring also injects EntityManagers and gives JTA support to tomcat users. Also, I don't care which module provides the capability.  I just want to get my job done efficiently.  I don't even know all the modules I import from Spring and neither I, nor my employer, care. 


                        Maybe not, but if Spring decided tomorrow to change the API of its Spring-JDBC module you would care. Which is why I think we should be careful about how we extend Weld. If Weld grow in a direction that is incompatible with Seam 2, that will be bad publicity for both of them, people then would not trust APIs release by JBoss because they change too fast and incompatible ways. That is IMO why official Weld extensions should be created within the context of Seam.



                        Do you think many people care if you call something Weld or Seam3?


                        Well, for starters, if the project changes its name, you will not be able to compile because all your imports are now wrong ;-). On a more serious not, dropping the name would send a bad message to the community: That Seam is a dead end, that is not going to grow, that there is now a better but incompatible way to inject JPA in your app, and that you better start redoing stuff the weld way until maybe the next year Braze is released and you have to start from scratch again.



                        Do you really care if a module is called Seam3-JPA-apapter-preview or weld?  Most of us want something that helps us do our jobs. 


                        Of course I care, the name is just the tip of the iceberg, why do you think Java has been named the same way for the last 10 years? Because of lack of imagination in Sun? No, because it and indicator that is the same product, that is improved but backwards compatible, that your investment on it is a safe investment, and that is very important, not only for me as a developer, but only the big chiefs that want their systems built over a platform that is reliable.



                        The bottom line is we need JPA.  Most of us Tomcat users rely on Spring to do these things for us.  If we cannot accomplish these tasks in Weld, we can't drop Spring.  If your ultimate goal is JBoss6 and JEE6 adoption, I think they'll be more successful by giving us viable alternatives to Spring so we can transition. 


                        Again, I agree, but one of the reasons I trust spring is that the things I learned when I first played with it (Spring 0.9) still applied to when I played again with it many years later (on Spring 2.0). Do not dismiss backwards compatibility and brand continuation as irrelevant: They are very important. If you can trust that a platform will be stable, and that what you learned about it will still be valid in the future then you better start looking for a another platform, because an unreliable platform will change in a way that will make it incompatible with itself and the costs of keeping it or switching to another one will be the same.



                        I think the Weld team has a huge opportunity to make this technology successful by providing a solution that can solve business problems, such as JNDI and JPA integration easily.


                        And they are taking the opportunity, it is called Seam 3. What I would ask from them is that it truly becomes the foundation of an ecosystem, as in Eclipse case.



                        I'm very thankful Gavin is helping by pasting that code in this forum.  I'm just pushing for them to go a step further and make it readily available and easy to use  because I think small details like can make a huge difference in your adoption. 


                        I agree with you, but I think we should push in the right direction, if we don't we risk damaging the same thing we are trying to improve.


                        • 24. Re: How do I get a JPA EntityManager reference in Weld?

                          Typo:




                          If you can not trust that a platform will be stable, and that what you learned about it will still be valid in the future then you better start looking for a another platform...


                          Please add editing to this forums!!!!!!!!!


                          • 25. Re: How do I get a JPA EntityManager reference in Weld?
                            asookazian

                            From a corporate development perspective, what will be the advantage (if any) of using Weld vs. Seam3 if you are not planning on writing portable extensions?  In other words, shouldn't we just wait for Seam3 unless we want to learn concepts and experiment?


                            And, say we adopt Seam3, can you write portable extensions in Seam3 apps b/c Weld is the core?  Or will the SPI be available/unavailable in Seam3?


                            I think the target audience point that Steve brought up is an important one.  It's confusing who should use Weld due to the SPI/PE aspect of it.  Is it framework devs, corporate devs, or both?

                            • 26. Re: How do I get a JPA EntityManager reference in Weld?

                              Arbi Sookazian wrote on Nov 19, 2009 18:22:


                              From a corporate development perspective, what will be the advantage (if any) of using Weld vs. Seam3 if you are not planning on writing portable extensions?


                              That question makes no sense to me, it is like asking: what will be the advantage (if any) of using Spring-Core vs. Spring-MVC? Does the question make sense to you?



                              In other words, shouldn't we just wait for Seam3 unless we want to learn concepts and experiment?


                              If Weld is not enough for your current needs... probably yes... unless you want to contribute to make it more stable or create extensions, or improve documentation... Or push and try to convince JBoss to convert Seam 3 in to a plug-in ecosystem that is synchronized each year in official JBoss sanctioned releases for Weld...



                              And, say we adopt Seam3, can you write portable extensions in Seam3 apps b/c Weld is the core?


                              AFAIK Seam3 will be a portable extensions on top of Weld, so... why not?



                              Or will the SPI be available/unavailable in Seam3?


                              Unavailable? I do not see how can that be possible... Weld is opensource, Seam 3 will be opensource, Seam 3 will be on top of Weld... how can it be unavailable?



                              I think the target audience point that Steve brought up is an important one.  It's confusing who should use Weld due to the SPI/PE aspect of it.  Is it framework devs, corporate devs, or both?


                              I guess it depends on your needs. There no one size fits all solution for this.

                              • 27. Re: How do I get a JPA EntityManager reference in Weld?

                                I think one thing that is very important to keep in mind is that if Seam 3 is release monolitically that IMO will hurt adoption.


                                Seam 2 does too many things (here are most of them in no particular order):



                                1. Integration with JSF

                                2. Integration with JPA

                                3. Integration with JBPM

                                4. Integration with EJBs

                                5. Remoting with JavaScript

                                6. Integration with Wicket

                                7. Integratoin with JBoss Rules

                                8. Security Management (JAAS/Authorization/Authentication/Catpchas/OpenId,etc)

                                9. Internationalization

                                10. WikiText

                                11. PDF generation

                                12. Excel generation

                                13. RSS support

                                14. Asynchronicity and messaging

                                15. Caching

                                16. WebServices Support

                                17. GWT support

                                18. Integration with Spring

                                19. Integration with Guice

                                20. Email sending support



                                Now I can see how, if we are told we are going to have to wait for all of this to be released as part of Seam 3 that gives us an uneasy feeling... I mean: why do I need to wait for RSS support or Security Management if all I want is JPA support? Why do I need to wait for JSF support if all I want is GWT Support?


                                That is why I think that why this extensions should belong to the Seam 3 project, they should not be released as a single monolithic thing. They should be released incrementally, perhaps following an order that the team knows is the one that fits their target audience the most.


                                If some people feel that the priority is wrong, they should be given the chance to explain their reasons, if after explaining them Jboss still feels that it shouldnt change its priorities, then, since this is opensource, those that want to change the path have the power to do so, they have to step up and decide that they are going to help port XXXX from Seam 2 to Seam 3.


                                Of course, this is going to be a tough test on Jboss, because when one creates an ecosystem, it gets a life of its own, and it can grown in unexpected ways... if they are not careful they could asphyxiate it by exercising too much control, but if they offer no guidance, they risk becoming a forgotten piece of the ecosystem (like Sun and the Java ecosystem)


                                They need to find the Middle Way

                                • 28. Re: How do I get a JPA EntityManager reference in Weld?
                                  nickarls

                                  With Weld shop, I didn't mean anything commercial - I was referring to a small workshop where welders work ;-)

                                  • 29. Re: How do I get a JPA EntityManager reference in Weld?
                                    gavin.king

                                    I'm more or less in agreement with Francisco on this one. All these extra features should be independent modules, independently installable. And we should release them as the become ready. (However, we should probably not call them GA until we are ready to release the entire Seam3 platform as GA.)