Tang Yong wrote on 12/10/13 01:15:
> A litter different opinion from me is that, if GF offered the option of "trun
> off", once the user selects turning off EJB container and causes the app can
> not work normally, then, I think that such behavior is on his own responsibility.
I understand that point of view, but the Java compatibility rules don't allow
that approach.
>> The only way to support subsets of the Java EE specification is to produce
>> separate products that don't carry the Java EE brand, but that still do
>> conform to all the Java specification requirements for the Java technologies
>> they do include. This is the "distributions" approach I suggested earlier.
> Just like WebProfile.
>
> Bill, whether you think of the following or not?
>
> Whether WebProfile or FullProfile is all defined based on the view of JavaEE
> Spec, maybe should have more profiles...
>
> Well, for a java application server, its constitution should be made up of the
> three parts(my immatural thinking),
>
> 1. JavaEE Spec Implementation(core value)
> 2. itself's Infrastructure(core value + add-on value)
>
> 1) core parts in order to support 1
> 2) add-on parts(eg. Cluster Support, Monitoring, Logging...)
>
> 3. extension capability(add-on value)
>
> Eg. GlassFish OSGi-JavaEE, integration with the third part FW,...
>
> Then, for 2.2 and 3, whether should also have some profiles similar to
> WebProfile and FullProfile?
We've considered defining more profiles, but there are tradeoffs.
If we had (e.g.) 17 profiles, no one would be able to keep them straight
and the brand "Java EE" would become meaningless.
So where do we draw the line? How many profiles is too many? I think we
could probably handle one or two more, max. That means any new profiles
have to be really important, and have to have a clearly distinguished use
separate from the Web Profile. A new profile that's just the Web Profile
plus one or two APIs isn't different enough.
It's always possible to define new APIs that are add-ons to Java EE, and
aren't covered by the Java EE brand. We already have many of those, such
as the Portlet API.
And of course it's possible to create a Web Profile product or distribution
that includes more than the minimum required by the Web Profile spec, as
long as the additions also meet the Java compatibility requirements.
> I agree with you that by "distributions" approach, this must be done. However,
> just like Roman said, I think this approach is a fixed approach. From an user,I
> think this approach is less convenient than having some way to switch these
> profiles dynamiclly.
The thing that's the most convenient for users is to never have to think
about these issues and to just have the product work well in all cases.
> An user who originally uses Tomcat starts to migrate into GlassFish distro with
> Servlet. Some day, he found that he also needs EJB to deploy another app. Then,
> how he will do? Maybe he will swich into GlassFish distro with Servlet and EJB.
> Then, the cost of switching is that he will re-deploy previous app. If the
> previous app is mission-critical, ...
It's supposed to be possible to upgrade from the GlassFish Web Profile
distribution to the GlassFish full Java EE distribution "in place",
without redeploying any apps.
> I agree with you the point "why", and I needs to give more powerful proofs and
> spend more time. Indeedly, such proofs will be more useful for GF, whether
> finally GF team will agree my solution.
It's always possible that there are cases where the cost of doing it
"right" so that it's transparent to the user is huge, but the cost of
just adding the ability to turn off the subsystem is small. Some people
might even agree with you that the cost/benefit tradeoff favors the easy
solution. Still, we're constrained by the Java compatibility requirements,
and some of these easy solutions can't be considered. At least, not without
changes to the Java EE specifications.