I agree with Jeff - finding configuration faults at deploy time, which would cause rollbacks, feels a bit dramatic. Not to mention waiting for session quiescence. CDI is awsome and solves runtime configuration for applications, but not for the app server itself and we would still lack a common configuration management interface.
Configuration Management is a cross-cutting concern we see in all our products. We usually approach our customers with a ecosystem of products (developed by different organizations) offering unique customer solutions based on composition of these products (the SOA approach). A coherent view of configuration is neccessary to keep OPEX low for customers in distributed and complex solutions (and they usually are).
For us, configuration data is similar to runtime application data in the sense that it also subject to high availability and disaster recovery. So it usually make sense to be able to manage both in the same storage. Or even delay choice of storage technology to the customer (that sometimes have well established data policies) by being able to plug different implementation into the common configuration management SPI.
Configuration is also what enables product customization in a very diverse and controlled way. From this perspective we envision an declarative API for modules (also to be used by app server providers) to clearly express their configuration schema to the administrator. Schemas also provide validation (JSR 303, error messages etc) for asserting predictable behaviour on behalf of modules, before configuration changes are commited to storage and picked by runtime modules.
Cheers,
-Kristoffer
________________________________
From: Jeff Genender [mailto:jgenender_at_savoirtech.com]
Sent: den 14 juni 2011 18:07
To: jsr342-experts_at_javaee-spec.java.net
Subject: [jsr342-experts] Re: Configuration
I guess I can chime in here... OSGi is a very large part of our work and obviously we are seeing JavaEE containers moving towards OSGi...so my guess is this topic will come up much more frequently.
This is a touchy subject and this really plays into things that work and its interesting you point out JNDI because that is very transitionary with regard to OSGi.
Spring has been difficult in OSGi because the classloading mechanisms and protections sort of counter each other. Spring wants the ability to share application contexts across bundles, where OSGi wants to be very restrictive. In Spring-DM, its been great to use no JNDI and simple wiring in of transactions. However, the dichotomy of Spring vs OSGi classloaders causes huge issues of "Spring Context Resets" and loss of classes not being found when they encountered a bundle refresh. Its a difficult problem to work around and there are long recipes of workarounds one needs to implement to prevent these problems - in essence its a nightmare. Thus, this is where Blueprint comes in which is a lighter weight "Spring" and for those in the know I believe Spring has a huge hand in its development. Blueprint is essentially a way to do "Spring" in OSGi with minimal impact on the classloading and classes getting lost in the shuffle. I won't go into the technical details since the OSGi spec really clarifies it and a Google will yield a lot of information on this subject.
Getting into how this related to your comment/question... we found that Blueprint seems to be much more heavily reliant on XA transactions and seems to be much more reliant on the JNDI mechanism in being able to get cross transactions like Spring used to do for us automatically. Blueprint Transaction seems to be very JNDI centric. We actually found that in using Blueprint with transactions and JPA, we were actually wiring together nearly a fully functional JavaEE style container that utilized traditional methods of JavaEE, while allowing some of the ease of Spring.
So pulling this somewhat together, one of the reasons I wanted to comment on the configuration/management really plays into the ability to provision modules on-the-fly without the necessity to bring down containers which has been a significant challenge in the past. Some comments I have gotten is, "then just architect rolling deployments". This is fine for a handful of servers. But once you get into government entities and large companies who are running cloud applications with up to 3000 containers, rolling deployments are no longer a viable and reasonable option.
Hence this is the reason I am very interested in this discussion and seeing PaaS and on-the-fly configuration/management/admin as this is really becoming visual, especially in the OSGi arena. So it seems JNDI and other traditional JavaEE configuration seems to be showing a hybrid with Spring-like configurations in the OSGi world (at least for now, that seems the direction).
I hope this was helpful and not too long of an answer ;-)
Jeff
On Jun 14, 2011, at 8:47 AM, Antonio Goncalves wrote:
Talking about our experiences at customers, JNDI is not what I commonly see. Teams use Maven profiles, property.files, XML, Spring Configuration or funny parsing of Strings (eg. @@This is a value you need to parse@@). And that's also because JNDI is of no use when you work with Tomcat, Batch of other non-full-EE server.
All this is funny because configuration is crucial to applications and it feels we don't use the right tool. I would like to hear more from people of the OSGi landscape, Spring Config or Seam Config... They have a lot of experience in this matter
On Tue, Jun 14, 2011 at 16:16, Jeff Genender <jgenender_at_savoirtech.com> wrote:
I have to say that we all see different visuals based on our own customers and our own perspectives with what we work with ;-)
I do a lot of service based EE work and the biggest cry I hear is run time deployment management and administration including provisioning, etc. This area is really hot right now from my perspective and it plays very heavily in the the cloud arena.
I think its definitely something we need to grapple with and not put off since we will be behind the 8-ball again in getting these things ready to market.
The biggest problem we have out there in this area is a lot of fragmentation in the configuration/management/admin of stacks and I really think its a good idea for us to tackle this and not put it off to JavaEE8.
Just my lousy .02 ;-)
Jeff
On Jun 14, 2011, at 8:06 AM, Reza Rahman wrote:
> Kristoffer,
>
> To be completely honest with you, we don't see a big customer demand for deployment-time/run-time administration of deployment descriptors (I know that's probably crazy talk in Java EE land with all of our Java EE roles :-)). In our design we have the capability to bind values from a property like this:${some.value}. The property could either come from a property file (pre-pended by the property file name if needed or get overridden by a system/environment property if needed). Admins could change those values if they like. From my consulting days though, I haven't seen many admins too eager to muck with application meta-data :-).
>
> I do understand that increasing deployment descriptor flexibility could make administration tools development harder. It's just that I think it is the right trade-off to make. On the other hand, it wouldn't be so bad to have the run-time administration toolsjust look like XML property editors would it?
>
> I am not sure about the configuration API part. Do we really need it since reading XML is so trivial? There really is no practical reason you could not use a CDI/EJB SPI to do any kind of run-time configuration change (proprietary or otherwise)? That's what we do for CDI right now anyway -- we parse/read the custom beans.xml and pass on the meta-data via the CDI portable extensions SPI to the CDI implementation (that's right now our own implementation).
>
> Cheers,
> Reza
>
>
> On 6/14/2011 4:15 AM, Kristoffer Sjögren wrote:
>> Hi
>>
>> Very interesting. Do you see a possibility for runtime administration of configuration using same meta model?
>>
>> Closed source products may not ship the build environment to customers as they treat xml descriptors as source code, sealing archives with a version, package signature before released to the package management system. This kind of product development would benefit from a programatic SPI that enable the system administrator to discover and override application configuration at runtime.
>>
>> Potentially resulting in more productive development release cycle with decreased turn-around times since no repackaging+deploy would be needed.
>>
>> Would Java EE Product Providers expose proprietary server configuration using same SPI possibly, enabling configuration management unification for server and application?
>>
>> I believe configuration is an important topic and would be more than willing to collaborate on this work.
>>
>> Cheers,
>> -Kristoffer
>>
>> ________________________________
>>
>> From: Reza Rahman [mailto:reza_rahman_at_lycos.com]
>> Sent: den 10 juni 2011 19:51
>> To: jsr342-experts_at_javaee-spec.java.net
>> Subject: [jsr342-experts] Re: Configuration
>>
>>
>> Antonio,
>>
>> Sorry for the late reply -- I have been out of town this week and in meetings. I'll contribute details as soon as I can...
>>
>> Your initial thoughts look about right. In our case, we allow the usage of EJB meta-data outside of EJB in CDI managed beans, also revamp the web.xml, application.xml, etc to be more compact/type-safe/flexible and allow for fragments/meta-data mixing for all XML. In short, we see it is an overhaul/modernization for Java EE XML configuration.
>>
>> The big problem in making our solution completely portable is the lack of a Servlet, EJB, etc, meta-data SPI (as Pete alluded to as an issue). It's also the case that Seam Config solves 80%-90% of the problems...
>>
>> Cheers,
>> Reza
>>
>>
>> On 6/10/2011 8:17 AM, Antonio Goncalves wrote:
>>
>> Hi all,
>>
>> I'm not a configuration expert but, as a developer and deployer I feel something more is needed. I started to put some ideas into this email and then I switched to my blog. So here are my humble thoughts on the topic :
>>
>> http://agoncal.wordpress.com/2011/06/10/debate-and-what-about-configuration-in-java-ee-7/
>>
>> Reza and al, we can use this as a starting point to exchange an what configuration could look like
>>
>> Antonio
>>
>>
>> On Tue, Jun 7, 2011 at 02:01, Reza Rahman<reza_rahman_at_lycos.com> wrote:
>>
>>
>> Antonio,
>>
>> FYI, we do have some of these details hashed out internally. If it saves you time, I am happy to share those details.
>>
>> As I said, this has been on our radar, I'm just not entirely sure about priorities for Java EE 7 vs Java EE 8, etc.
>>
>> Cheers,
>> Reza
>>
>>
>>
>> On 6/6/2011 6:01 PM, Linda DeMichiel wrote:
>>
>>
>> Antonio,
>>
>> Sounds interesting, tell us more....
>>
>> thanks,
>>
>> -Linda
>>
>>
>> On 6/2/2011 10:47 AM, Antonio Goncalves wrote:
>>
>>
>> I would like to share some thoughts with you.
>>
>> I've used in the past Spring Config and latelly I've attended a conference that talked about Seam Config. Clearly I can
>> see the benefit of having easy configuration on the entire platform. At the moment we have ejb-jar.xml and environment
>> entries to configure our EJBs. We can also use the web.xml to pass some parameters to our servlets and bits and pieces
>> in the application.xml file.
>>
>> Why not having a seperate spec that takes inspiration from Seam Config, Spring Config and so on to be able to configure
>> the entire platform (a CDI bean as well as an EJB...). Configuration will also be used for Paas purposes of course.
>>
>> Configuration is an important topic and developers never know where to put it : property files, XML, database, JNDI. Why
>> not having a spec that specifies how configuration should work (I really like the Seam Config approach) and each spec
>> could then use it to specify how to configure a specific component, as well as batch processing or Paas/Saas
>> configuration...
>>
>> Again, my 2 cents
>>
>> --
>> Antonio Goncalves
>> Software architect and Java Champion
>>
>> Web site<http://www.antoniogoncalves.org <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 <http://www.parisjug.org/> >
>>
>>
>>
>>
>> -----
>>
>> No virus found in this message.
>> Checked by AVG - www.avg.com <http://www.avg.com/>
>>
>> Version: 10.0.1375 / Virus Database: 1511/3685 - Release Date: 06/06/11
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Antonio Goncalves
>> Software architect and Java Champion
>>
>> Web site<http://www.antoniogoncalves.org <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 <http://www.parisjug.org/> >
>>
>> ________________________________
>>
>>
>> No virus found in this message.
>> Checked by AVG - www.avg.com <http://www.avg.com/>
>> Version: 10.0.1382 / Virus Database: 1511/3682 - Release Date: 06/05/11
>>
>>
>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com <http://www.avg.com/>
>> Version: 10.0.1382 / Virus Database: 1513/3703 - Release Date: 06/14/11
>>
>>
>>
>
--
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/>