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