What I see often at my customers is the heavy used of Maven to do
configuration. Either they use resource filters (so we can change
${variables} with values) or profiles (several ejb-jar.xml, each for a
specific environment). In big projects both approaches can be really
confusing. And of course, packaging your application without Maven is just
impossible.
@Bill I agree that we have deployment descriptors but the problem is that
we have many of them. We lack of a central point of configuration. In the
"Maven Profile" approach, projects end-up having several persistence.xml,
ejb-jar.xml, faces-config.xml.... per environment. I think we already
mentioned that a few month ago in this ML, but it would be interesting if
we could think of a centralized configuration solution (other than JNDI)
Like Andrew I feel variable approach is safer as you could get an exception
if the variable is not defined. But overriding can be smoother in the point
that the application "works" out of the box.
I'm not a JBoss employee ;o) but I really find Seam Solder (formally known
as Seam Config) interesting and would love to have something similar in
Java EE (type-safe XML, I love it ;o) I don't enough Spring Config to
compare both approaches.
http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/introduction.html
http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/xml-provider.html
Antonio
On Tue, Jan 31, 2012 at 23:17, Andrew Phillips <demobox1_at_yahoo.co.uk> wrote:
> Perhaps a further angle on the "replacement token vs. override property"
> debate [1]:
>
> Replacement tokens make it pretty unambiguously clear that the values for
> these properties may vary per environment and need to be supplied at
> deployment-time (as Bill points out, the changes of a password being
> "${myAppPassword}" are relatively small).
>
> This makes the expected "customization points" of the application somewhat
> self-documenting. It also allows for better "fail-safe" behaviour since you
> could fail the deployment if a value for a given token was not found at
> deployment time.
>
> Using overrides of existing properties is certainly convenient as the
> application "always works", but firstly it leaks environment-specific
> information into the source code ("localhost" and other values that need to
> be overridden often refer to the dev environment) and can make for very
> hard-to-detect errors.
>
> "Exception: no value for placeholder ${myAppPassword}" certainly seems
> clearer to me than a runtime "Unable to create database connection"
> exception (because you're pointing to the wrong DB, using the wrong
> credentials etc.)
>
> ap
>
> [1] or "token-based vs. pointer-based replacement" as discussed at much
> greater length in this post:
> http://blog.xebia.com/2010/07/05/customize-this-tailoring-deployment-packages-to-your-target-environments/
>
> ------------------------------
> *From:* David Blevins <david.blevins_at_gmail.com>
> *To:* jsr342-experts_at_javaee-spec.java.net
> *Sent:* Tuesday, 31 January 2012, 14:19
> *Subject:* [javaee-spec users] [jsr342-experts] Re: password aliasing
> proposal
>
> I can't quite tell if we're off topic, we definitely are somewhat, but I
> like the discussion.
>
> There are sort of two camps of thought on this kind of thing. The one
> camp where you fill in "this can be replaced".
>
> @DataSourceDefinition(name="${myDataSource}",
> className="com.mysql.jdbc.jdbc2.optional.MysqlDataSource",
> user="${myUserId}",
> password="${password}",
> databaseName="${dbName}",
> serverName="localhost",
> portNumber=3306 )
>
> - myUserId = joe
> - password = cool
> - dbName = peanuts
>
> We'll call it the "variables" approach. In this approach you end up
> scooping out all the metadata till there is just a shell left. In the
> extreme case the @DataSourceDefinition doesn't define anything anymore and
> ultimately serves little purpose aside from providing structure.
>
> The other camp is "anything with simple properties can be replaced"
>
> @DataSourceDefinition(name="moviesDataSource",
> className="com.mysql.jdbc.jdbc2.optional.MysqlDataSource",
> user="jane",
> password="doe",
> databaseName="films",
> serverName="localhost",
> portNumber=3306 )
>
> - moviesDataSource.user = joe
> - moviesDataSource.password = cool
> - moviesDataSource.databaseName = peanuts
>
> We'll call it the "override" approach.
>
> The advantages of the override approach:
> - there are defaults
> - all replacement is optional
> - all replacement is possible
>
> Both approaches hinge on you having a unique name. You either guarantee
> "moviesDataSource" is unique or you need to guarantee "myUserId" is a
> unique variable. Really the same thing. Slight difference is the number
> of "unique keys" you have to manage. One vs six using
> @DataSourceDefinition as an example.
>
> Geronimo uses the variables approach, OpenEJB/TomEE use the override
> approach.
>
> What I've seen happen is the day you have two datasources, you fall into
> this with the variables approach:
>
> - moviesDataSourceUserId = joe
> - moviesDataSourcePassword = cool
> - moviesDataSourceDbName = movies
> - booksDataSourceUserId = arthur
> - booksDataSourcePassword = dent
> - booksDataSourceDbName = books
>
> Only you didn't start with the long "moviesDataSourceUserId" kind of
> unique key, so you first have to go and rename all your old "myUserId"
> variables to the long version before you can deal with the new
> "booksDataSource".
>
> In the override approach where name is the unique key, you get that from
> day one. The downside is it isn't really easy to deal with complex
> annotations.
>
> Attempting to be more on topic, I wonder if we need a syntax.
>
> Instead of having to explicitly add a "this is not a password" entry in a
> deployment descriptor or xml file, why not just leave it out? Do we need
> to actually a value to say that the value will be handled elsewhere?
>
> As vendors we already have the ability to change any part of the
> application metadata without the code having to reflect that. The status
> quo on that seems pretty good. There could be good value in focusing on
> sections 2 and 3 of the proposal and leaving out the part where application
> developers have to enable that in the annotations or descriptors.
>
> In the extreme case would really put the entire <data-source> definition
> in this secure storage.
>
>
> -David
>
>
> On Jan 31, 2012, at 5:42 AM, Antonio Goncalves wrote:
>
> > Not sure about the ALIAS= syntax. What about the good old EL ? I agree
> with Jevgeni, we've already talked about configuration issues in EE. It has
> to go further not just restricted to passwords. What about :
> >
> > @DataSourceDefinition(name="${myDataSource}",
> > className="com.mysql.jdbc.jdbc2.optional.MysqlDataSource",
> > user="${myUserId}",
> > password="${password}",
> > databaseName="${dbName}",
> > serverName="localhost",
> > portNumber=3306 )
> >
> > Sorry if I didn't understand well but passwords are just one of the many
> possible configuration on an EE app. The fact that it's encrypted makes it
> slightly different but we could treat it in a different way. Something like
> password="${aClearPassword}" and
> password="${encrypted(anEncryptedPassword}".
> >
> > Antonio
> >
> > On Tue, Jan 31, 2012 at 09:45, Jevgeni Kabanov <
> jevgeni_at_zeroturnaround.com> wrote:
> > Is there a reason it is limited to passwords? I'm sure a generic ${}
> > Ant-style configuration string post-processing would be greatly
> > appreciated by the community.
> >
> > Sent from my iPhone
> >
> > On 31.01.2012, at 0:49, Bill Shannon <bill.shannon_at_oracle.com> wrote:
> >
> > > I've uploaded a proposal from our security team for password aliasing
> > > support in Java EE 7. Let me know if you have any comments.
> > >
> > >
> http://java.net/projects/javaee-spec/downloads/download/password-aliasing-ee7-proposal.pdf
> >
> >
> >
> > --
> > Antonio Goncalves
> > Software architect and Java Champion
> >
> > Web site | Twitter | Blog | LinkedIn | Paris JUG
>
>
>
>
--
Antonio Goncalves
Software architect and Java Champion
Web site <http://www.antoniogoncalves.org> |
Twitter<http://twitter.com/agoncal>|
Blog <http://feeds.feedburner.com/AntonioGoncalves> |
LinkedIn<http://www.linkedin.com/in/agoncal>| Paris
JUG <http://www.parisjug.org>