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

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?

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?

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.

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. :-)

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?

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.

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.)

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.

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.

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...

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?

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. ;-)

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.

Gavin King wrote on Jan 08, 2009 17:54:
Possibly the disconnect comes from what people mean by the term Web Beans. ;-)

Agreed!

Now, that doesn't constrain an actual implementation of JSR-299 from executing in some other environment without support for certain EE technologies. ... 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?

No, definitely not from that point of view, but possibly from others. Take JME or applets for example. Outside my JEE day job, I like messing around with Processing applets now and then - something people far more talented than myself do for a living. I think it would be great to be able to use Part 1 to do this. To my mind events, interceptors and decorators feel like a good fit for designing complex, reactive graphical simulations. And DI is always welcome.

I'm not saying this justifies any modification to the spec today. I just hope that the ability to run Web Beans in this zero-EE way remains so as to give people the opportunity to see if it's useful or not. I suspect there may be some weird and wonderful use cases for it, but only time will tell.

I totally understand that this is nowhere near the target audience of the Web Beans spec, and that the recurrence of this theme is probably slightly tedious for you JBoss guys! Thanks for bearing with us as we explore all the possible implications, intended or otherwise, of this great spec :).

OK, I've made a proof of concept. It a bit rough and ready. But it's here for now: http://screamingcoder.com/projects/plebeians/plebeians.tar.gz. There's a simple example with that. The main things to know are:

• Include the Plebeians.jar and all its dependencies on the classpath
• Implement your own Web Beans (simple Web Beans only, of course)
• Annotate your 'main' Web Bean with @Main. Plebeians will instantiate this for you.
• Annotate one of your 'main' Web Bean's methods with @Initializer. This will act as your 'main' method. You can inject stuff directly into it if you want.
• Your command line parameters, should you need them, will be injected at

@Params String[] whatever

• Only @Dependent and @ApplicationScoped contexts are supported.

Known issues:

• The code is a little rushed :) Some of the things I've done to get the Manager going without EE may be a little dubious.
• Also what does anyone think about the @Initializer thing? Round peg in a square hole? It was just the easiest way of getting injections on the main method.
• I've copied and modified some code from the JBoss RI (some of the Mock classes and bootstrappy stuff). JBoss guys if you'd like to take a look, please let me know if I've done anything you don't like (or illegal) with your code. Source is included with the download.

Oh yeah, and you start your app with this main method:

com.screamingcoder.plebeians.StarMain

One possibility would be to make it an event, and the main method would look like:

public static void main(@Observes Start start) {

    String param = start.getParameter(0);
    ...

}

Or you could inject the parameters separately (using a producer method):

public static void main(@Observes Start start, @Parameters List<String> parameters) {

    String param = parameters.get(0);
    ...

}

I love the events stuff :-)

Of course, the observer method doesn't need to be called main() and doesn't need to be static :-)

@Parameters is a binding type, of course. It comes from a producer like this:

@Produces @Parameters List<String> getParameters() { .... }

And the Start event is fired like this:

manager.fireEvent( new Start(...) );

Hi Pete ;-)

I took a quick look at your code - it looks exactly like I had envisioned doing an SE extension of the RI would look like (which is good :-). Nice!

I'm not quite sure which version of the RI you are working with, but I've altered the SPI a little recently, which should make your life easier:

• Split out EjbDiscovery from Web Bean Discovery (a bit cleaner)
• Added PropertiesBasedBootstrap to allow you to make it easy to load the various SPI implementations from properties (a properties file or system properties specified to java) - might be worth doing this to make it easy for people to swap out the SPI?
• I'm still not sure how I would approach contexts in the SE case, but I think what you did looks good. There might be some problems though with using this in OSGI as I use ThreadLocal quite a lot in the default context impls.
• Leaving the dependent context open all the time - probably only using it (or Gavin) can tell you if this is sensible
• I wouldn't use scannotation for class discovery (as all classes should be Web Beans, not just those annotated). Take a look at URLScanner in Seam for a scanner which will discover all classes which have a specific file in the root of the archive.

Finally, are you interested in contributing this as module? As we currently have no modules, quite what this means is open to speculation ;-), but at the very least:

• host in webbeans svn
• document on sfwk.org

and for this module:

• include in the Web Bean releases
• document in the reference guide

Drop me an email if you are,

Pete

Gavin King wrote on Jan 16, 2009 07:28:
One possibility would be to make it an event

Of course! Good idea. I've implemented it this way now.

Gavin King wrote on Jan 16, 2009 07:28:
Or you could inject the parameters separately (using a producer method):

Yeah I chose this approach exclusively. I like the decoupling since you may want to pass the params through some kind of validation/transformation as I do in my simple example. Then by the time they get to your business logic they're being injected as something more meaningful.

Or you can just pass them straight in if you like!

Pete, I'm working with TRUNK. I've made some changes as per your suggestions and updated the archive linked above (all versions are listed at http://screamingcoder.com/projects/plebeians/). I've also Mavenised the projects so they're easier to work with.

Pete Muir wrote on Jan 18, 2009 01:28:
Added PropertiesBasedBootstrap

I've extended the PropertiesBasedBootstrap class - not sure if there's anything else I need to do?

Pete Muir wrote on Jan 18, 2009 01:28:
There might be some problems though with using this in OSGI as I use ThreadLocal quite a lot in the default context impls.

I think I know what you mean, but probably could use a better understanding of how contexts work in multi-threaded environments before I try to tackle this..

Pete Muir wrote on Jan 18, 2009 01:28:
Leaving the dependent context open all the time - probably only using it (or Gavin) can tell you if this is sensible

Luckily this issue goes away since I'm now using an event to fire off the main method, as per Gavin's suggestion. The Dependent context is closed before the event is fired.

Pete Muir wrote on Jan 18, 2009 01:28:
Take a look at URLScanner in Seam

Will probably check this out next.

Pete Muir wrote on Jan 18, 2009 01:28:
Finally, are you interested in contributing this as module? As we currently have no modules, quite what this means is open to speculation ;-)

Sounds like fun. I'll do a bit more work on it (the URL scanning at least) then I'll swing you an email.

Cheers,

Pete,

I'll email you the code over the weekend, then I promise to leave this thread alone :). I just want to know what group, artifact and package name you think I should use? If I get that right now I can continue working with it while you merge it in to SVN and the changes should be relatively easy to track (no major refactorings).

Cheers,

Pete.

Pete, did we end up using the event approach?

We sure did. We're using the existing @Initialized Manager and @Deployed Manager events as hooks for application/module configuration and startup respectively. I'll be writing some documentation for this soon.

Hi Pete / Pete,

Can either of you point me to the latest version of this code please? Is it already in the Web Beans SVN?

Also in what release do we plan to include this. (when is the GA due?)

Cheers! Nirav

Yes, it's in SVN - look in extensions/trunk/se - and built nightly.

We will include it in the next release - a preview release of 1.0.0 - the core is fairly stable at this point. The 1.0.0 release date is currently unknown, as the spec has not been finalised yet.