Tags
People
Badges
Help-
CORE FRAMEWORK
FEATURED COMPONENTS
-
RESOURCES
-
LEARN ZK
RESOURCES
Hi guys,
is there any news on the forefront of @EJB DI in zk MVVM/MVC pattern.Until know the @EJB is entirely ignored by the ZK framework when initializing the components to be injected. The problem could be solve by looking up the been from JNDI but that's equal with going back at 2003(EJB2) spec. regards Nick
I think this behavior of answering only what doesn't scratch productivity penalties in zk is not good my the company supporting it. In any new javaee7 web framework the DI works out of the box once the application is deployed in a javaee7 enabled container. In zk you can only do it via Spring variable resolver, BUT with the new specification of jee7 that's not mandatory any more. DI is offered by the platform. ZkCDI tries to address but is a dead project many time now. Any view on that from someone from the company supporting zk? For me is crucial since I have to go live in 3-4 months and much functionality in the UI is running with zk..I will have to port in play else.It will take time but I will do it if necessary. Any thoughts?
Hi, Nick You can use JNDI lookup (not DI)
// DAO
import domain.Employee;
@Stateless @LocalBean public class EmployeeService {
public Employee add(Employee empl) throws Exception {
.... }
// DAO from ejb module
import <ejb package="" name="">.domain.Employee;
// Service from ejb module
import <ejb package="" name="">.EmployeeService;
......
public class EmployeesView extends GenericAutowireComposer {
// declare variable to access service
private EmployeeService employeeService;
// jndi name
private final String ejbEmployeesServiceJndi = "java:global/<jee module name :
eeapp>/<ejb module="" name="" :="" eeapp-ejb="" >="" employeeservice";<="" p="">
// Get ejb instance
@Override public void doAfterCompose(Component comp) throws Exception {
super.doAfterCompose(comp);
employeeService = (EmployeeService) InitialContext.doLookup(ejbEmployeesServiceJndi); }
// Now you can use any public methods from ejb , for example:
employee = employeeService.add(employee);
Hope this helps Best regards, Vladimir
Hi Vladimir,
as mentioned in my previous post, that's is an already known procedure for me and of course I can even use a WeakReferenceMap to implement something like an LRU cache in order to avoid consecutive JNDI lookups. CDI is part of the javaee specification since version 6. Thus the @EJB annotation should be supported. I think I have identified the part of the code that instantiates the wired class and I can clearly see that you don't check for annotations in the apart from what spring can bring and specific annotations for zk. The question is rather simple. Do you plan to make zk javaee6> compatible or not? because you should be aware that using the @Inject and @EJB are more convenient that doing JNDI lookup.
regards Nick
The earlier ZK CDI extension was not working very well with glassfish/jboss so i developed my own empego-zkcdi extension: http://www.javaforge.com/wiki/127153.
It supports ZK specific scopes and deals also with CDI events. This works but i havent updated this for a long time... in hope the CDI support will be integrated native in ZK.
What i have done meanwhile is to use the ZK integrated CDI support to obtain a instance of a BeanManager and write a little utility method to perform injection: https://github.com/oberinspector/zkdemo/blob/master/zkdemo-basics/src/main/java/net/empego/zkbasics/util/ZKCDIUtil.java
You can hook in this method in any lifecycle method in your ZK composer classes or own components e.g. AfterCompose. I have CDI composer baseclasses and CDI-Div component baseclasses. In my ZK-demo project you might find some usages of CDI with this utility: https://github.com/oberinspector/zkdemo You might have to change the jndi name configuration in zk.xml since ZK has the wrong defaults: https://github.com/oberinspector/zkdemo/blob/master/zkdemo-basics/src/main/webapp/WEB-INF/zk.xml
CDI is one of the most impressive improvements of Java EE and i think a native ZK CDI integration is a must to be competitive in future. And this should work with the most common EE containers like Glassfish and JBoss and not only with the Weld SE edition on Tomcat. Wicket, JSF and even Struts2 has CDI support. The ZK CDI support might be improved meanwhile but i didn't tried it for a long time... Hopefully something will happen in ZK7...
regards, thomas
Hi Thomas,
I end up doing the same. But I think in order to do the CDI in zk is rather simple. Before calling the newInstance() you need to parse the class and check for annotations.If you find @EJB or @Inject annotations you inject with CDI. programmatically wiring up the deps in the classes under creation. I really hope so also that this will be a major issue in the coming release of zk. I don't know if it worth reporting it and raising the issue by voting for it in JIRA to be implemented.
regards Nick
Hi Nick, in the last releases ZKCDI was a feature for PE and EE edition. I didn't manage to get it running with Glassfish and JBoss because it depends on a specific weld implementation.
Adding CDI to ZK for injection is not a big deal as you mentioned above. If they add it to CE i will give it a try again... when not.. my solution works for me.
CDI becomes more and more a very important feature and we should vote for this extension in Jira.
But CDI is not only about injection. What i really love in ZK and what i hardly miss in all other frameworks i have to use to earn my money are the well defined scopes. In my empego-zkcdi implementation i supported all ZK scopes and that is what i would expect from a full CDI integration: @DesctopScoped, @ExecutionScoped, @ComponentScoped @IdSpaceScoped beans.
I don't know the current state of ZKCDI in ZK 7.0 but when there is nothing new on this we should write some requirements to a Jira. The current ZKCDI implemetation was'nt updated for a long time: https://code.google.com/p/zkcdi/
Maybe we should do it ourself again... ;)
I havent fount a feature request for this so i created one: http://tracker.zkoss.org/browse/ZK-2034
Add your comments and vote
I also moved my old ZKCDI exctension to github: https://github.com/oberinspector/empego-zkcdi
Hi Thomas, I have reviewed a bit the code you have in the ZKCDIUtil class and I have some comments on it. The BeanManager according to the SPEC of CDI can also be retrieved not only by JNDI, and you should also support the CDI.getBeanManager stuff to be fully compliant witht he CDI 1.1 Spec. On the other hand the solution isn't generic. It's a very nice try by my purpose is to write a portable extension on the zk to support CDI by nature,aka if you are using the new MVVM way of doing data binding then the @init('foo.bar.MyClass') should also be registred as container managed beans. To do so you need to create a portable extension. Weld(Reference implementation of CDI 1.1) supports the creation of portable extensions by utilizing the Extension interface. Thus you will have native support of CDI in the ZK from the application server. If you are interested the Weld tutorial chapter 16 describes how this can be accomplished. I plan putting the same comment in the JIRA you have opened but we have to create awareness. With the new Glassifish and JBoss 7.1.1 and Wildfly around the corner, zk could be a framework of choice if such support existed. In JavaEE a nice web framework with clear programmatic paradigm is missing...zk could be a good candidate to feel in the need.
regards Nick
yes... you are right. My implementation is CDI 1.0 and Weld 1.0 and it's about 2 years old. Maybe there are some code parts which can be recycled.
Realistic i wont be able to spend much time on this due to a busy project i'm working on until end of december.
Asked: 2013-11-16 16:33:28 +0800
Seen: 82 times
Last updated: Dec 02 '13
