Jason,
Yep -- we did the same :-).
Cheers,
Reza
On 6/16/2011 9:57 PM, Jason T. Greene wrote:
> We pruned those two, since they are significantly out of date (did not
> handle annotations), and had little interest (ask an EE developer
> about these and you get silence followed by blinks). IMO If we did
> want to introduce a management / deployment spec, it should be a fresh
> take from scratch.
>
> On 6/16/11 7:44 PM, Reza Rahman wrote:
>> Bill,
>>
>> For what it is worth, I agree with you that some of this looks like it
>> is putting the horse before the cart :-). I'd like to see the existing
>> developer APIs improve first and perhaps a basic outline of resource
>> layer multi-tenancy before adding too many new APIs geared towards PaaS
>> vendors. I think in the interim, JSR-88 and JSR-77 are the way go to
>> even if they are less than ideal, maybe augmented by vendor-specific
>> server APIs.
>>
>> Cheers,
>> Reza
>>
>>
>> On 6/16/2011 5:54 PM, Bill Shannon wrote:
>>> Jevgeni Kabanov wrote on 06/15/2011 11:21 AM:
>>>> I'm still catching up with the reading and some research, but here
>>>> are in no
>>>> particular order some things I'd ideally want to see from this:
>>>> 1. App servers should abandon the notion that they are only managed
>>>> by their own
>>>> consoles. Their should be a generic way to start/stop/deploy/etc. I
>>>> haven't
>>>> looked into JSR-77 yet, maybe that's the one. But I'd propose to
>>>> standardize on
>>>> the command line instead of the Java API, which is hugely cumbersome
>>>> in a
>>>> heterogenous environment the apps commonly live in.
>>>
>>> We tried to standardize some of this in JSR-77 and JSR-88. They have
>>> not been
>>> a success. While we'd like to do more here, it's a tremendous amount of
>>> effort, and not something we're planning to do for EE 7.
>>>
>>>> 2. Also, please let me pass parameters to the JVM, e.g. managing
>>>> Glassfish
>>>> through scripts is impossible. Being able to tune the app server and
>>>> its JVM
>>>> centrally is a must for the cloud.
>>>
>>> To make standardizing this really useful, we'd want standardized JVM
>>> parameters. There are none. A standardized way to pass non-standard
>>> parameters isn't as interesting, and encourages non-portable
>>> applications.
>>>
>>> Passing JVM parameters with an application when you deploy the
>>> application
>>> to the cloud assumes a certain deployment model (one application per
>>> JVM)
>>> that we're unlikely to require.
>>>
>>> If people think there's value in standardizing a way to pass
>>> non-standard
>>> JVM parameters, with no requirement that the application server do
>>> anything
>>> with them, I suppose we could consider that.
>>>
>>> Oh, and you *can* set JVM parameters for GlassFish using a script so
>>> I'm
>>> not sure what your issue is there.
>>>
>>>> 3. REST API layered over JMX API for deployment, configuration
>>>> management and
>>>> app management. Can't stress that enough.
>>>
>>> JSR-77 is an EJB API for management. It gave us a standardized protocol
>>> for management that wasn't Java specific. Still, JMX proved more
>>> popular.
>>> There is still no cross-platform standardized protocol for management
>>> using JMX. We've been asking for years for a Web Services / SOAP
>>> mapping
>>> for JMX. Today, using a REST-based protocol might be a better choice.
>>>
>>> Again, this is a ton of work that we won't be able to do for EE 7.
>>>
>>>> 4. A jvm-instance-per-app model (better called process per app model)
>>>> for app
>>>> servers as an alternative to the current classloader per app model
>>>> and way to
>>>> manage those apps. At least as an option to be standardized on down
>>>> the line.
>>>
>>> I don't think we'll standardize this, but this is definitely one
>>> implementation
>>> strategy that we intend to allow.
>>>
>>>> 5. Session API/SPI (probably through the same JMX/REST combination)
>>>> that allows
>>>> to migrate data without relying on the app server and also keep
>>>> session in the
>>>> super-effective datagrids/caches.
>>>
>>> I'm not sure I understand your use case here.
>>>
>>> Our focus has been on APIs that applications need. Applications
>>> shouldn't
>>> be migrating data.
>>>
>>> In some cases we've provided SPIs that allow servers to be extended, or
>>> allow multiple implementations of a facility to be provided
>>> independently
>>> of a server vendor. An SPI to allow pluggability of session state
>>> storage and migration mechanisms might be interesting.
>>>
>>>> 6. Oh, and an API for provisioning app servers, though that's
>>>> probably too much
>>>> to expect :)
>>>>
>>>> Generally I think the main thing PaaS support requires is to expose a
>>>> bunch of
>>>> scripting APIs and make the app server consoles to be consumers of
>>>> the APIs the
>>>> underlying server exposes. This will create a great ecosystem to
>>>> complement the
>>>> existing tooling instead of requiring app servers to catch up one by
>>>> one.
>>>
>>> That's not our current plan.
>>>
>>> We're trying to enable application server vendors to provide a full
>>> cloud
>>> platform.
>>>
>>> We're not trying to turn application servers into a component that
>>> someone
>>> else would use to construct a full cloud platform.
>>>
>>>
>>> -----
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 10.0.1382 / Virus Database: 1513/3707 - Release Date: 06/16/11
>>>
>>>
>>
>
>