WebBeans in non web environment

[thejavafreak]

Since WebBeans claims to be a standard for dependency injection, would we be able to use WebBeans in non-web environment if we are looking for the dependency injection only?

Regards

[gavin.king]

Yes. The spec says that in the SE environment, the EE services can be provided by am embeddable EJB Lite implementation.

[thejavafreak]

Gavin King wrote on Jan 04, 2009 01:08:


Yes. The spec says that in the SE environment, the EE services can be provided by am embeddable EJB Lite implementation.

Why would I need an embeddable EJB when I will only be using the WebBeans for injection? Doesn't that sound a bit too bloated?

[gavin.king]

Not to me, no. I can't imagine what the usefulness of dependency injection would be without support for things like JDBC datasources, transaction demarcation, JPA, etc. If you look at Spring for example, it also has all this functionanality. Is Spring therefore bloated?

[kks_krishna]

He may be asking only the IOC container to inject the object. You can use google guice as IOC right? If i am wrong correct me.

[thejavafreak]

Krishna Srinivasan wrote on Jan 07, 2009 12:29:


He may be asking only the IOC container to inject the object. You can use google guice as IOC right? If i am wrong correct me.

Yes Krishna. Guice or Pico would be a good example for this. :-)

[thejavafreak]

Gavin King wrote on Jan 05, 2009 06:52:


Not to me, no. I can't imagine what the usefulness of dependency injection would be without support for things like JDBC datasources, transaction demarcation, JPA, etc. If you look at Spring for example, it also has all this functionanality. Is Spring therefore bloated?

But Gavin, Spring won't force me to deploy the apps in a JEE environment. I can just use a servlet container. Infact I can use Spring in a non web environment. As for the JDBC datasource Spring can use Commons-DBCP or c3p0. What's the whole point using WebBeans in a full-blown appserver if I can use a servlet container?

[gavin.king]

Joshua Partogi wrote on Jan 08, 2009 02:28:

Gavin King wrote on Jan 05, 2009 06:52:


Not to me, no. I can't imagine what the usefulness of dependency injection would be without support for things like JDBC datasources, transaction demarcation, JPA, etc. If you look at Spring for example, it also has all this functionanality. Is Spring therefore bloated?

But Gavin, Spring won't force me to deploy the apps in a JEE environment. I can just use a servlet container. Infact I can use Spring in a non web environment. As for the JDBC datasource Spring can use Commons-DBCP or c3p0. What's the whole point using WebBeans in a full-blown appserver if I can use a servlet container?

Perhaps I'm being dense but I simply don't understand the difference here. Web Beans doesn't require an EE server in the traditional sense, just an EE6 web profile, or embeddable EJB lite.

If I use Spring in Tomcat, I have a servlet engine, Spring's dependency injection engine, Spring interceptors, Spring's proprietary transaction management/demarcation stuff, DBCP or c3p0, Hibernate, Spring's persistence context management stuff.

If I use the an EE 6 Web Profile, I have a servlet engine, web beans dependency injection, interceptors, EJB for transaction demarcation and persistence context management, a JDBC datasource, JPA.

i.e. exactly the same list of stuff! But standards-compliant.

Joshua, have you actually read up about the EE web profile and EJB Lite? It sounds like you're still stuck in thinking that EE implies the full list of technologies that are required in EE5. It doesn't.

[gavin.king]

The precise list of technologies for the web profile is still under discussion, but it looks like will be something like:

• Servlet 3.0


• JSP 2.2


• EL 1.2


• JSTL 1.2


• JSF 2.0


• JAX-RS 1.1

• JSR-45 Debugging Support for Other Languages

• JSR-250


• EJB Lite 3.1


• Web Beans 1.0


• JTA 1.1


• JPA 2.0

where EJB Lite is defined as:

The EJB Lite API is composed of the following subset of the EJB API :

• Stateless, Stateful, and Singleton Session Bean components


• Local and no-interface view only


• Synchronous method invocations only


• Container-managed transactions / Bean-managed transactions


• Declarative and programmatic Security


• Interceptors


• Deployment Descriptor support (ejb-jar.xml)

An EJB Lite implementation is also required to support Java Persistence 2.0.

If anything, this is a smaller footprint than Tomcat+Spring today.

Let me turn the question around: if you're a Web Beans user, why on earth would you not want one of the things in that list of technologies?

(OK, some people may decide to use proprietary web frameworks instead of JSF and JAX-RS, but nothing stops them.)

