First, let's say the properties are stored on a java.util.Vector(or anything else implementing List, or Map, or....)
Receive the vector either in the constructor or within a setter method. That being out of the way, the restrictions for file I/O are there because there's no transaction management in file I/O; hence using a properties file isn't betraying the spec per se. But most app servers won't help you to make the properties files available; they use special ClassLoaders that may or may not let you access these files, etc. If you're reasonably sure which target platform your app will be deployed in, you could try and figure out how to access prop. files. JNDI... Well, even if it is slow, you could just cache the data. The bad thing is, you'll (usually, with exceptions) have to redeploy to make changes to the settings. JMX won't work just anywhere(regrettably), altough it's a good solution. Another way I can think of is to store everything in a properties like table, then use JDBC to read it. It means you could change the prop. data without redeploying. I've used this approach a lot. Another solution I'm using more regulary now is using an XML file deployed in a nearby web-server(or the same one), get it using URL.openConnection(...), and parsing it to retrieve the values. I do this on a static method of one of my components, store the Vector, while also providing for a static void reloadProperties() method that... well... reloads all properties. Works like a charm. Well, that's my 2c; HTH, Juan Pablo Lorandi Chief Software Architect Code Foundry Ltd. [EMAIL PROTECTED] Barberstown, Straffan, Co. Kildare, Ireland. Tel: +353-1-6012050 Fax: +353-1-6012051 Mobile: +353-86-2157900 www.codefoundry.com > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]] On Behalf Of Chaganthi, > Madhusudan R. > Sent: Monday, June 03, 2002 4:51 PM > To: [EMAIL PROTECTED] > Subject: Re: Uniform Environment/Property Access for EJBs and Non-EJBs > > > How about using JMX? > > Store env properties in xml file. > Read xml file via a startup class into a singleton cache. > Write a JMX MBean, which will have reloadCache method on it. > This reload cache can implement a read-write-strategy pattern > (found at > www.theserverside.com) to enable modifications without > affecting the clients. Only authorized clients can access > this JMX Mbean for modifying the properties while the server > is up and running. EJBs and POJO will then use the singleton > cache to read the properties. > > I am sure that there is some more complexity involved in > clustering because of the usage of the singleton. > > Maybe others can pitch in. > > Thanks > Madhu > > -----Original Message----- > From: Mike Dunbar [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 03, 2002 11:45 AM > To: [EMAIL PROTECTED] > Subject: Uniform Environment/Property Access for EJBs and Non-EJBs > > > Hello, > I am wondering if some of you have already fought this battle > and could help me out before I do my own brainstorming. > Basically, we don't want to "hard-code" our business logic > components into the EJB model. We would like to develop the > core components in plain ol' Java and "wrap"/deploy them as > EJBs when it makes sense. Basically, the EJB would just > delegate to the "wrapped" Java component. Sounds simply enough, right? > > The part I need help with is: how to give the components > access to configurable properties in a way that works both > when they are deployed as an EJB, and when they are not > deployed as an EJB? The most straight forward way would seem > to be putting such properties a Java properties file, but I > believe EJBs are not allowed to do file I/O - right? I think > EJBs usually get such information from JNDI entries specified > in the EJB's deployment descriptor as <env-entry>'s. Is there > a uniform mechanism that will work both when the components > are deploy as EJBs and when they are not? For example, maybe > the components could always access the properties via JNDI. > Sometimes an application server would have put them there > (when deployed as an EJB), sometimes they would've got there > via another mechanism (when they are not deployed as an EJB). > But, I've heard that JNDI lookup's give pretty bad > performance. This would also require a naming server to > present whenever they are Deployed, which I think is more > demanding than something like a simple properties file. > > Has anyone else tried to do this? Could you point me in the > right dirction? This seems like a common approach people > would want to use - not tying your code to a given component > model so it could be used outside of that model also. > > Much Thanks for Your Help! > Mike > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ======================================================================== === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". ======================================================================== === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
