it will created by jsf - i see that tiger annotation does not work at this point
it seems my problem lies in implementation if the injection
public class DataFactory {
@EJB
private CategoriesLangFacade categoriesLangFacade;
public CategoriesLangFacade getCategoriesLangFacade() {
return categoriesLangFacade;
}
}
/////////////////////////////////////////////////////////////////////////////
@Local
public interface CategoriesLangFacade {
public CategoriesLang findById(long categoriesLangId, long languageId);
}
#######################################
@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) {
...
}
}
but this is the way how to
an @local interface, an stateless ejb and DataFactory which should
create injection
2006/9/15, Craig McClanahan <[EMAIL PROTECTED]>:
On 9/15/06, stephan opitz <[EMAIL PROTECTED]> wrote:
>
> does indeed work - i tried under jboss so many different versions of
> implementation...
>
> craig i know your mailreader jpa based on glassfish...
That is true, but I had to follow the advice I gave you ... I had to make
the backing beans that receive injection into standard JSF managed beans,
not using the Shale Tiger @Bean annotation.
maybe it is because of jboss ejb implementation?
>
> my managed bean "datafactory" is in the ejb-jar and defined in
> faces-config.xml
> i have access from any shale model class
Be sure to take @Bean off as well ... if you leave it there, the Tiger
extensions will be creating the bean, instead of JSF itself, so the
injections will not occur.
Craig
if i debug i see
>
> @Resource
> SessionContext sc;
> is null
>
> maybe i have a generall problem with the jboss
>
> does exist any tiger annotation for the postback value?
>
> 5, Craig McClanahan <[EMAIL PROTECTED]>:
> > 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.0from
> > > 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
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> >
>
