--- Juan Pablo Lorandi <[EMAIL PROTECTED]> wrote: > 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 would technically work. My only beef with that is (atleast with the type of information I am wanting to store), I feel the burden of knowing/locating these properties should be on the component itself, rather than it's clients. Thanks for this and your other suggesttion, though. So, the overhead of the JDBC and URLConnection approaches isn't too bad? Thanks Again, Mike > > 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". > __________________________________________________ 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".
