[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?
15 years, 5 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.
15 years, 5 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
15 years, 5 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
>
15 years, 5 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
15 years, 5 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
15 years, 5 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
15 years, 5 months
[webbeans-dev] build fails with java 6
by Michael Brackx
Hi,
The build fails for me with java 6. Might be known or unsupported, but
nothing was mentioned on
http://www.seamframework.org/WebBeans/GuidelinesForWebBeansRIDevelopment
Environment:
Maven version: 2.0.9
Java version: 1.6.0_07
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
error:
[INFO] Compilation failure
...\webbeans-ri\src\main\java\org\jboss\webbeans\introspector\impl\SimpleAnnotatedClass.java:[234,69]
incompatible types
found : java.lang.reflect.Constructor<?>
required: java.lang.reflect.Constructor<T>
Michael Brackx
15 years, 5 months
