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> | Twitter<http://twitter.com/agoncal> | Blog
>> <http://feeds.feedburner.com/AntonioGoncalves> | LinkedIn<http://www.linkedin.com/in/agoncal> | Paris JUG
>> <http://www.parisjug.org>
>>
>>
>>
>>
>> -----
>>
>> No virus found in this message.
>> Checked by AVG - 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> | Twitter<http://twitter.com/agoncal> | Blog<http://feeds.feedburner.com/AntonioGoncalves> | LinkedIn<http://www.linkedin.com/in/agoncal> | Paris JUG<http://www.parisjug.org>
>>
>> ________________________________
>>
>>
>> No virus found in this message.
>> Checked by AVG - 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
>> Version: 10.0.1382 / Virus Database: 1513/3703 - Release Date: 06/14/11
>>
>>
>>
>