You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lécharny <el...@gmail.com> on 2015/04/03 13:46:51 UTC
[Fortress] fortress-core release
Hi guys,
I have cleaned up the fortress-core pom to be able to cut a first
release. The idea is to not depend on a parent pom at the moment, but
release the four different projects (with enmasse, realm and commander)
separately. We will most certainly regroup all of them later, but that
requires a new git repo.
The release will only be a source release (ie, we won't generate a
binary package containing all the needed jars). As this is a library, it
makes sense, as most of our users will use Maven (or a flavor of maven)
to pull the jars.
For commander, it's a bit more complex, and I'm waiting for some input
to decide how to release it, as we wnt to produce a war.
Thanks for testing the first release as soon as t will be out (later today).
Emmanuel
Re: [Fortress] fortress-core release
Posted by Kiran Ayyagari <ka...@apache.org>.
On Sat, Apr 4, 2015 at 4:12 AM, Shawn McKinney <sm...@apache.org> wrote:
>
> > On Apr 3, 2015, at 11:49 AM, Kiran Ayyagari <ka...@apache.org>
> wrote:
> >
> > 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 ;)
>
> Yes, this is a good idea too. So here is what I think we could do:
>
> 1. read first from env variable
> 2. if that isn’t set, read from servlet context (as Stefan suggested)
> 3. finally read from the fortress.properties if other two not set.
>
> This will cover all the bases but will take a little bit of work. I’ll add
> a JIRA and we can aim to get it fixed on next release.
>
> WDYT?
>
> +1
> Shawn
> smckinney@apache.org
>
--
Kiran Ayyagari
http://keydap.com
Re: [Fortress] fortress-core release
Posted by Shawn McKinney <sm...@apache.org>.
> On Apr 3, 2015, at 11:49 AM, Kiran Ayyagari <ka...@apache.org> wrote:
>
> 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 ;)
Yes, this is a good idea too. So here is what I think we could do:
1. read first from env variable
2. if that isn’t set, read from servlet context (as Stefan suggested)
3. finally read from the fortress.properties if other two not set.
This will cover all the bases but will take a little bit of work. I’ll add a JIRA and we can aim to get it fixed on next release.
WDYT?
Shawn
smckinney@apache.org
Re: [Fortress] fortress-core release
Posted by Kiran Ayyagari <ka...@apache.org>.
On Sat, Apr 4, 2015 at 12:29 AM, Stefan Seelmann <ma...@stefan-seelmann.de>
wrote:
> On 04/03/2015 05:59 PM, Shawn McKinney wrote:
> >
> >
> >> On Apr 3, 2015, at 10:38 AM, Shawn McKinney <sm...@apache.org>
> wrote:
> >>
> >>>
> >>> On Apr 3, 2015, at 10:27 AM, Stefan Seelmann <ma...@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
Re: [Fortress] fortress-core release
Posted by Shawn McKinney <sm...@apache.org>.
> On Apr 3, 2015, at 11:29 AM, Stefan Seelmann <ma...@stefan-seelmann.de> wrote:
>
> 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.
Great idea, and yes, that will work very well. Thanks for the help.
Shawn
smckinney@apache.org
Re: [Fortress] fortress-core release
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
On 04/03/2015 05:59 PM, Shawn McKinney wrote:
>
>
>> On Apr 3, 2015, at 10:38 AM, Shawn McKinney <sm...@apache.org> wrote:
>>
>>>
>>> On Apr 3, 2015, at 10:27 AM, Stefan Seelmann <ma...@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.
Kind Regards,
Stefan
Re: [Fortress] fortress-core release
Posted by Shawn McKinney <sm...@apache.org>.
> On Apr 3, 2015, at 10:38 AM, Shawn McKinney <sm...@apache.org> wrote:
>
>>
>> On Apr 3, 2015, at 10:27 AM, Stefan Seelmann <ma...@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.
Thanks
Shawn
smckinney@apache.org
Re: [Fortress] fortress-core release
Posted by Shawn McKinney <sm...@apache.org>.
> On Apr 3, 2015, at 10:27 AM, Stefan Seelmann <ma...@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?
Shawn
smckinney@apache.org
Re: [Fortress] fortress-core release
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
On 04/03/2015 04:44 PM, Shawn McKinney wrote:
>> On Apr 3, 2015, at 6:46 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>>
>> For commander, it's a bit more complex, and I'm waiting for some input
>> to decide how to release it, as we wnt to produce a war.
>>
>> Thanks for testing the first release as soon as t will be out (later today).
>
> I struggle with the idea of publishing a .war for commander. Before this app may be deployed (correctly), it requires configuration settings for a particular ldap host server. In this scenario, a user would have to hand edit a config file and poke it back into the .war before it would work. Not a very good practice IMO. I’ll need to think about this and come up with a solution.
I think the standard JEE way is to put all configuration to context.xml
[1] which can be deployed together with the war.
Kind Regards,
Stefan
[1]
https://tomcat.apache.org/tomcat-8.0-doc/config/context.html#Context_Parameters
Re: [Fortress] fortress-core release
Posted by Emmanuel Lécharny <el...@gmail.com>.
>> On Apr 3, 2015, at 6:46 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>>
>> Thanks for testing the first release as soon as t will be out (later today).
> Tried to build and received an error pulling down directory api-all M29. Understand this has *just* been released so this is probably just a timing issue.
>
> One problem I can see is the maven install isn’t publishing the javadoc artifacts to the local .m2 repo, though it can be found under target. Not a showstopper, just something to figure out.
Seems like Nexus fucked up... The release is in 'Operation in Progress'
for around 2 days now, and I can't fix it. I just have pinged infra :/
You can build the LDAP API tag locally, it should then work.
Re: [Fortress] fortress-core release
Posted by Shawn McKinney <sm...@apache.org>.
Hello, this is my first release with apache directory project so please forgive the naive questions….
> On Apr 3, 2015, at 6:46 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>
> I have cleaned up the fortress-core pom to be able to cut a first
> release. The idea is to not depend on a parent pom at the moment, but
> release the four different projects (with enmasse, realm and commander)
> separately. We will most certainly regroup all of them later, but that
> requires a new git repo.
>
OK
> On Apr 3, 2015, at 6:46 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>
> The release will only be a source release (ie, we won't generate a
> binary package containing all the needed jars). As this is a library, it
> makes sense, as most of our users will use Maven (or a flavor of maven)
> to pull the jars.
Agreed. Assuming by this you mean we will still release (upload to maven central repo) the targets of the maven install operation.
> On Apr 3, 2015, at 6:46 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>
> For commander, it's a bit more complex, and I'm waiting for some input
> to decide how to release it, as we wnt to produce a war.
>
> Thanks for testing the first release as soon as t will be out (later today).
I struggle with the idea of publishing a .war for commander. Before this app may be deployed (correctly), it requires configuration settings for a particular ldap host server. In this scenario, a user would have to hand edit a config file and poke it back into the .war before it would work. Not a very good practice IMO. I’ll need to think about this and come up with a solution.
> On Apr 3, 2015, at 6:46 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>
> Thanks for testing the first release as soon as t will be out (later today).
Tried to build and received an error pulling down directory api-all M29. Understand this has *just* been released so this is probably just a timing issue.
One problem I can see is the maven install isn’t publishing the javadoc artifacts to the local .m2 repo, though it can be found under target. Not a showstopper, just something to figure out.
Thanks,
Shawn