Perfectly right, that's why large users such as my current client need
tools like Multiconf/Kokki, or others using Puppet/Chef and related
libraries for configuration management.
Frameworks like Play! use Scala, and I heard a rumor last night
NightHacking with Stephen Chin, that Spring 4 plans to use Groovy in
similar ways.
Not sure, to what extent EE 8 may cover what they all do, but if at least
part of the "Cloud" or Multi-tenanancy promise was met, it has to cover a
few.
Werner
Am 01.02.2013 11:23 schrieb "Antonio Goncalves" <antonio.goncalves_at_gmail.com
>:
> Hi all,
>
> Let's face it, configuration in Java EE is broken. Most of my customers
> package their application in an ear and they have to use the same ear (i.e.
> checksum) in all environments (test, dev, integration, production...),
> meaning that all the configuration has to be externalize (web.xml,
> persistence.xml...). Most of them use Spring Config or some home-made
> tricky stuff or application-server specific configuration... but not JNDI
> for example.
>
> So, to be honest, until we have a decent configuration API, I would just
> leave each spec to do its own stuff, so I would go fo 1. (The current Batch
> API approach of leaving all the details up to the implementation).
>
> I know that Mike Keith was brainstorming on having a Java EE Configuration
> spec across all EE. Something that could use simple XML centralize file
> instead of just JNDI (makes no sense to have JNDI sticking around for a
> Batch spec that can live in Java SE). I wonder where this idea is at the
> moment (I'll contact him).
>
> My 2 cents
> Antonio
>
>
> On Fri, Jan 25, 2013 at 11:55 PM, Bill Shannon <bill.shannon_at_oracle.com>wrote:
>
>> I'd like the advice of this group on an issue with the Batch API.
>>
>> The Batch API specifies how applications can define job steps.
>> Job steps are combined into a batch job using an XML file that
>> is effectively a batch "job control language" script. The application
>> starts a batch job by supplying this batch JCL script to the Batch API.
>>
>> There are at least two models for how an application might deal with
>> these batch scripts:
>>
>> 1. The batch scripts are an integral part of the application. They're
>> supplied with the application and controlled by the application.
>>
>> 2. The application supplies only the batch job steps, expecting that
>> an external agent (usually an administrator) constructs a batch
>> script using these jobs. The application controls the execution
>> of the script, but not the content of the script.
>>
>> In the first case it seems obvious that the batch script XML files
>> should be packaged with the application and the application should
>> refer to them by using a resource name in the application (possibly
>> a name valid for Class.getResource(), possibly a name of a file in
>> a fixed location in the application) when using the Batch API.
>>
>> In the second case, the application needs to refer to these scripts,
>> but the scripts aren't packaged with the application, so it's not
>> clear how the application should refer to them. The Batch API
>> specifies this case very loosely. The Batch implementation is
>> free to interpret the names given to it in any way it desires,
>> locating these batch scripts wherever and however it wants. The
>> names used with case #1 above are portable, assuming they
>> haven't been overridden in some Batch implementation-specific way.
>>
>> Normally, when a Java EE application uses a resource that's external
>> to the application and can be configured by an administrator, we
>> expect the application to declare this external dependency using
>> (e.g.) a @Resource annotation. This creates information known to
>> the deployment process that alerts the deployer that an external
>> resource is being referenced and must be supplied.
>>
>> The Batch API provides no way to expose to the deployment process
>> an application's dependency on an externally supplied batch script.
>> An application might fail at runtime because the administrator didn't
>> supply the expected script with the expected name.
>>
>> I've proposed that the Batch API make use of @Resource to handle
>> this case, similarly to how we've handled other cases, but they've
>> rejected that proposal. They believe the loosely defined approach
>> that leaves all the details up to the implementation is sufficient.
>>
>> Which approach do you prefer?
>>
>> 1. The current Batch API approach of leaving all the details
>> up to the implementation.
>>
>> 2. Find a way (e.g., @Resource) to expose these application dependencies
>> on an external batch script to the deployment process.
>>
>> Let me know what you think.
>>
>
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site <http://www.antoniogoncalves.org> | Twitter<http://twitter.com/agoncal>|
> LinkedIn <http://www.linkedin.com/in/agoncal> | Paris JUG<http://www.parisjug.org> |
> Devoxx France <http://www.devoxx.fr>
>