Great work on this, Peter, it's really nice. I think we should let you specify an event type to raise:   java -Devent=my.Event or, perhaps, an event qualifier to be applied to the ContainerInitialized event:   java -Dqualifier=my.Qualifier that way, you have a mechanism for choosing between "main methods". Alternatively, we could use something EL-ish to specify a method to call:   java -Daction=mybean.method Hrm, perhaps that's the best option. Maybe my idea of using an event wasn't so great after all. WDYT? -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org

java -Devent=my.Event java -Daction=mybean.method

Von: Gavin King <gavin.king(a)gmail.com&gt; Betreff: [weld-dev] Java SE extension An: "Weld-Dev" <weld-dev(a)lists.jboss.org&gt; Datum: Dienstag, 17. November 2009, 23:25 Great work on this, Peter, it's really nice. I think we should let you specify an event type to raise:    java -Devent=my.Event or, perhaps, an event qualifier to be applied to the ContainerInitialized event:    java -Dqualifier=my.Qualifier that way, you have a mechanism for choosing between "main methods". Alternatively, we could use something EL-ish to specify a method to call:    java -Daction=mybean.method Hrm, perhaps that's the best option. Maybe my idea of using an event wasn't so great after all. WDYT? -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

Using the JSR-299 eventing instead of their own internal eventing system in JSF might open some interesting possibilities...

Great work on this, Peter, it's really nice.

I think we should let you specify an event type to raise: java -Devent=my.Event or, perhaps, an event qualifier to be applied to the ContainerInitialized event: java -Dqualifier=my.Qualifier that way, you have a mechanism for choosing between "main methods". Alternatively, we could use something EL-ish to specify a method to call: java -Daction=mybean.method Hrm, perhaps that's the best option. Maybe my idea of using an event wasn't so great after all. WDYT? -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

Great work on this, Peter, it's really nice. I think we should let you specify an event type to raise: java -Devent=my.Event or, perhaps, an event qualifier to be applied to the ContainerInitialized event: java -Dqualifier=my.Qualifier that way, you have a mechanism for choosing between "main methods". Alternatively, we could use something EL-ish to specify a method to call: java -Daction=mybean.method Hrm, perhaps that's the best option. Maybe my idea of using an event wasn't so great after all. WDYT? -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

On Sat, Nov 21, 2009 at 10:47 AM, Pete Muir <pmuir(a)redhat.com&gt; wrote: > * I would prefer to not actually bootstrap Weld core inside the Weld constructor (I believe this should be an explicit step), hence the boot() method. We could rename this to initialize() for example. Opinions? Fine by me. Especially since that at some stage we will need to pass some kind of settings before booting. > * What API do we want to expose to allow people to get hold of an Instance<?> ? IMO we need more syntatic sugar than offered by BeanManager. Do we want to just allow access to Instances (as above)? Stick the following two methods on the object returned by initialize(): Instance<Object> instance(); Instance<Event> event(); So I can do: Weld weld = new Weld().initialize(); weld.instance().select(Foo.class).get() weld.event().select(Bar.class).fire( new Bar() ); weld.shutdown(); Or whatever.

On 21 nov. 09, at 19:36, Gavin King wrote: > On Sat, Nov 21, 2009 at 10:47 AM, Pete Muir <pmuir(a)redhat.com&gt; wrote: > >> * I would prefer to not actually bootstrap Weld core inside the >> Weld constructor (I believe this should be an explicit step), hence >> the boot() method. We could rename this to initialize() for >> example. Opinions? > > Fine by me. Especially since that at some stage we will need to pass > some kind of settings before booting. Which probably means you don't want Weld to host both the configuration and the operation methods WeldContainer weld = new Weld().initialize(); weld.instance().select(Foo.class).get();

> WeldContainer weld = new Weld().initialize(); > weld.instance().select(Foo.class).get(); Yes, this seems sensible to me, as it will allow us to provide flexibility with the configuration in the future. Emmanuel, master of fluent APIs, has made an important point that we should keep in mind when designing a sequential call chain. Think twice before returning "this" and think if there is a more specific type that you can return that narrows the options based on where you are in the sequence. That way, you prevent being able to invoke methods out of sequence. You can now prevent: new Weld().event() Returning a more specific type is also self documenting. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

