Antonio,
We actually only add JMS on top of the web profile and support some EJB
features outside of EJB Lite. We got the JMS certification in addition
to the Web Profile certification. We also internally tested the EJB
features that are outside of EJB Lite because those tests are available
in the CTS (although we do not make that claim to customers because we
cannot/should not). In practice, I think keeping things open/flexible
adds a lot of value to the idea of EJB Lite/Java EE Web Profile and we
should keep it that way until EJB Lite matures a bit or the EJB spec
itself sheds some of the legacy like EJB 2 backwards compatibility and
CORBA that adds some needless baggage for implementers of a lightweight
option.
Cheers,
Reza
On 7/12/2011 3:40 AM, Antonio Goncalves wrote:
>
>
> On Tue, Jul 12, 2011 at 04:02, Marina Vatkina
> <marina.vatkina_at_oracle.com <mailto:marina.vatkina_at_oracle.com>> wrote:
>
> Hi Antonio,
>
> Antonio Goncalves wrote:
>
> Hi
>
>
> On Wed, Jul 6, 2011 at 01:02, Marina Vatkina
> <marina.vatkina_at_oracle.com <mailto:marina.vatkina_at_oracle.com>
> <mailto:marina.vatkina_at_oracle.com
> <mailto:marina.vatkina_at_oracle.com>>> wrote:
>
> Dear Experts,
>
> Before we go any further on the discussions of the spec
> improvements, we need to close on several issues with the
> current
> version:
>
> 1. Vote on the optionality of the Entity Beans and JAX-RPC
> based
> Web Service Endpoints (and the split of the spec into 2
> parts, but
> the split is the secondary issue). I have only 3 votes
> (positive)
> so far.
>
>
> You have my +1
>
>
> thanks.
>
>
>
> 2. Close on the items marked by Linda as XXX in the drafts.
>
>
> I've been following the XXX marks threads and agreed on most
> of them
>
>
> Which ones you do not agree on?
>
>
>
> 3. Define *deterministic* rules in the EJB spec about EJB
> Lite vs.
> EJB Full list of features in regards to the EJB support in
> a Web
> Profile container. In addition to be very flexible (contrary to
> the regular Java EE approach, and the expectations of the EJB
> TCK), the current wording in the spec does not make it clear a)
> what is expected and what is not in the Web Profile, and b)
> if we
> keep it flexible, how a user (at deployment and/or runtime) can
> determine if a specific feature outside EJB Lite is
> available/supported.
>
>
> This is a bit tricky. Let me go a bit further. Let's say (and
> I emphasis my 'let's day') PAAS/SAAS features in Java EE 7 are
> put into a seperate profile (not into EE 7 itself), this would
> mean that we would have 3 different flavours of EJBs : EJB
> Full, EJB Lite and EJB Cloud (BTW, EJB Full doesn't seam a
> good name to me). What are the differences between a EJB Full
> vs EJB Lite vs EJB Cloud ? How to make it clear to the reader
> and implementor what to use when ?
>
> Two posisble approaches :
> * we define everything (all the services) in the EJB spec
> and in
> the same spec have a chapter defining what services apply
> to EJB
> Full, EJB Lite, EJB Cloud
> * we define everything (all the services) in the EJB spec. In
> fact, we could even rename it to Enterprise Java Services
> (instead of Enterprise Java Bean). Then, in the EE spec we
> define what services are available in EE, in the Web Profil
> spec we define what services are available in the Web
> Profile,
> and in the Cloud Profile spec we define what services are
> available in the Cloud Profile
>
> I have a preference with the second approach
>
>
> EJB spec can't change to be something completely different than
> what it is today and services described in other specs can't
> become part of the EJB spec 3.2 (at least for backward
> compatibility). What can be done, is extract (or at least start on
> that path) common services and either create separate docs or
> create a common Java EE services doc (under the Platform spec or
> under the EJB spec - most probably the platform EG needs to decide
> on that).
>
> That said, it will still leave a question of if say, services A
> and B that are not required to be supported in the EJB Lite (or
> Web Profile), can a provider Z still support only A in their EJB
> Lite implementation? If the answer is yes, we have a problem.
> Besides explaining how to detect that, we need to describe how can
> it be tested that such service behaves correctly as expected in
> the EJB Full set? Current CTS suite is not available in a la carte
> mode, and it's not an easy task to create one out of existing
> tests (where the assumption always was that you can test either
> all or none).
>
>
> Correct me if I'm wrong, but that's what happening with JBoss 6 (and
> Resin I guess). Both implement the Web Profile and they both add
> JAX-RS (which is not Web Profile) and JBoss 6 goes even further by
> adding JMS (and JAX-WS I think). The EE 6 EG brought that at the time.
> The question was : "if there is a RESTService in your war file and you
> deploy it to a Web Profile app server, should the deployment fail?".
> The answer was clearly no. If service A and B are not required in EJB
> Lite, these services shouldn't be tested in the CTS (and the provider
> can still add them).
>
> But that being said, I do not know how the CTS suite is made and how
> it works.
>
> Antonio
>
>
> Best,
> -marina
>
>
> Antonio
>
>
>
> The same applies to the Embeddable EJB Container.
>
> Thank you,
> -marina
>
>
>
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | Blog
> <http://feeds.feedburner.com/AntonioGoncalves> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Paris JUG
> <http://www.parisjug.org>
>
>
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | Blog
> <http://feeds.feedburner.com/AntonioGoncalves> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Paris JUG <http://www.parisjug.org>
> ------------------------------------------------------------------------
>
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 10.0.1388 / Virus Database: 1516/3759 - Release Date: 07/11/11
>