Hi Christian, You know Tapestry very well. Do you have any points of comparison with JEE JSF, e.g. Ice Faces?
It seems to me that JSF is very similar (by borrowed design) to Tapestry. But there must be technical points of significant difference? I haven't dived down to find these. I'm working for a company called Yell Labs, which is trying in some way to turn around a book based (paper published) directory service and align it with the internet. Of course it does have an on line presence and the whole thing is an interesting, if a bit depressing and long, business story that collides with a story of technical difficulty and ineptness. Unfortunately, I'm afraid we are still being inept. Best, Adam On 4 November 2010 23:11, Christian Riedel <cr.ml...@googlemail.com> wrote: > Hi Adam, > > do you need to use the sfsb across multiple requests as a kind of > conversational bean or is it sufficient to hold the reference for the time > of one request? > You can define a Tapestry-Service's scope as "per-thread" (1) so you could > wrap the connection to your remote inside a service similar to your current > approach. > For proper conversational support in T5 you could also utilize Tynamo's > module (2). That way you would avoid storing proxys directly in the session. > > The right solution depends on your use case :) > > (1) > http://tapestry.apache.org/tapestry5.1/apidocs/org/apache/tapestry5/ioc/annotations/Scope.html > (2) http://tynamo.org/tapestry-conversations+guide > > Best > Christian > > > Am 04.11.2010 um 22:55 schrieb Adam Zimowski: > > > Hi Experts - > > > > Our business (service) layers lives within OpenEJB on a remote host. > > Most of our business logic (DAOs, etc) are stateless session beans. We > > were able to elegantly define them as Tapestry services using standard > > static module builder. Here is our (simplified) EjbModule with one > > statless EJB: > > > > /** > > * Defines all aspect of EJB remoting. Each EJB becomes a singleton > > * Tapestry IOC service, and can be used from a page or component > > * via @Inject or @InjectService. > > * > > * @author Adam Zimowski > > */ > > public class EjbModule { > > > > private static final Logger log = > > LoggerFactory.getLogger(EcommerceModule.class); > > > > public static Context buildEjbContext(@Inject @Value("${ejb.host}") > > String aEjbHost) { > > > > if(log.isDebugEnabled()) log.debug("EJB host: " + > aEjbHost); > > > > Properties p = new Properties(); > > p.put(Context.INITIAL_CONTEXT_FACTORY, > > "org.apache.openejb.client.RemoteInitialContextFactory"); > > p.put(Context.PROVIDER_URL, aEjbHost); > > > > Context ctx = null; > > > > try { > > ctx = new InitialContext(p); > > } > > catch(NamingException ne) { > > log.error("EJB host lookup error!", ne); > > } > > > > return ctx; > > } > > > > public static CatalogServiceRemote > > buildCatalogService(@InjectService("EjbContext") Context aEjbContext) > > { > > > > CatalogServiceRemote catalogService = null; > > > > try { > > Object ref = > aEjbContext.lookup("CatalogServiceEjbRemote"); > > catalogService = > > > (CatalogServiceRemote)PortableRemoteObject.narrow(ref, > > CatalogServiceRemote.class); > > } > > catch(NamingException ne) { > > log.error("Unable to create " + > > CatalogServiceRemote.class.getSimpleName(), ne); > > } > > > > return catalogService; > > } > > } > > > > Works perfectly. In a page or component we simply do: > > > > @InjectService("CatalogService") > > private CatalogServiceRemote catalogService; > > > > and we're talking to a statless EJB on a remote host. > > > > Things become a bit tricky with a statfull session bean. I don't see > > how I can use the same approach since I now need to retain a state > > meaning I need to hold onto a specific EJB instance per request. > > > > What's the preferred and recommended way to use statefull session > > beans within a Tapestry application? > > > > The closest I've got was to define some sort of a factory, and store > > the proxy in the HttpSession. May work, but so ugly comparing to our > > elegant solution with statless beans. > > > > Any ideas highly appreciated. > > > > Adam > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > For additional commands, e-mail: users-h...@tapestry.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
