[peteroyle.howardmoon.hitcity.com.au]

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

[peteroyle.howardmoon.hitcity.com.au]

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.

[peteroyle.howardmoon.hitcity.com.au]

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

com.screamingcoder.plebeians.StarMain

[gavin.king]

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

[gavin.king]

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

[gavin.king]

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

[pmuir]

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

[peteroyle.howardmoon.hitcity.com.au]

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!

[peteroyle.howardmoon.hitcity.com.au]

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,

[peteroyle.howardmoon.hitcity.com.au]

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.

[gavin.king]

Pete, did we end up using the event approach?

[peteroyle.howardmoon.hitcity.com.au]

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.

[niravshah]

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

[pmuir]

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.