try {
context = new InitialContext();
categoriesFacade = (CategoriesFacade) context
.lookup(ShaleTest
+
CategoriesImp.class/local);
} catch (NamingException e) {
e.printStackTrace();
}
in this way it works... strange but maybe it is so... if my
datafactory is in the ejb web-project shale tiger seems not to work ->
because will be included the ejb.jar -> faces-config.xml solves
problem to access the managed bean, but only with jndi- look-up in get
makes no fun, in ejb spec:
http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=javaee-5.0-fr-spec-oth-JSpec&SiteId=JSC&TransactionId=noreg
it is so easy @EJB Cart ...
maybe should shale built a more easy bridge
2006/9/15, stephan opitz <[EMAIL PROTECTED]>:
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
> > > >
> > > >
> > >
> > >
> >
> >
>
