-
1. Re: Web Beans Sneak Peak
matt.drees Sep 22, 2007 11:03 AM (in response to gavin.king)Cool stuff! I'm looking forward to the rest.
-
2. Re: Web Beans Sneak Peak
gavin.king Sep 22, 2007 11:33 AM (in response to gavin.king)Second installment is up:
http://in.relation.to/Bloggers/WebBeansSneakPeekPartIIInjectionBindingAnnotationsAndComponentTypes -
-
-
5. Re: Web Beans Sneak Peek
christian.bauer Sep 24, 2007 1:00 AM (in response to gavin.king)These were renamed, find the whole series here:
http://in.relation.to/Bloggers/Gavin -
6. Re: Web Beans Sneak Peek
ylazzari Sep 27, 2007 10:08 AM (in response to gavin.king)Hi,
I don't know if this is the palce but after reading all 4 parts of the sneak peak of Web Beans, here's a couple of comments/questions I would like share.
@Named annotation
I know that this has also been raise about Seam but would it be possible to remove that annotation and use the value() of the @Component annotation or add a "name" attribute to it instead? I found it would be more meaningful this way. Or maybe the @Named attribute has other uses which requires it to be separate?
Injection on resolver method
In the example that you give in part 4 about how to use injection in resolver method, wouldn't it be better to instantiate the component through the Web Beans API instead of having the container inject 3 values and in the end only using one of them? Something like:@Resolves @Preferred @ApplicationScoped public PaymentStrategy getPaymentStrategy() { switch (paymentStrategy) { case CREDIT_CARD: return container.methodToInjectBean("whatevertheparamshouldbe"); case CHEQUE: container.methodToInjectBean("whatevertheparamshouldbe"); case PAYPAL: container.methodToInjectBean("whatevertheparamshouldbe"); default: return null; } }
Again, I understand it was maybe only to showcase the possibility and not necessarily the only work around to this problem but I was just curious if it would be the preferred way to address this situation.
Integreation in Seam
It probably is too soon to discuss this but are there any plans to replace Seam's component model with Web Beans? I know that some features/behaviour of the Seam component model might be missing from the Web Beans specification but is the ultimate goal the one day use it in Seam?
Thanks for sharing this preview of the specification with us. -
7. Re: Web Beans Sneak Peek
gavin.king Sep 27, 2007 11:38 AM (in response to gavin.king)I know that this has also been raise about Seam but would it be possible to remove that annotation and use the value() of the @Component annotation or add a "name" attribute to it instead? I found it would be more meaningful this way. Or maybe the @Named attribute has other uses which requires it to be separate?
There are many component type annotations (@Component, @Standard, and all the user-defined component types). It doesn't make sense to re-declare the name attribute each time we create a new component type.
And please compare:@Component(name="foo") @Component @Name("foo")
The only difference is a single space.In the example that you give in part 4 about how to use injection in resolver method, wouldn't it be better to instantiate the component through the Web Beans API instead of having the container inject 3 values and in the end only using one of them?
You can do that if you like. It will look like:Component<Foo> comp = container.resolveByType(Foo.class); Foo foo = container.getContext(comp.getScope()).get(comp)
It probably is too soon to discuss this but are there any plans to replace Seam's component model with Web Beans? I know that some features/behaviour of the Seam component model might be missing from the Web Beans specification but is the ultimate goal the one day use it in Seam?
The current Seam codebase will evolve into the Web Beans RI. Then non-standardized features of Seam will be layered over the Web Beans standard. -
8. Re: Web Beans Sneak Peek
ylazzari Sep 27, 2007 2:11 PM (in response to gavin.king)My argument against the @Named annotation wasn't about the number of extra key strokes (as you pointed out, there is only one!) I was merely saying that to me, if you say that a component has a name, it would make more sense that it has a "name" attribute, not a separate annotation. Are you saying that because many annotations have to share common attributes that those common attributes should be turned into individual annotations just so you don't have to repeat them on each one? Take the @Stateless and @Stateful annotation. Are you saying that the EJB 3 spec is wrong in having duplicated the set of attributes they have in them? I can understand that when it comes to extending the framework and developing your own custom annotations it makes it a little bit easier because you don't have to carry over that attribute, but for clarity's sake and because I find it semantically more accurate, I like my idea better. It wouldn't be that much to ask that component annotations must define a name attribute. Then again, who am I to decide, right? Sorry for busting your balls, but I like to argument. And what's wrong with argumenting anyways? Isn't it how things get better?
-
9. Re: Web Beans Sneak Peek
lisaanm Oct 1, 2007 11:24 AM (in response to gavin.king)Hi,
Web Beans pre-review sounds good.
But what about the core EJB functionality: Distribution (Remote, RMI etc.,). I'm excited to know little more about this.
Thanks -
10. Re: Web Beans Sneak Peek
mnrz Oct 15, 2007 2:24 AM (in response to gavin.king)Thanks Gavin, I found it really nice and useful document :)
-
11. Re: Web Beans Sneak Peek
nickarls Oct 23, 2007 3:01 PM (in response to gavin.king)And the early draft now seems to be available (as seen on TSS):
http://in.relation.to/Bloggers/JSR299WebBeansEarlyDraft -
12. Re: Web Beans Sneak Peek
gavin.king Nov 5, 2007 11:40 PM (in response to gavin.king)But what about the core EJB functionality: Distribution (Remote, RMI etc.,). I'm excited to know little more about this.
Well, yeah, I need to write another installment covering that ... but, all you need to know is: you can use it all :-) And remember, EJB 3.1 will introduce a bunch of new stuff: singletons, bean-class local views, much improved timer service, etc.
Actually its pretty exciting what's going on in EJB 3.1. -
13. Re: Web Beans Sneak Peek
gavin.king Nov 5, 2007 11:44 PM (in response to gavin.king)My argument against the @Named annotation wasn't about the number of extra key strokes (as you pointed out, there is only one!) I was merely saying that to me, if you say that a component has a name, it would make more sense that it has a "name" attribute, not a separate annotation. Are you saying that because many annotations have to share common attributes that those common attributes should be turned into individual annotations just so you don't have to repeat them on each one? Take the @Stateless and @Stateful annotation. Are you saying that the EJB 3 spec is wrong in having duplicated the set of attributes they have in them?
Yes, I think that was a mistake. If I'm writing code that needs to discover the name of an EJB, it would be *much* better if there was just one annotation to look for. If annotation inheritance was supported, it would not be a problem, we could have @Stateless and @Stateful both extend @EJBComponent, and it might be OK.
It's even worse in Web Beans, where component types can be defined by the user.
When people see annotations, they start to forget all their OO modeling knowledge, for some reason. Try to think in terms of modeling and typesafety. -
14. Re: Web Beans Sneak Peek
ar.mohseni Dec 24, 2007 1:01 AM (in response to gavin.king)"mnrz" wrote:
Thanks Gavin, I found it really nice and useful document :)
hi mr. nourozi
please contact me.
apc.mohseni@gmail.com
tanx