Jevgeni Kabanov wrote on 09/29/2011 01:48 AM:
> From the perspective of our customers Cloud is more about automated deployment,
> provisioning and configuration management than anything else. If we could at
> least get the resource definitions into Java EE 7, that'd be hugely helpful. I'm
> much less concerned about multi-tenancy, as I think that it's not as easy to
> standardize and will probably end up too limited anyway. And of course, since
> we're talking about automation, I'd still love to see some Configuration API,
> that I mentioned a couple of time before, so that apps and containers could both
> be configured and deployed automatically.
I'm still trying to understand what you need for apps that's not provided
by the existing JNDI environment entries support. Is it just an ease of use
issue? Or is there some key capability missing?
As for configuring containers, I think there's very little hope of getting
agreement among all the vendors.
> I understand that Bill's worry that I'm proposing to lift the job of container
> to the app, but the reality is that deployments always operate in the context of
> legacy services, apps and data. Therefore, having flexible and easily scriptable
> deployment and configuration is key for customer satisfaction. Even a
> recommendation as per scripting and API type and location (Java, JMX, REST)
> would be hugely helpful if majority of container vendors would follow them.
Having everyone agree to provide REST support for configuration is of little
value if they don't all support the same configuration objects. The goal
needs to be to enable writing portable apps.
> As for modularity -- just as a thought experiment, isn't it possible to split
> the spec into conceptual modules independent of any specific module system to
> make our job easier down the line? I understand that the basic principles of the
> Java SE 8 module system is quite well laid out? Alternatively, it'd be possible
> to ship two versions of the spec (again, just thinking out loud), one based on
> Java SE 7 and the other based on Java SE 7 + modules. This would allow to both
> have a smooth transition path and to accommodate early adopters to test out the
> spec. This means more work for us, but not necessarily much more than doing the
> modules anyway.
Yes, it's possible, and those are the sorts of things we were exploring with
the Java SE group. But we needed *them* to do this work to ensure that the
resulting specs were aligned with, and implemented by, the module system
in Java SE 8. Unfortunately, they're not going to be able to do this.