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 ?
########################################
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
> > >
> > >
> >
> >
>
>
