• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

JSF, EJB, JPA design quandaries !!!

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I have a design question around jsf, ejb, and jpa.

I'm designing a system that uses JSF as a front end, the backing beans lookup session facades (stateless session EJBs). These then use other helper EJB (DAOs) to make calls to a JPA back end.

The system was originally built on Jboss 4.2, so I had to use a Service Locators so as my JSF backing beans could look up the Session Facade EJBs (as injection didn't work on JBoss 4.2 in the web tier at all).

My Session Facade EJBs called other helper EJBs (basically DAOs) as there is a lot of business logic (hence the session facade pattern). I had to use EJBs for these DAOs (helpers) and as far as can figure, the PersistenceContext can, again, be only injected successfully within EJBs.

Now, I recently upgraded to JBoss 5.0 as I thought it would solve my injection nightmares, but it doesn't... as I've learned (the hard way) that injection in the web tier is limited to Servlets and not JSF backing beans... (so I still have to use my Service Locator - which I don't like)... Has anyone found a solution for this?

Also, because I can't inject PersistenceContext in non EJBs (which I thought JBoss 5 would address) I have to make all of my DAOs (helper EJBs) EJBs... which I also don't like... as in theory, they are exposed to the web tier via normal InitialContext lookups - which bi-pass the Session Facade EJBs - which I don't want.

I guess I could pass Inject the PeristenceContext in my SessionFacade EJB and pass it to the DAO... but it seems nasty.

I'm guessing I'm missing something as I'm sure I'm not the only person to hit this problem, and I'm also guessing that a solution would be to change me design so as:

* DAOs are not exposed to the web-tier
* I can get access to the PersistenceContext for JPA in my DAOs
* ... and ideally someone can tell me how to solve my injection problems (Out of interest does glassfish allow you to use injection from non-managed beans - i.e. POJOs that are not EJBs or Servlets?)

Does anyone have any advice?

Many thanks

Matt
 
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Spring is an excellent solution for all injection problems that you have. And since all the injection issues are resolved, you won't have any derived problems as well.

Currently, I used Spring JNDI lookup to load relevant EJB beans, POJO beans, etc; then use org.springframework.web.jsf.DelegatingVariableResolver to resolve injecting variables for Faces backing beans.
 
Duc Vo
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You also can try JBoss Seam Framework as well.
 
matt mcgrillis
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Thanks for the reply.

Unfortunately it would be difficult to fit Seam to the current architecture, so I have to rule that out.

Though on the plus side, I have managed to get the injection working inside the JSF managed beans (thank you Jboss5).

I'm still stuck with the fact I can't use injection to get hold of the PersistenceContext inside my DAOs (if I keep them POJOs) and if I turn them into EJBs they are referenceable though injection the web tier (which I don't want - I only want the web tier to be able to inject referneces to the session facade EJBs)

I was thinking I could perhaps keep the DAOs as EJBs (so as I get the advantage of injection) but somehow lock down the access to them only to other EJBs within the same JAR? Would this be possible?

Thanks again

Matt
 
matt mcgrillis
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
BTW, Had a look at the Spring option, and whilst you are totally correct in saying that would solve the problem of being able to use annotation to inject the PersistenceContext within POJOs... it will add a lot of extra time to implement, just for the sake of being able to keep the DAOs as POJOs. There's got to be a simpler solution... as mentioned before... perhaps by locking down access of the EJB DAOs to within the JAR or something similar???)

(p.s. for anyone else reading that that's interested I found a good article about Spring solution at: http://www.ibm.com/developerworks/websphere/library/techarticles/0810_asplund/0810_asplund.html )
 
Duc Vo
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by matt mcgrillis:
somehow lock down the access to them only to other EJBs within the same JAR? Would this be possible?


I doubt that you can do it. EJB Container won't know which jar a bean comes from, also actually the bean that you access is a proxy object around your real object hence won't be from your jar file.

But if I remember correctly, you can configure to deploy a bean as local EJB only. In addition, you also can provide some security settings so that only authorised user/app can access to the bean.

Hope it help.
 
Duc Vo
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by matt mcgrillis:
BTW, Had a look at the Spring option, and whilst you are totally correct in saying that would solve the problem of being able to use annotation to inject the PersistenceContext within POJOs... it will add a lot of extra time to implement, just for the sake of being able to keep the DAOs as POJOs. There's got to be a simpler solution... as mentioned before... perhaps by locking down access of the EJB DAOs to within the JAR or something similar???)


How did you come to that conclusion? Spring's spirit is to make thing simpler. When you code the POJO, you only need to know that you need to use PersistanceContext. Spring configuration will instantiate your POJO inject PersistanceContext into it, inject the POJO into whatever object that you wnat. There should be no extra coding required.
Actually to make it easy, you should also install Spring IDE (it has plugins for most popular IDEs). It'll make your configuration tasks much quicker.
 
author
Posts: 580
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Matt,

Sorry for not replying to this earlier...I am on vacation...

I know what you are talking about in terms of access control for managed components. Sadly, you'll have the problems with any DI system since ultimately the container will need to instantiate, register and make the components available somehow. What I have done in the past is handle this via EJB security settings - take a look at @RolesAllowed and @RunAs. In this scheme, only a bean with a certain access role (say, "service") can access a DAO and only service tier EJBs run as "service".

As to injection of Java EE managed objects into non-managed classes, the options today are Seam, Spring and Guice. Seam and Guice are essentially being standardized as WebBeans as of Java EE 6. Personally, I find that DAOs as EJBs are a very good fit because of pooling, transactions and thread safety.

Hope it helps,
Reza
 
matt mcgrillis
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Reza -

As you said, I made all my service EJBs @RunAs("service") and all my DAOs @RolesRequires({"service"}). Which solved my web-tier DAO access problem.

Duc - I know what you're saying with Spring, the thing that puts me off was the XML configuration that goes with it, which while is necessary in some cases, I could save time and complexity if I could live with / find a solution to the 'web-tier DAO access problem' (which was sorted by Reza's post). Out of interest though I did find an interesting article which allows you combine to two, which I may look into further, as I still have some non DAO POJOs that could do with access to the PersistenceContext at http://java.sys-con.com/node/180386?page=1

Many thanks to both of you for your help.

Regards
Matt
 
I knew I would regret that burrito. But this tiny ad has never caused regrets:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic