Resin EE Web Profile strategy

In our view, one of the most important changes in EJB 3.1 is the redefinition of EJBs as simple managed bean POJOs with additional services. We have taken this realignment to the logical next step by allowing developers to use EJB annotations in CanDI managed beans in addition to EJBs including the @TransactionAttribute, @Schedule, @Asynchronous, @RolesAllowed, @PermitAll, @DenyAll, @RunAs, @Lock , @Startup and @Remote. Here are a few examples of this capability

This paragraph caught my eye. Is not possible to mix EJB and CDI annotations with containers implementing Weld?

Alex wrote on Feb 18, 2010 03:59:
In our view, one of the most important changes in EJB 3.1 is the redefinition of EJBs as simple managed bean POJOs with additional services. We have taken this realignment to the logical next step by allowing developers to use EJB annotations in CanDI managed beans in addition to EJBs including the @TransactionAttribute, @Schedule, @Asynchronous, @RolesAllowed, @PermitAll, @DenyAll, @RunAs, @Lock , @Startup and @Remote. Here are a few examples of this capability This paragraph caught my eye. Is not possible to mix EJB and CDI annotations with containers implementing Weld?

Yes, with all CDI containers you can use CDI services in EJBs and managed beans. For example

@Stateless
@TransactionAttribute(REQUIRES_NEW)
class DvdRentalManager {

   @Inject RentalCostCalculator calc;

   public void hireOutDvd(Dvd dvd) {
      ...
   }

   public void returnDvd(@Obsevers @Returned Dvd dvd) {
      ...
   }
}

However, what Resin allows you to do is omit the @Stateless annotation, and use annotations like @RunAs on a managed bean.

Ok. Is this notion of ubiquitous EJB services in Resin's implementation ground breaking? It seems nice and straightforwad to be able to use one set of transaction and security annotations throughout instead of one set for EJB managed and another for CDI managed. Or is this just simple convenience by allowing the omission of @Stateless, etc.?

Ok. Is this notion of ubiquitous EJB services in Resin's implementation ground breaking?

Well, it's something that plenty of folks, myself included, have advocated for a long time. But yes, Resin is the first server to actually get it implemented. Kudos.

Or is this just simple convenience by allowing the omission of @Stateless, etc.?

Well, that's also true :-)

Note Profiles do not stop a vendor from adding APIs and features as they see fit. As we will discuss shortly, we have chosen to add a very small number of Java EE APIs and features on top of the Web Profile. Specifically, we see value in adding support for scheduling, asynchronous processing, messaging, message driven beans and Hessian based remoting.

hmmm. vendor lockin? the inevitable dilemma, should I or should I not use non-standard (i.e. APIs not in the RI/spec) APIs from this particular vendor application server/product? Aren't they essentially extending the EE6 web profile to almost EE6 full profile or similar? Then why not implement the full profile as well?