Jason,
Yes, I am aware of the JSR 77 and 88 situation :-).
Cheers,
Reza
On 6/16/2011 10:50 PM, Jason T. Greene wrote:
> No I mean that we the EG (including you) marked JSR-88 as pruned in
> EE6 (will no longer be required for vendors in EE7 provided we don't
> change our minds). I thought we did the same for 77, but apparently we
> did not.
>
> On 6/16/11 9:32 PM, Reza Rahman wrote:
>> 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
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>