It looks as if event() is returning javax.enterprise.inject.Instance<javax.enterprise.event.Event> instead of javax.enterprise.event.Event. On Sun, Nov 29, 2009 at 6:12 PM, Peter Royle <howardmoon(a)screamingcoder.com&gt; wrote: > Hi, > I've done the first iteration of this (checked in - r5173). It doesn't yet > separate out the initialisation, I'll do that next. > One problem is that I can't get the following line to compile: > weld.event().select(CustomEvent.class).fire(new CustomEvent()); > I get: > Compilation failure > org/jboss/weld/environment/se/test/WeldMainTest.java:[70,18] cannot find > symbol > symbol : method > select(java.lang.Class<org.jboss.weld.environment.se.test.beans.CustomEvent>) > location: interface > javax.enterprise.inject.Instance<javax.enterprise.event.Event> > I think the problem is that my CustomEvent doesn't implement or extend > Event. I don't think it has to though (am I mistaken?). Anyone know what I'm > missing? > Cheers, > > > On 24/11/2009, at 11:11 PM, Dan Allen wrote: > >> >>> WeldContainer weld = new Weld().initialize(); >>> weld.instance().select(Foo.class).get(); >> >> Yes, this seems sensible to me, as it will allow us to provide flexibility >> with the configuration in the future. > > Emmanuel, master of fluent APIs, has made an important point that we should > keep in mind when designing a sequential call chain. Think twice before > returning "this" and think if there is a more specific type that you can > return that narrows the options based on where you are in the sequence. That > way, you prevent being able to invoke methods out of sequence. > > You can now prevent: > > new Weld().event() > > Returning a more specific type is also self documenting. > > -Dan > -- > Dan Allen > Senior Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://mojavelinux.com > http://mojavelinux.com/seaminaction > http://www.google.com/profiles/dan.j.allen > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org

OK I've added WeldContainer, so now it's as Emmanuel suggested: WeldContainer weld = new Weld().initialize(); weld.instance().select(Foo.clas); weld.shutdown(); So: new Weld().event() // doesn't exist new WeldContainer(InstanceManager, BeanManager) // is package protected Pete R. On 30/11/2009, at 9:12 AM, Peter Royle wrote: > Hi, > > I've done the first iteration of this (checked in - r5173). It doesn't yet separate out the initialisation, I'll do that next. > > One problem is that I can't get the following line to compile: > > weld.event().select(CustomEvent.class).fire(new CustomEvent()); > > I get: > > Compilation failure > org/jboss/weld/environment/se/test/WeldMainTest.java:[70,18] cannot find symbol > symbol : method select(java.lang.Class<org.jboss.weld.environment.se.test.beans.CustomEvent>) > location: interface javax.enterprise.inject.Instance<javax.enterprise.event.Event> > > I think the problem is that my CustomEvent doesn't implement or extend Event. I don't think it has to though (am I mistaken?). Anyone know what I'm missing? > > Cheers, > > > > On 24/11/2009, at 11:11 PM, Dan Allen wrote: > >> >> >> > WeldContainer weld = new Weld().initialize(); >> > weld.instance().select(Foo.class).get(); >> >> Yes, this seems sensible to me, as it will allow us to provide flexibility with the configuration in the future. >> >> Emmanuel, master of fluent APIs, has made an important point that we should keep in mind when designing a sequential call chain. Think twice before returning "this" and think if there is a more specific type that you can return that narrows the options based on where you are in the sequence. That way, you prevent being able to invoke methods out of sequence. >> >> You can now prevent: >> >> new Weld().event() >> >> Returning a more specific type is also self documenting. >> >> -Dan >> >> -- >> Dan Allen >> Senior Software Engineer, Red Hat | Author of Seam in Action >> Registered Linux User #231597 >> >> http://mojavelinux.com >> http://mojavelinux.com/seaminaction >> http://www.google.com/profiles/dan.j.allen >> _______________________________________________ >> weld-dev mailing list >> weld-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/weld-dev > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev