1 2 Previous Next 28 Replies Latest reply on Jan 25, 2010 10:10 AM by longbeach Go to original post
      • 15. Re: Weld and EJB 3.0 and JSF 2.0 and JBoss 6 M1
        nickarls

        In one place there is a comment


        // TODO Don't create enterprise bean if it has no local interfaces!

        so it might be something that wasn't quite finished.

        • 16. Re: Weld and EJB 3.0 and JSF 2.0 and JBoss 6 M1
          longbeach

          Any chance you might fix it soon and include it in the next build / release of Weld ? So I can integrate it in JBoss 6.0.0 M1


          In the mean time, I might try to add local interfaces to my session beans, they are not too many. I will see if that is the cause of my problem.

          • 17. Re: Weld and EJB 3.0 and JSF 2.0 and JBoss 6 M1
            meetoblivion

            Celinio Fernandes wrote on Dec 30, 2009 21:41:


            They're remote interfaces because i plan to use them remotely indeed.

            Right now, I just want to experiment CDI in my JSF 2.0 client. With and without session beans calls.

            I could try to systematically add local interfaces to all my EBJs if that could fix it. What do you think ?

            I guess EJB 3.0 with CDI is not the best option. Too bad JBoss 6 is not supporting EJB 3.1 yet.


            Remote and Local or just Remote? It seems a little odd to have a web app where the EJBs are all remote, there's definitely a performance hit as a result.  From my perspective, even when I've written code that was expected to be remoteable (e.g. web services) the business interfaces always include a Local version as well as Remote/WS.  The reason is if I need to do something with another bean locally, it makes it easier to implement.  From CDI's point of view, whether it is a Session Bean or POJO/ManagedBean is irrelevant, it treats them fairly equally.


            Of course, you have the scenario of deploying a standalone EJB jar to the app server, without putting it in an EAR/WAR.  In this case you're supposed to use remote, however, you can't CDI with this bean - the module itself is outside the scope of other modules.  It can CDI within itself, so if it uses stuff that stuff might be CDI enabled, but that would be local to the module.  If that module sits in an EAR then it can be shared.


            Though I think the behavior of deploying an EJB jar to the container directly might vary between vendors, maybe a little less w/ Java EE 6's design changes.



            Nicklas Karlsson wrote on Dec 30, 2009 22:05:


            In one place there is a comment

            // TODO Don't create enterprise bean if it has no local interfaces!

            so it might be something that wasn't quite finished.


            Well that would definitely be a bit of odd behavior in my opinion.  So if there's no local interface on the session bean, we treat it like a POJO?  Does the spec actually describe this?

            • 18. Re: Weld and EJB 3.0 and JSF 2.0 and JBoss 6 M1
              longbeach

              Just a quick update :
              I added a local interface (with no methods) to each session bean of my EJB project and i still get the same error.
              I do not think I missed a session bean, i will check tomorrow.



              I applied these annotations :


              @Local on the interface then @Local({MyLocalInterface.class} on the session bean.


              So not sure where the problem is.

              • 19. Re: Weld and EJB 3.0 and JSF 2.0 and JBoss 6 M1
                nickarls

                Shouldn't it just be @Local on the interface and then the session bean implements it?

                • 20. Re: Weld and EJB 3.0 and JSF 2.0 and JBoss 6 M1
                  longbeach

                  If my local interface is defined like this :




                  @Local
                  public interface MyLocalInterface  {
                  
                  }






                  then i can define my session bean like this :




                  @Stateless
                  @Local({MyLocalInterface.class})
                  public class MyBean  {
                  ...
                  }
                  





                  It is not required to explicitly implement the interface like this :



                  @Stateless
                  @Local({MyLocalInterface.class})
                  public class MyBean  implements MyLocalInterface {
                  ...
                  }
                  



                  • 21. Re: Weld and EJB 3.0 and JSF 2.0 and JBoss 6 M1
                    asookazian

                    A legal alternative (@Local is default via convention over configuration):


                    public interface MyLocalInterface  {
                    
                    }



                    @Stateless
                    public class MyBean implements MyLocalInterface {
                    ...
                    }
                    



                    You'd think that if you write this:


                    @Stateless
                    @Local({MyLocalInterface.class})
                    public class MyBean  {
                    ...
                    }
                    



                    Then the annotation, whether @Local or @Remote, would not be required in the interface definition...

                    • 22. Re: Weld and EJB 3.0 and JSF 2.0 and JBoss 6 M1
                      nickarls

                      OK. Can you start with the Numberguess example, see that it deploys and modify that to see what the differences are?

                      • 23. Re: Weld and EJB 3.0 and JSF 2.0 and JBoss 6 M1
                        longbeach

                        i do not use Maven at the moment.


                        To test the Numberguess example, i created a new dynamic web project in Eclipse called testWeld where i added the following classes and files :


                        Game.java
                        Generator.java
                        MaxNumber.java
                        Random.java
                        WEB-INF/web.xml
                        WEB-INF/beans.xml
                        WEB-INF/faces-config
                        webapp/home.xhtml
                        webapp/index.xhtml
                        webapp/template.xhtml



                        I removed all my other projects from the EAR build.
                        It deploys perfectly :


                        09:44:08,693 INFO  [TomcatDeployment] deploy, ctxPath=/jmx-console
                        09:44:08,980 INFO  [Weld/Version] WELD-000900 1.0 (0)
                        09:44:10,288 WARN  [InterceptionTypeRegistry] Class 'javax.interceptor.AroundTimeout' not found, interception based on it is not enabled
                        09:44:10,571 INFO  [TomcatDeployment] deploy, ctxPath=/testWeld
                        09:44:10,627 INFO  [config] Initialisation de Mojarra 2.0.1 (FCS b02) pour le contexte '/testWeld'



                        And i could guess the correct number in 6 attempts :p


                        If i include all my other projects, it fails miserably (same error).




                        • 24. Re: Weld and EJB 3.0 and JSF 2.0 and JBoss 6 M1
                          longbeach

                          Any update or further suggestion regarding this matter ?
                          Still can't use Weld on my project (EJB 3.0 and JBoss 6.0 M1 and JSF 2).


                          Thanks.

                          • 25. Re: Weld and EJB 3.0 and JSF 2.0 and JBoss 6 M1
                            pmuir

                            Fixed in trunk (you can drop this into JBoss 6.0 M1's server/default/deployer/weld.deployer/lib-int to update) - the issue was the presence of an MDB in the ear - oops!

                            • 26. Re: Weld and EJB 3.0 and JSF 2.0 and JBoss 6 M1
                              longbeach

                              thanks Pete !
                              I replaced weld-core.jar with that new jar. And it works now :) Very cool, now i can play with Weld !


                              One remark though :
                              I have an interceptor class (EJB 3) in my projet and i initially got the following error :


                              21:54:48,858 WARN  [HDScanner] Failed to process changes
                              org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):

                              DEPLOYMENTS MISSING DEPENDENCIES:
                                Deployment "vfszip:/K:/ENI/DeveloppementEJB3/jboss-6.0.0.M1/server/default/deploy/VenteEnLigne.ear/_WBInjector" is missing the following dependencies:
                                  Dependency "vfszip:/K:/ENI/DeveloppementEJB3/jboss-6.0.0.M1/server/default/deploy/VenteEnLigne.ear/_WeldBootstrapBean" (should be in state "Installed", but is actually in state "**ERROR**")

                              DEPLOYMENTS IN ERROR:
                                Deployment "vfszip:/K:/ENI/DeveloppementEJB3/jboss-6.0.0.M1/server/default/deploy/VenteEnLigne.ear/_WeldBootstrapBean" is in error due to the following reason(s): org.jboss.weld.exceptions.DeploymentException: WELD-001402 The bean org.jboss.weld.bootstrap.Validator@1a10b00 declared a passivating scope but has a non-serializable interceptor com.eni.dvtjeb.metier.interceptors.CommanderInterceptor, **ERROR**

                                   at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:1002)
                                   at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:948)
                                   at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:870)
                                   at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.checkComplete(MainDeployerAdapter.java:128)
                                   at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:378)
                                   at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:256)
                                   at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
                                   at java.util.concurrent.FutureTask$Sync.innerRunAndReset(Unknown Source)
                                   at java.util.concurrent.FutureTask.runAndReset(Unknown Source)
                                   at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(Unknown Source)
                                   at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(Unknown Source)
                                   at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
                                   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
                                   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
                                   at java.lang.Thread.run(Unknown Source)



                              I fixed it by implementing the Serializable class in my interceptor class.
                              I am not sure this is normal behaviour since the EJB 3 specification does not require interceptors to implement the Serializable interface.

                              • 27. Re: Weld and EJB 3.0 and JSF 2.0 and JBoss 6 M1
                                nickarls

                                6.6.1 says



                                A managed bean is passivation capable if and only if the bean class is serializable and all interceptors and decorators of
                                the bean are serializable.

                                There is probably a reason for it, I have found very few things in the spec that have been there by accident ;-)

                                • 28. Re: Weld and EJB 3.0 and JSF 2.0 and JBoss 6 M1
                                  longbeach

                                  Nicklas Karlsson wrote on Jan 24, 2010 12:10:


                                  6.6.1 says

                                  A managed bean is passivation capable if and only if the bean class is serializable and all interceptors and decorators of
                                  the bean are serializable.


                                  There is probably a reason for it, I have found very few things in the spec that have been there by accident ;-)


                                  You are referring to the section 6.6.1 of the CDI spec that I have not really checked yet. I was referring to the EJB 3.0 spec.
                                  But I guess that's something to know from now on.
                                  Thanks.

                                  1 2 Previous Next