[webbeans-dev] @Supports
by Gavin King
I've been thinking about the problem of implementing re-usable
components like our JMS endpoints. What I'm trying to do is implement
the requirements of JMS endpoints as a simple Web Bean. To do that
today, I would need to create a class which implemented all the API
types:
@ApplicationScoped
public class QueueEndpoint
implements Queue, QueueSession, QueueSender, QueueConnection { ... }
and I would have to go and implement every one of the operations of
each of those interfaces to delegate to the correct object. (A bunch
of tedious code.)
However, if we assume that the client proxy is smart enough, we could
let the Web Bean manager automagically do that delegation for us. We
would need a new annotation that could be applied to fields or
methods, for example:
@ApplicationScoped
public class QueueEndpoint {
...
@Supports Queue getQueue() { ... }
@Supports QueueSession getQueueSession() { ... }
@Supports QueueSender getQueueSender() { ... }
@Supports QueueConnection getQueueConnection() { ... }
}
We no longer need to write all those annoying delegation methods! The
client proxy would just call the correct @Supports method when the
QueueEndpoint type did not define the method that was invoked by the
client, and delegate the method to the returned object.
To make this really work, we would need to say:
* the set of API types of the Web Bean includes all types of @Supports
methods/fields
* if a certain method name appears on more than one @Supports
method/field type, it must also be implemented directly by the impl
class
* if a certain method name appears on more than one @Supports
method/field type, or on both the impl class and a @Supports
method/field type, it is always called on the impl class
Therefore, close() would need to be implemented by QueueEndpoint:
@ApplicationScoped
public class QueueEndpoint {
...
@Supports Queue getQueue() { ... }
@Supports QueueSession getQueueSession() { ... }
@Supports QueueSender getQueueSender() { ... }
@Supports QueueConnection getQueueConnection() { ... }
void close() { throw new UnsupportedOperationException(); }
}
You're probably thinking that we can do all this with @Producer
methods, however, the semantics are not exactly the same, since the
association b/w the producer object and produced object is lost as
soon as the producer method returns. Furthermore, @Producer methods
aren't really appropriate for 3rd-party reusable objects, since the
XML configuration of a producer method is verbose.
I don't believe that Web Beans 1.0 absolutely has to have this
feature, but I know its useful, and I know that we will implement it
in the RI, so I would prefer if it was portable. What do you guys
think? Useful? Too much magic? Let me know...
Seam already has an extremely primitive/braindead version of this
feature, that I've found *extremely* useful when writing reusable
components:
http://docs.jboss.com/seam/2.1.0.SP1/reference/en-US/html/concepts.html#d...
(@Factory is more or less like @Produces, whereas @Unwrap is a really
crappy version of @Supports.)
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
17 years, 3 months
[webbeans-dev] Web Beans RI - hot deploy
by Pete Muir
However we implement hot-deploy in the RI (our own classloader like
Seam, or with the container doing it) we need to make sure that we
include the ability to reset meta-data about individual beans in WB.
With this in mind, and other bits like @Logger, we should split out a
webbeans-ri-api jar I think. Opinions?
17 years, 3 months
[webbeans-dev] ejb-jar.xml is not in the root
by Pete Muir
Whilst working on the web bean discovery, Ales and I hit a spec issue.
In 10.1 of the current spec 20081105 it says:
* any ejb-jar.xml file in any root directory of the application
classpath that also has a web-beans.xml file, and
but ejb-jar.xml is placed in META-INF/
Also, Ales thinks that web-beans.xml should be in META-INF/ as this is
consistent with other specs.
Also this causes some problems when doing a deployer for JBoss 5, Ales
can explain more, as I don't understand exactly why.
17 years, 4 months
[webbeans-dev] Hierarchical Managers
by Gavin King
Oracle have a usecase where they want to be able to define Web Beans
within a particular "context" (in their usecase, the context is
something like an orchestration task). I think we can handle this by
providing a hierarchy of Managers. We would add a method to Manager to
create a child, and a method to associate a child (or root) Manager
with the current context associated with a certain active scope:
public interface Manager {
...
public Manager createChild();
public void setCurrent(Class<Annotation> scopeType);
}
A child Manager would inherit all Web Beans, interceptors, decorators,
contexts of its parent, but would allow addition of now ones. So
Oracle's orchestration engine could create a Manager object for each
task definition at startup time, and then when the task started
processing, call setCurrent(TaskScoped.class). When the context ends,
web beans automagically reverts to the root Manager.
What do you guys think?
Bill, do you think this solves the problem you guys have?
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
17 years, 4 months
[webbeans-dev] Fwd: static producers
by Chris Dempsey
I don't see a problem with that at all. Just not supporting static method
specialization it seems to be the best choice to me.
On Sat, Nov 15, 2008 at 1:36 AM, Gavin King <gavin(a)hibernate.org> wrote:
> Hi Chris.
>
> What I'm thinking is simply to not define/support specialization for
> static producers.
>
> I think that's fine....
>
> Do you see a problem with that?
>
> On Fri, Nov 14, 2008 at 1:52 PM, Chris Dempsey <cdallas(a)gmail.com> wrote:
> > Hi all. I've been a lurker on the list for a while and have been reading
> > and studying the spec like a mad man. If I go off the rails here feel
> free
> > to let me know. :)
> >
> > The only thing I can think of as a possible issue with this is Web Bean
> > specialization? Static methods cannot be overridden and only hidden by
> > sub-classes and the declared type (any actual instance is ignored) is
> used
> > to resolve which static method is called. If you had a static
> > Foo#producerMethod and a specialization of a static
> MockFoo#producerMethod
> > Web Beans would have to know to call MockFoo.producerMethod and couldn't
> > rely on Foo.producerMethod to resolve polymorphically to the specialized
> > producer method.
> >
> > I don't think it would be a problem that couldn't be overcome but it
> would
> > seem to complicate the specialization rules quite a bit.
> >
> > On Fri, Nov 14, 2008 at 11:50 AM, Gavin King <gavin(a)hibernate.org>
> wrote:
> >>
> >> ---------- Forwarded message ----------
> >> From: Gavin King <gavin(a)hibernate.org>
> >> Date: Fri, Nov 14, 2008 at 12:50 PM
> >> Subject: static producers
> >> To: Java Community Process JSR #299 Expert List <JSR-299-EG(a)jcp.org>
> >>
> >>
> >> Question:
> >>
> >> should we allow producer methods and fields to be declared "static"?
> >>
> >> This would mean that the Web Bean manager does not need to instantiate
> >> an instance of the Web Bean that declares the producer method/field
> >> when invoking the method/field.
> >>
> >> I can't think of a good reason why *not*...
> >>
> >> Furthermore, should we allow static observer and disposal methods?
> >> Again, I can't quite think of a reason why *not*...
> >>
> >> --
> >> Gavin King
> >> gavin.king(a)gmail.com
> >> http://in.relation.to/Bloggers/Gavin
> >> http://hibernate.org
> >> http://seamframework.org
> >>
> >>
> >>
> >> --
> >> Gavin King
> >> gavin.king(a)gmail.com
> >> http://in.relation.to/Bloggers/Gavin
> >> http://hibernate.org
> >> http://seamframework.org
> >> _______________________________________________
> >> webbeans-dev mailing list
> >> webbeans-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/webbeans-dev
> >
> >
> > _______________________________________________
> > webbeans-dev mailing list
> > webbeans-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/webbeans-dev
> >
> >
>
>
>
> --
> Gavin King
> gavin.king(a)gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
>
17 years, 4 months
[webbeans-dev] Updated Hudson build notifications to include links to the public hudson server
by Jay Balunas
Hello all,
Previously all build messages from hudson contained links to hudson
servers that were behind the redhat VPN. This meant that no one could
access build information unless they were connected to and had access
to Red Hat's VPN.
I updated all Seam, WebBeans, and RichFaces builds so that the
messages now include both the original link, and a new link that
points to the public hudson server. The new links will take you to
the effected hudson job, but not the exact build. There is no way to
make that work at the moment.
Please let me know if I got any of the links wrong, or missed any of
the important builds. They should be all set, but I am not positive,
until the messages actually get sent.
By the way the notification criteria can be customized to some extent,
but as of now all the effected builds have the same scheme. In all of
these situations - failed, unstable, still-failed, still-unstable,
fixed - users who have made commits to the current, fixed, or still
failing/unstable builds will receive the email.
Let me know if we want changes made.
Regards,
Jay
17 years, 4 months
[webbeans-dev] Producer fields?
by Gavin King
I'm trying to decide if we want to support @Produces on fields. i.e.
@Produces Foo foo;
is equivalent to:
Foo foo;
@Produces Foo getFoo() { return foo; }
Evan from Sybase has requested it in the Web Beans EG, and I'm
sympathetic b/c it throws a bone to Seam folks who love outjection.
Note, however, that it is not exactly the same as outjection .... the
object only gets bound to the context if someone requests it.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
17 years, 4 months
[webbeans-dev] Bean removal
by Nicklas Karlsson
Some question on bean removal / contexts:
* 8.2 says destroying a context calls all Bean.destroy methods. Is it
implied that they are also removed from the context?
Or are the bean instances just flagged "destroyed"?
* How is a bean removed from a context manually? Currently, there is
no API on ManagerImp/NormalContext for this, should there be?
* Calling a bean destroy method manually does nothing extra from
lifecycle point of view?
* Calling an EJB remove method triggers the (currently non-existent)
remove method on the Manager impl which then calls the destroy method
and removes the bean from the context (with the currently
non-existent) Context impl remove method?
* Can a bean be removed from a context that is not currently active?
---
Nik
17 years, 4 months
