On 9/15/06, stephan opitz <[EMAIL PROTECTED]> wrote:
as i reviewed example from jboss:
http://docs.jboss.org/ejb3/app-server/tutorial/injection/injection.html
To facilitate test driven development, the EJB 3.0 specification
allows you to use annotations to inject dependencies through
annotations on fields or setter methods. Instead of complicated XML
ejb-refs or resource refs, you can use the @EJB and @Resource
annotations to set the value of a field or to call a setter method
within your session bean with anything registered within JNDI.
You can use the @EJB annotation to inject EJB references and @Resource
to access datasources.
in conclusion that ejb incejtion only works if registration is within
jndi, so beans under registred ejb stateful or stateless beans should
work without problems as managed bean i gave up
Three comments:
* Did you remove the @Bean annotation as I suggested?
Leaving it there is ***guaranteed*** to make injectino fail.
* I know for a fact that injecting things works on a certified Java EE 5
server (Glassfish).
See the shale-mailreader-jpa example, and note that the Logic bean gets
its
EntityManagerFactory bean injected, without any explicit registration of
JNDI
resource.
* Why are you expecting Java EE 5 compliant behavior from a
container that is not yet Java EE 5 compliant? If there's an issue
here, it seems likely to be with JBoss, if they claim to do
the resource injection but do not do so.
Craig
2006/9/15, stephan opitz <[EMAIL PROTECTED]>:
> 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
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>
