On 9/15/06, stephan opitz <[EMAIL PROTECTED]> wrote:
craig... the possibility with indirect works only if i do a jndi lookup... @Bean(name = "dataFactory", scope = Scope.SESSION) public class DataFactory { @EJB private CategoriesLangFacade categoriesLangFacade; public CategoriesLangFacade getCategoriesLangFacade() { return categoriesLangFacade; } } solves categoriesLangFacade as null; without @EJB and jndi-lookup in the getCategoriesLangFacade it works under jbos s4.04ga - but why resource injection does not work ?
Container resource injection only works on what the *container* thinks is a JSF managed bean that *it* created. The Tiger Extensions stuff (@Bean) intercepts the normal process and creates the bean itself, and can't do any injections. If you made this a normal managed bean (configured in faces-config.xml), you'll find that the resource injection does indeed work. It would be an interesting challenge to examine whether it's even *possible* to fake the container's normal resource injection for stuff like this. Craig ########################################
public interface CategoriesLangFacade { public CategoriesLang findById(long categoriesLangId, long languageId); } ####################################### @Local({CategoriesLangFacade.class}) @Stateless public class CategoriesLangImp implements CategoriesLangFacade { @PersistenceContext(unitName = "ShaleTestPU") private EntityManager em; public static final String Remote = CategoriesLangImp.class .getSimpleName() + "/remote"; public static final String Local = CategoriesLangImp.class .getSimpleName() + "/local"; public CategoriesLang findById(long categoriesLangId, long languageId) { ... any solution or idea? 2006/9/13, stephan opitz <[EMAIL PROTECTED]>: > i tried comparable, but without success. > > anyone who can helps? > > 2006/9/12, numpsy beelzebub <[EMAIL PROTECTED]>: > > thx craig, > > > > > > > It is possible to access the stateful session bean *indirectly*, if you > > > declare it in a managed bean and then provide a public getter. The > > simplest > > > way to do this is to leverage the resource injection capabilities of a > > Java > > > EE 5 container, so you might have something like this: > > > > > @EJB > > > private MySessionBean mySessionBean; > > > > > public MySessionBean getMySessionBean() { return this.mySessionBean; } > > > > > and you can then use a binding expression like "#{ foo.mySessionBean.bar}" > > > where "foo" is the name of the managed bean containing the above > > > declaration, and "bar" is a property on the session bean itself. > > > > > If you are not running inside an EE 5 app server, you'll have to do the > > > usual sort of JNDI lookup to get a reference to the stateful session bean > > > instead. If you're using Shale's ViewController capabilities, the init() > > > method would be a good place to do that so the bean will be available to > > > other event handlers (and rendering) associated with this bean. > > > > can't follow exactly > > now i use jboss and ask for my entity beans from shale model objects > > try { > > Context context = new InitialContext(); > > contactNotesFassade = (ContactNotesFassade) context > > .lookup(Constants.ProjectNameSeparator > > + ContactNotesFassadeImp.Local); > > } catch (NamingException e) { > > messageLang.setFacesMessage("error.ejb"); > > } > > can image how this @EJB works with shale and how i can have easy access in > > clay etc... > > 1. i declare a stateful session bean mySessionBean mySessionBean > > ejb-web-project part > > 2. an interface with local - here the part with your @EJB code > > 3. access to interface in modelbeans of shale - as you told in init()-method > > > > how i can have access in clay to this away stateful ejb > > > > > > :-/ > > > > 2006/9/11, Craig McClanahan <[EMAIL PROTECTED]>: > > > > > On 9/11/06, numpsy beelzebub <[EMAIL PROTECTED]> wrote: > > > > > > > > hello, > > > > > > > > i want to developed an application using shale and ejb 3.0 (within > > > > container > > > > jboss). > > > > primary i used stateless session beans for access to the entity beans - > > > > persistenz-layer is ok and how to work with it > > > > > > > > as session i will declare a managed bean with an application scope > > > > "session" > > > > and save my data in it. > > > > i thought it is the fastest and easiest way, but in comparing to > > > stateful > > > > session beans it is not the only possible solution. > > > > > > > > in addition to this a few questions: > > > > > > > > 1. i'm fit in clay and know how to access normally ejb 3.0 from shale's > > > > application-logic (building context etc) > > > > but how is it possible to access stateful session bean from view etc. > > > > (normally i have direct access, if it is declared as managed bean) > > > > > > > > > It is possible to access the stateful session bean *indirectly*, if you > > > declare it in a managed bean and then provide a public getter. The > > > simplest > > > way to do this is to leverage the resource injection capabilities of a > > > Java > > > EE 5 container, so you might have something like this: > > > > > > @EJB > > > private MySessionBean mySessionBean; > > > > > > public MySessionBean getMySessionBean() { return this.mySessionBean; } > > > > > > and you can then use a binding expression like "#{ foo.mySessionBean.bar}" > > > where "foo" is the name of the managed bean containing the above > > > declaration, and "bar" is a property on the session bean itself. > > > > > > If you are not running inside an EE 5 app server, you'll have to do the > > > usual sort of JNDI lookup to get a reference to the stateful session bean > > > instead. If you're using Shale's ViewController capabilities, the init() > > > method would be a good place to do that so the bean will be available to > > > other event handlers (and rendering) associated with this bean. > > > > > > > > > 2. i have to initalize context for access ejb, so i thought maybe declare > > > a > > > > interface as managed bean which gives access to stateful session bean > > > > does exist a method in shale except init(), that would be called for > > > > every request, so that i can initialize my access-context > > > > > > > > > > > > Why do you need a method other than init()? That is exactly what it is > > > for. > > > > > > > > > 3. if i want to use stateful-session ejb 3.0 - how is it possible out from > > > > session to define when access of specific user ends. > > > > maybe saving access to stateful-session ejb 3.0 into some kind of > > > state > > > > bean in shale declared as managed bean with session scope -> but if i do > > > > it > > > > so it seems strange > > > > > > > > > My understanding of the typical scenario for Stateful session beans is > > > that, > > > when you want the user's access to end (i.e. they log out or something), > > > then you'll call the remove method o the stateful session bean to make it > > > go > > > away. > > > > > > > > > i save access to a ejb, but i could save the data also direct > > > > 4. generally problem - session in shale is only a javabean with the > > > > session > > > > scope > > > > <-> stateful session bean is server side component (differences are > > > > clear, but what is best to use - where lies advantages) > > > > > > > > it is also a problem because jboss seam gives possibilities for my > > > > problems > > > > http://www.javaworld.com/javaworld/jw-05-2006/jw-0515-jsf-p3.html > > > > > > > > maybe i need some impressions of developer with some kind of more > > > > experience, including th developers of shale > > > > > > > > > Seam encourages you (but does not require you) to use a stateful session > > > bean (SFSB) in a manner fairly similar to using a session scoped backing > > > bean in a regular JSF application. If you're using an SFSB for your > > > business logic anyway, this can save you writing one class (the typical > > > sort > > > of backing bean) that primarily serves as an adapter role. The tradeoff > > > is > > > that you'll typically end up tying the SFSB class to web tier APIs instead > > > of being able to make it independent. > > > > > > A couple of other considerations: > > > > > > * If you're using Shale view controllers, that only works for request > > > scope > > > beans, > > > so you won't be able to make your SFSB class "implements ViewController" > > > and get those sorts of event callbacks. > > > > > > * A SFSB is automatically a transactional resource (depending on what > > > annotations > > > or XML metadata settings you use to configure it), so you don't have to > > > worry > > > about explicitly committing transactions (although you might still need to > > > roll back > > > if you're partway through an update and you need to abort it). You can > > > access > > > things like JPA entity classes directly from a JSF backing bean, but you > > > need to > > > manage transactions yourself. > > > > > > * A SFSB can only be accessed by one thread at a time, so you might find > > > yourself > > > in a situation where the locking that enforces this can cause you > > > performance issues. > > > A classic case is where you've got lots of AJAX-ish calls coming in from > > > the client, > > > such that there will be multiple requests (on different threads) to the > > > same session bean > > > at the same time. With session scoped backing beans, the calls happen > > > simultaneously > > > (but, of course, that means you also need to code your methods in a > > > threadsafe manner). > > > With an SFSB you don't have to worry about coding for simultaneous access, > > > but you do > > > need to worry about the performance impact of the locking. > > > > > > Craig > > > > > > > > > > > > thx so much > > > > > > > > > > > > > > > > > > >