directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: [Fortress] fortress-core release
Date Fri, 03 Apr 2015 16:49:41 GMT
On Sat, Apr 4, 2015 at 12:29 AM, Stefan Seelmann <mail@stefan-seelmann.de>
wrote:

> On 04/03/2015 05:59 PM, Shawn McKinney wrote:
> >
> >
> >> On Apr 3, 2015, at 10:38 AM, Shawn McKinney <smckinney@apache.org>
> wrote:
> >>
> >>>
> >>> On Apr 3, 2015, at 10:27 AM, Stefan Seelmann <mail@stefan-seelmann.de>
> wrote:
> >>>
> >>>
> >>> I think the standard JEE way is to put all configuration to context.xml
> >>> [1] which can be deployed together with the war.
> >>
> >>
> >> For JEE managed resources like datasources I agree but how would this
> work for application managed resources like ldap connections?
> >
> >
> > Stefan your comments have me thinking….
> >
> > Arbitrary name/value pairs can be added to context.xml and made
> available to the app.  Not all of the fortress properties would need to go
> there, just the ones that tell it how to connect to the directory.
> >
> > So if we allowed overrides of the ldap props, e.g. ldap.host, to be
> dropped into context.xml - what is the procedure for deployment?  i.e. when
> would the user modify the file, and where would the file reside?
> >
> > I currently use context.mxl for integrating with the fortress tomcat
> security realm.  But that file also resides in the war’s /meta-inf folder.
> So my assumption is the user stages their own copy of context.xml outside
> the .war, where tomcat picks it up.  If assumption is correct, this would
> work fine.
>
> Yes, that is what I meant. You can put an external context.xml (but
> named webappname.xml) to conf/Catalina/localhost/[webappname].xml.
>
> In the context.xml you can then add arbitrary name/value pairs which can
> be read by ServletContext.getInitParameter():
>
> <Context>
>   <Parameter name="..." value="..." />
> </Context>
>
> We use this pattern @work and it works quite fine. However it seems this
> is very Tomcat specific, but maybe other servlet containers / JEE
> servers provide similar means to allow external configuration.
>
yep, this is indeed very tomcat specific.
otoh, wondering if these parameters are a must during app startup
I know this is convenient configuration to move fast with development.

I suggest to have FORTRESS_HOME or FORTRESS_CONF env variable
and read the config from that location. If this variable is not set then
the default
config can be extracted and used.

If this variable is set and if no config is present default can be copied
over there
during startup and used by the app.

Note sure if all this can be done in this version to be released, but good
to have
cause users will love to try such software bundles ;)

>
> Kind Regards,
> Stefan
>
>


-- 
Kiran Ayyagari
http://keydap.com

Mime
View raw message