Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 6.1.0
    • Component/s: None
    • Labels:
      None

      Description

      Introduce integration with CDI containers which should include

      • injection of components with CDI dependencies
      • conversation scope propagation across pages

        Activity

        Igor Vaynberg made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        Igor Vaynberg added a comment -

        added new wicket-cdi module

        Show
        Igor Vaynberg added a comment - added new wicket-cdi module
        Martijn Dashorst made changes -
        Fix Version/s 6.1.0 [ 12322957 ]
        Fix Version/s 6.0.0 [ 12321282 ]
        Martin Grigorov made changes -
        Fix Version/s 6.0.0 [ 12321282 ]
        Fix Version/s 6.0.0-beta2 [ 12320343 ]
        Martin Grigorov made changes -
        Fix Version/s 6.0.0-RC1 [ 12320343 ]
        Fix Version/s 6.0.0-beta1 [ 12315431 ]
        Hide
        John Sarman added a comment -

        Thanks, That definitely solves the Serialization issue.
        So to use @Singletons, @Stateless, @Statful Jee6 objects with wicket-cdi to avoid Serialization issues, create a @SessionScoped or @ConversationScoped CDI Bean that wraps the EJB. That works for me.

        Show
        John Sarman added a comment - Thanks, That definitely solves the Serialization issue. So to use @Singletons, @Stateless, @Statful Jee6 objects with wicket-cdi to avoid Serialization issues, create a @SessionScoped or @ConversationScoped CDI Bean that wraps the EJB. That works for me.
        Hide
        Igor Vaynberg added a comment -

        you can inject your ejbs into a cdi bean and then inject that cdi bean into wicket.

        Show
        Igor Vaynberg added a comment - you can inject your ejbs into a cdi bean and then inject that cdi bean into wicket.
        Hide
        John Sarman added a comment -

        They work great except for the Serialization. I tested it after reading http://www.adam-bien.com/roller/abien/entry/is_java_ee_6_war So now i have a UserManager that needs the SessionContext to call sessionContext.isCallerInRole(role). I set up an Database Realm in Glassfish and a simple html login page using the j_security_check. After login my wicket Application starts and using my EJB which is injected via wicket-cdi to my session object, I am able to implement an IRoleCheckingStrategy that simply does "return MySession.get().hasAnyRole(roles);" In MySession I inject the Usermanager and call hasAnyRole, which wraps the sessionContext. So I let the glassfish handle realm authentication and still benefit from wicket Authorization. Whether you know it or not your CDI implementation supports EJBs out of the Box

        Show
        John Sarman added a comment - They work great except for the Serialization. I tested it after reading http://www.adam-bien.com/roller/abien/entry/is_java_ee_6_war So now i have a UserManager that needs the SessionContext to call sessionContext.isCallerInRole(role). I set up an Database Realm in Glassfish and a simple html login page using the j_security_check. After login my wicket Application starts and using my EJB which is injected via wicket-cdi to my session object, I am able to implement an IRoleCheckingStrategy that simply does "return MySession.get().hasAnyRole(roles);" In MySession I inject the Usermanager and call hasAnyRole, which wraps the sessionContext. So I let the glassfish handle realm authentication and still benefit from wicket Authorization. Whether you know it or not your CDI implementation supports EJBs out of the Box
        Hide
        Igor Vaynberg added a comment -

        i dont think this project covers EJBs

        Show
        Igor Vaynberg added a comment - i dont think this project covers EJBs
        Hide
        John Sarman added a comment -

        When creating a @Stateless beanand launching an app using glassfish 3.1.1 a serialization exception will always be thrown unless you make your @Stateless is also a @Remote. @Local beans are not required to be Serializable per CDI spec. I recommend figuring out how to either force the container to create as Serializable or create a Serializable Wrapper. The @Stateless is needed for things such as getting an instance of the SessionContext etc..

        Show
        John Sarman added a comment - When creating a @Stateless beanand launching an app using glassfish 3.1.1 a serialization exception will always be thrown unless you make your @Stateless is also a @Remote. @Local beans are not required to be Serializable per CDI spec. I recommend figuring out how to either force the container to create as Serializable or create a Serializable Wrapper. The @Stateless is needed for things such as getting an instance of the SessionContext etc..
        Hide
        Igor Vaynberg added a comment -

        wicket-cdi will become part of core with the next major version. wicket 1.5.x is compiled against jdk5 while cdi api jar is compiled against jdk6 so for now it cannot be made part of core.

        also since wicket-cdi depends on seam-conversation module and seam-conversation is not release into maven central i cannot release wicket-cdi into maven central as well.

        so for now we are stuck building from sources ourselves.

        Show
        Igor Vaynberg added a comment - wicket-cdi will become part of core with the next major version. wicket 1.5.x is compiled against jdk5 while cdi api jar is compiled against jdk6 so for now it cannot be made part of core. also since wicket-cdi depends on seam-conversation module and seam-conversation is not release into maven central i cannot release wicket-cdi into maven central as well. so for now we are stuck building from sources ourselves.
        Hide
        Jeff Campbell added a comment -

        This works GREAT for non-component beans:

        CdiContainer.get().getNonContextualManager().postConstruct(this)

        I now have fully working Wicket CDI application that uses Wicket-1.5.1, wicket-cdi (that I built myself from git sources), AuthenticatedWebApplication, JPA that works WELL on both JBoss AS 7.0.2 and/or Glassfish 3.1.1

        Is the plan to release wicket-cdi separately from wicket-core?

        Show
        Jeff Campbell added a comment - This works GREAT for non-component beans: CdiContainer.get().getNonContextualManager().postConstruct(this) I now have fully working Wicket CDI application that uses Wicket-1.5.1, wicket-cdi (that I built myself from git sources), AuthenticatedWebApplication, JPA that works WELL on both JBoss AS 7.0.2 and/or Glassfish 3.1.1 Is the plan to release wicket-cdi separately from wicket-core?
        Hide
        Igor Vaynberg added a comment -

        to inject non-component beans you have to use this line:

        CdiContainer.get().getNonContextualManager().postConstruct(this)

        Show
        Igor Vaynberg added a comment - to inject non-component beans you have to use this line: CdiContainer.get().getNonContextualManager().postConstruct(this)
        Hide
        Jeff Campbell added a comment -

        I've been playing with wicket-cdi, here are some notes:

        • Example deploys/runs WELL to Jetty
        • When deploying the example war file to Tomcat 7, deployment fails on the following Line of org.jboss.weld.environment.servlet.Listener (197)

        jspApplicationContext.addELResolver(manager.getELResolver());

        (BeanManager IS resolved (from getServletContext().getAttribute(...)), but "new CdiConfiguration(manager).configure(this);" fails.

        • The Example deploys/runs WELL to run in GlassFish 3.1 and JBoss AS7 by doing the following
        • web.xml: REMOVE:

        <listener>
        <listener-class>org.jboss.weld.environment.servlet.Listener</listener-class>
        </listener>

        • CdiApplication.java: REPLACE:

        BeanManager manager = (BeanManager)getServletContext().getAttribute(Listener.BEAN_MANAGER_ATTRIBUTE_NAME);

        WITH:

        BeanManager manager = null;
        try

        { manager = (BeanManager) new InitialContext().lookup("java:comp/BeanManager"); }

        catch (NamingException e)

        { e.printStackTrace(); }
        • Current Issue: No Support for @Inject in an AuthenticatedWebSession when your application extends AuthenticatedWebApplication and overriding getWebSessionClass().

        I have not been able to figure this one out... yet. When I use Spring, it would work when I would put the following line in the constructor:

        Injector.get().inject(this);

        This would allow me to use @SpringBean in my AuthenticatedWebSession object. This does not work with wicket-cdi (I put @Inject in my AuthenticatedWebSession and also have Injector.get().inject(this) in the constructor).

        Show
        Jeff Campbell added a comment - I've been playing with wicket-cdi, here are some notes: Example deploys/runs WELL to Jetty When deploying the example war file to Tomcat 7, deployment fails on the following Line of org.jboss.weld.environment.servlet.Listener (197) jspApplicationContext.addELResolver(manager.getELResolver()); (BeanManager IS resolved (from getServletContext().getAttribute(...)), but "new CdiConfiguration(manager).configure(this);" fails. The Example deploys/runs WELL to run in GlassFish 3.1 and JBoss AS7 by doing the following web.xml: REMOVE: <listener> <listener-class>org.jboss.weld.environment.servlet.Listener</listener-class> </listener> CdiApplication.java: REPLACE: BeanManager manager = (BeanManager)getServletContext().getAttribute(Listener.BEAN_MANAGER_ATTRIBUTE_NAME); WITH: BeanManager manager = null; try { manager = (BeanManager) new InitialContext().lookup("java:comp/BeanManager"); } catch (NamingException e) { e.printStackTrace(); } Current Issue: No Support for @Inject in an AuthenticatedWebSession when your application extends AuthenticatedWebApplication and overriding getWebSessionClass(). I have not been able to figure this one out... yet. When I use Spring, it would work when I would put the following line in the constructor: Injector.get().inject(this); This would allow me to use @SpringBean in my AuthenticatedWebSession object. This does not work with wicket-cdi (I put @Inject in my AuthenticatedWebSession and also have Injector.get().inject(this) in the constructor).
        Igor Vaynberg made changes -
        Fix Version/s 1.6.0 [ 12315431 ]
        Hide
        Igor Vaynberg added a comment -

        currently integration lives here:

        https://github.com/42Lines/wicket-cdi

        Show
        Igor Vaynberg added a comment - currently integration lives here: https://github.com/42Lines/wicket-cdi
        Igor Vaynberg made changes -
        Assignee Igor Vaynberg [ ivaynberg ]
        Igor Vaynberg made changes -
        Field Original Value New Value
        Summary CDI integration Add CDI integration
        Igor Vaynberg created issue -

          People

          • Assignee:
            Igor Vaynberg
            Reporter:
            Igor Vaynberg
          • Votes:
            3 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development