Thx. The AppServer we're currently working with (WAS 3.5) does appear to support this but we want the app to work across different AppServers.
I'll bear your comments in mind /Colin ----- Original Message ----- From: "Rajeev Kaul" <[EMAIL PROTECTED]> To: "Turbine Users List" <[EMAIL PROTECTED]> Sent: Thursday, June 20, 2002 6:40 PM Subject: Re: Fulcrum + EJB's > Colin, > > The EJB spec does not permit either threads or disk i/o. However, not all > app servers enforce these rules. There are no good options for logging > inside EJBs. You could either use the logger of the EJB container, sockets, > a logging servlet on a separate machine, JNDI resource, etc. - all ugly > options in my opinion. > > You could also ignore the EJB spec and hope that your app server does not > complain. > > Rajeev > ----- Original Message ----- > From: "Colin Chalmers" <[EMAIL PROTECTED]> > To: "Turbine Users List" <[EMAIL PROTECTED]> > Sent: Wednesday, June 19, 2002 11:44 PM > Subject: Re: Fulcrum + EJB's > > > > Thx Rajeev, > > > > This sounds a good solution and cleaner than my present implementation. > > > > Just concerning your last sentence "make sure that none of the services > you > > need are neither using threads nor doing file i/o." > > > > We're not using Threads, we are writing to disk and would need to use the > > logging service. What kind of problems could we expect from this? > > > > /Colin > > > > > > > Colin, > > > > > > You do not need to initialize the Fulcrum in every ejb, but in every ejb > > > container. One way to do this is to use the init() method of the > servlet > > to > > > call a special EJB stateless session initialization bean, and pass it > the > > > turbine configuration (by fetching it from the > > > TurbineResources.getConfiguration()). This is possible because the > > > configuration is an instance of the ExtendedProperties class which is > > > derived from the HashTable. Since, the HashTable is serializable, you > can > > > pass the configuration as a parameter to the method of the > initialization > > > EJB. The EJB will initialize the required services for its EJB > container, > > > using the configuration it receives from the servlet. This gets around > the > > > problem of reading turbine properties from a file inside the EJB > > container - > > > since the EJB spec prohibits it. From here on, all other EJBs can use > the > > > fulcrum services. Again, just make sure that none of the services you > > need > > > are neither using threads nor doing file i/o. > > > > > > Rajeev > > > ----- Original Message ----- > > > From: "Colin Chalmers" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Wednesday, June 19, 2002 1:17 PM > > > Subject: Fulcrum + EJB's > > > > > > > > > > Is anyone using Fulcrum with EJB's? > > > > > > > > I managed to get Turbine to run under WebSphere 3.5 but had to play > > around > > > a > > > > bit with the manner in which the Classes are loaded; WebSphere 3.5 has > > got > > > a > > > > hierarchy of classloaders which complicated things. > > > > > > > > The reason it's working so well at the moment is because of the > Servlet > > > > properties of Turbine, it's those same Servlet properties that I'm NOT > > > > actually using from the EJB's. All I want to do is use a number of > > > services > > > > which have now been moved to Fulcrum. > > > > > > > > Presently, Turbine gets started when the app server starts afterwhich > I > > > can > > > > access all services. I can't imagine that I have to initialize Fulcrum > > in > > > > every EJB when it's created. > > > > > > > > Any tips appreciated > > > > > > > > /Colin > > > > > > > > > > > > > > > > -- > > > > To unsubscribe, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > For additional commands, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > -- > > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