[peteroyle.howardmoon.hitcity.com.au]

Gavin King wrote on Jan 08, 2009 03:53:

Let me turn the question around: if you're a Web Beans user, why on earth would you not want one of the things in that list of technologies?

Perhaps if I was implementing one of the above technologies, assuming I could use a Web Beans platform that only included Java SE stuff.

Gavin King wrote on Jan 01, 2009 14:33:

IN THREAD: Resin supports Web Beans?

Yes, Caucho have their own Web Beans implementation, which if I understand correctly is the basis for their server (it serves a similar role to what the microcontainer serves in JBoss5).

I could be very wrong here but: If they used it as their microcontainer then I'd imagine that they made heavy use of the pure SE dependency injection, interceptor, delegator and event frameworks in order to build a platform into which they then integrated their existing EE stuff to end up with a full Web Beans stack.

Disclaimer: I have no irrational fear of the letters E, J and B, nor any phychological issues that I'm aware of :P.

[peteroyle.howardmoon.hitcity.com.au]

In other words, I think what people are seeing is the future potential for JSR-299 to be split into a 2 parts:

Part 1: is just those parts of the current JSR-299 which raise the semantic level of java and allow much easier integration of stuff with other stuff. Things like typesafe DI, interceptors, decorators, deployment types, the (synchronous) event model. Maybe contexts and/or Unified EL?

Part 2: is Web Beans, with a dependency on Part 1. It will use part 1 to integrate all the Java EE stuff and also add the EE-specific extensions like session bean support, servlet integration, JPA, JMS endpoints, asynchronous event model etc.

[gavin.king]

Possibly the disconnect comes from what people mean by the term Web Beans. ;-)

When I'm using the term, I mean the set of requirements an implementation has to fulfill in order to certify compliance with the JSR-299 TCK and use the brand "Web Beans" in its product marketing.

Now, that doesn't constrain an actual implementation of JSR-299 from executing in some other environment without support for certain EE technologies. There's nothing in the specification to stop you from doing that. Hell, we even test the RI like that! However, that's not "Web Beans" as defined by the specification, it can't be tested by the TCK and it can't be certified compatible with the specification or other implementation of the specification.

Would it be possible for the 299 specification to define what an implementation of JSR-299 should do in an environment that doesn't support the other EE technologies? Sure, anything's possible. But is there any value in doing that from the point of view of a user who is concerned about portability of their application between different vendors? Well, I don't see how there could be...

[gavin.king]

Again, if you look at the definitions, embeddable EJB lite + Web Beans is really not very different from your Part 1.

It has interceptors/decorators, deployment types, synchronous events, 2 of the 4 contexts, datasources, JPA and declarative transaction demarcation.

It doesn't have servlet integration, presentation, JMS, asynchronicity, session/conversation contexts or EL.

Are you really going to get that upset by the fact that it has JPA in there?

[hajdi]

Gavin King wrote on Jan 08, 2009 18:06:


Again, if you look at the definitions, embeddable EJB lite + Web Beans is really not very different from your Part 1.

Not very different still means different though. :-)

It has interceptors/decorators, deployment types, synchronous events, 2 of the 4 contexts, datasources, JPA and declarative transaction demarcation.

It doesn't have servlet integration, presentation, JMS, asynchronicity, session/conversation contexts or EL.

Are you really going to get that upset by the fact that it has JPA in there?

I for sure won't be upset. But would really like know what is the technical reason not doing separate Part 1. It seams obvious to me to take such approach from architectural point of view. One can come up with many usages for such scenario. For example using WebBeans as skeleton for Maven 5 mojo handling with unnecessary JPA dependencies. ;-)

[gavin.king]

Not very different still means different though. :-)

Well, sure, but the point is if we line up 10 guys and ask them what features should be in the EE web profile, we get 10 different answers. Trust me, I've seen this happen.

I for sure won't be upset. But would really like know what is the technical reason not doing separate Part 1

What does separate mean? Two different specification documents? Two different JSRs? The political reason for doing it in one JSR is that we want everything to be internally consistent and work well together, and that is not possible if you have multiple expert groups.

It seams obvious to me to take such approach from architectural point of view.

Java specifications don't define the architecture of things that implement them. The only define how the implementation interacts with the application. An implementation can have whatever architecture it likes. Nothing stops you from implementing 299 in layers if that is what you prefer.