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 <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<http://www.antoniogoncalves.org>>
>>> | Twitter <http://twitter.com/agoncal> | Blog <
>>> http://feeds.feedburner.com/**AntonioGoncalves<http://feeds.feedburner.com/AntonioGoncalves>>
>>> | LinkedIn <http://www.linkedin.com/in/**agoncal<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 <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>