Antonio,
Interceptors is currently a separate spec (separate document, separate api jar, separate version number) from EJB. The only places it currently links to EJB is (a) no separate TCK and (b) controlled by the EJB EG.
HTH
On 8 Jul 2011, at 08:58, Antonio Goncalves wrote:
> One problem at the very beginning of JPA 1.0 was that it was bundled with EJB 3.0. People first thought you could only use JPA with EJBs. I think it would make it clearer to have a separate spec for Interceptors, a separate spec for transaction management... and so on. Maybe the future of Java EE is to have 100 short specifications rather than 30 fat ones.
>
> But again, I don't see this as a very high priority for EE 7. It's more important to extract parts of the spec (interceptors, tx mgmt...) and ship it with EJB.
>
> My 2 cents
>
> Antonio
>
> On Fri, Jul 8, 2011 at 00:35, Reza Rahman <reza_rahman_at_lycos.com> wrote:
> Marina,
>
> I think eventually it does make sense for Interceptors to be a separate JSR/EG, but I don't see it as a high priority issue at the moment. Maybe Pete, et al feel differently and it would make things easier from a CDI EG perspective?
>
> Cheers,
> Reza
>
>
>
> On 7/7/2011 6:04 PM, Marina Vatkina wrote:
> Managed bean spec says "A Managed Bean may use interceptors as defined in the Interceptor specification.". Isn't it enough? If anybody feels that the Interceptors spec should be moved out of the EJB JSR, it needs to be addressed at the Platform EG.
>
> -marina
>
> Antonio Goncalves wrote:
> Agree that lifecycle callback methods should be exposed as business methods. But Shouldn't this (@PostConstruct & @PreDestroy) be defined in the ManagedBean spec ?
> On Thu, Jul 7, 2011 at 02:10, Marina Vatkina <marina.vatkina_at_oracle.com <mailto:marina.vatkina_at_oracle.com>> wrote:
>
> Should we add a word of caution for the lifecycle callback methods
> to be exposed as business methods?
>
> thanks,
> -marina
>
>
> Carlo de Wolf wrote:
>
> (page 86)
>
> Yes. The lifecycle annotation is only an indicator which
> method must be called by the container at the appropriate
> event. The method can equally be called via a view.
>
> Carlo
>
> On 07/06/2011 01:02 AM, Marina Vatkina 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.
>
> 2. Close on the items marked by Linda as XXX in the drafts.
>
> 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.
>
> 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>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1388 / Virus Database: 1516/3749 - Release Date: 07/07/11
>
>
>
>
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site | Twitter | Blog | LinkedIn | Paris JUG