geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Where to store secret EJB properties?
Date Tue, 21 Oct 2008 20:34:30 GMT

On Oct 21, 2008, at 12:31 PM, Juergen Weber wrote:

> David, thanks so far, "Locating your application specific
> configuration files" is a step in the right direction. This helps in
> organizing property files, which is better than directly loading them
> from the file system.
> I also was looking for a way to enhance the @Resource injection  
> system.
> Now it would be great if one could use a SystemPropertiesGBean to
> inject @Resource into an EJB...

This is a less direct solution to your immediate problem but you might  
want to look into gbean bindings into jndi.  I think this is the  
geronimo equivalent of what the sun article was suggesting.  To get  
even closer we could write a gbean that bound an object factory into  
jndi.  The reason the sun idea won't work "as is" in geronimo is that  
we have no persistent jndi: everything is bound as the server starts  
and various components start and bind stuff.  So the equivalent of  
using the sun admin console to set up a persistent binding would be to  
have a gbean in some plugin that, on starting, would bind whatever is  

The gbean binding stuff is in geronimo-naming GBeanBinding class.

david jencks

> thanks,
> Juergen
> On Tue, Oct 21, 2008 at 7:42 PM, David Jencks  
> <> wrote:
>> On Oct 21, 2008, at 9:38 AM, Juergen Weber wrote:
>>> The canonical way to have properties for EJBs is IMHO to use <env- 
>>> entry>
>>> in
>>> ejb-jar.xml and have them injected via @Resource.
>>> ejb-jar.xml are like source and in source control and are put in the
>>> ejb.jar
>>> by ant.
>>> Obviously this is not a good idea for passwords.
>>> Is there a way to save properties via the Geronimo Console (or  
>>> deployer)
>>> and
>>> have them injected via @Resource?
>>> I guess properties in .properties in a .jar cannot be injected,  
>>> can they?
>>> Could this be done via javax.naming.spi.ObjectFactory as suggested  
>>> in the
>>> comment here:
>> I'm sure that wouldn't work in geronimo naming (e.g. in a web app in
>> geronimo, which only uses geronimo naming stuff) and doubt openejb  
>> has a way
>> to make it work (IIRC openejb does some of its own jndi setup).  I  
>> also
>> don't see how this  would conceal the secrets.  Wouldn't they now  
>> be in the
>> source code of the ObjectFactory class?
>> I can think of a couple approaches that you might find suitable.   
>> One is
>> having an application specific data file as explained here:

>> .
>> This also hints at the other, using a system property to store the  
>> secret,
>> set up with a SystemPropertiesGBean in the geronimo plan for your  
>> app.  In
>> this case however I would advise:
>> - use maven :-)
>> - deploy your app as a geronimo plugin using the car-maven-plugin
>> - include a config.xml snippet in the geronimo-plugin.xml  
>> (generated from
>> the car-maven-plugin configuration)
>> - set up the property value as a  
>> variable.
>> Now you can either set the secret directly in
>> var/config/ or on the command line,  
>> e.g. with
>> gshell
>> geronimo/start-server -G mySecret=foo
>> hope this helps
>> david jencks
>>> Thanks,
>>> Juergen
>>> --
>>> View this message in context:
>>> Sent from the Apache Geronimo - Users mailing list archive at  

View raw message