WELD-862 and Seam Cron
by Peter Royle
Hi,
I'm aiming to make a release of Seam Cron available within the next two weeks. Currently there is an outstanding issue (https://issues.jboss.org/browse/WELD-862) which prevents Cron from running properly with Weld. I have been able to carry on developing Cron by testing it against OpenWebBeans, but obviously if we are to release a Seam module it should work against Weld.
It would be nice if WELD-862 could be fixed as soon a possible so that all future versions will work well with Cron.
But more importantly I also probably need to do something special in Cron so that it will work with the version of Weld already deployed in JBoss AS and Glassfish, which will contain the bug. The workaround mentioned in the bug report is to deep copy the InvocationContext. I attempted to do this by serialising and unserialising the InvocationContext but couldn't due to UnserializableExceptions. Does anyone have any advice for me about how I might be able to work around this bug to support existing versions of Weld?
Cheers,
Pete R
2 months
Bridge methods & proxies & interceptors
by Marko Lukša
Hey all.
I've been working on https://issues.jboss.org/browse/WELD-1162 and need
your opinion.
Say we have:
public interface Foo<T> {
void doSomething(T t);
}
public interface StringFoo extends Foo<String> {}
public class StringFooImpl implements StringFoo {}
and
@Inject StringFoo stringFoo;
The proxy created by Weld is a subclass of StringFooImpl and therefore
has two declared methods:
void doSomething(Object o) { doSomething((String) o); }
void doSomething(String) {...}
However, when StringFooImpl is a session bean, with StringFoo as its
local interface, the proxy is a subclass of Object and therefore the
proxy only has the following declared method:
void doSomething(Object o);
In both cases, when a client invokes stringFoo.doSomething("foo"), the
method doSomething(Object) is invoked. But there's a difference in what
happens next:
* In the non-ejb version, the bridge method then immediately invokes
doSomething(String) and only then is the proxy's method handler
invoked. The handler is therefore dealing with the method
doSomething(*String*)
* in the EJB version, doSomething(Object) is not a bridge method, and
so the method handler is invoked directly and it (the handler) is
operating on doSomething(*Object*).
In the second case, this ultimately means that Weld will check whether
doSomething(Object) is intercepted. It isn't, since
Beans.getInterceptableMethods() is ignoring bridge methods. The
interceptor will not be invoked. On the other hand, in the first case,
the interceptor _will_ be invoked, since Weld will be checking whether
doSomething(String) is intercepted.
My initial solution was to make Beans.getInterceptableMethods() also
return bridge methods, but now I'm thinking the actual problem is in the
proxy itself. IMO, when creating a proxy based on an interface, we
should also generate bridge methods on the proxy (this should be either
done by Weld or by Javassist directly). These bridge methods should be
perfectly normal bridge methods and should not invoke the method handler
directly. They should simply invoke the non-bridge method and the
non-bridge method should then invoke the method handler.
The java compiler can't add bridge methods directly to interfaces which
require them, so it adds them to all the classes implementing the
interface (StringFooImpl in our case). Since we are creating
StringFoo$Proxy, which is also a class implementing an interface which
requires bridge methods, we should add the bridge methods
to it - exactly as the java compiler would.
This would solve the interceptor problem and possibly other similar
problems as well.
What do you think?
Marko
13 years, 6 months
weld-osgi status update
by Ales Justin
A quick update on Weld-OSGi.
I finally managed to get all tests - plain, incontainer, etc - to pass. :-)
(apart from that disabled LifeCycleTest, which I'm waiting on Mathieu to have a look)
This are the latest branches I've been working on
(a) Weld API: https://github.com/alesj/api/tree/osgi2
(b) AS7 OSGi: https://github.com/alesj/jboss-as/tree/osgi2
(c) Weld OSGi: https://github.com/alesj/core/tree/osgi3
@Stuart:
* I would need a new AS7 CDI TCK Runner - 1.0.0.CR3
* if you could run this stuff against JEE6 TCK
Now the next question is how to get this into AS7?
As it's sort of a chicken-n-egg problem. :-)
We need to upgrade Weld API in AS7 + switch its impl,
but to release the impl we need to test this against latest AS7.
I guess if this manual setup from above (a, b, c) fully works,
we could tweak/hack the release of impl (Weld Core) a bit?
-Ales
13 years, 6 months
New Seam/Weld QE Lead
by Ondřej Skutka
Hello!
Let me announce a change in the Seam/Weld QE Lead position. From now on you can reach to Marek Schmidt to solve all your Seam/Weld QE related problems and tasks for the team.
Marek has only been in the team since Feb 2011, but he grew very quickly to an internals expert with the ability to dig deep into any problem fast and effectively (read he can break anything). He's also able to manage other team members as he's proven many times, so I believe this role will suit him well.
Please join me in congratulating Marek on his new role.
Good luck, Marek
Thanks,
Ondra
13 years, 6 months
Re: [weld-dev] [seam-dev] New Seam/Weld QE Lead
by Daniel Hinojosa
Howdy
On Wed, Sep 5, 2012 at 7:12 AM, Martin Gainty <mgainty(a)hotmail.com> wrote:
> ich gratuliere Marek!
>
> Martin
> ______________________________________________
> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
>
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
> dient lediglich dem Austausch von Informationen und entfaltet keine
> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
> E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
>
> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
>
>
>
>
> > Date: Wed, 5 Sep 2012 14:39:04 +0200
> > To: jboss-qa-internal(a)redhat.com
> > From: oskutka(a)redhat.com
> > CC: seam-qa-list(a)redhat.com; wfk-pm-list(a)redhat.com;
> seam-dev(a)lists.jboss.org; weld-dev(a)lists.jboss.org
> > Subject: [seam-dev] New Seam/Weld QE Lead
>
> >
> > Hello!
> >
> > Let me announce a change in the Seam/Weld QE Lead position. From now on
> you can reach to Marek Schmidt to solve all your Seam/Weld QE related
> problems and tasks for the team.
> >
> > Marek has only been in the team since Feb 2011, but he grew very quickly
> to an internals expert with the ability to dig deep into any problem fast
> and effectively (read he can break anything). He's also able to manage
> other team members as he's proven many times, so I believe this role will
> suit him well.
> >
> > Please join me in congratulating Marek on his new role.
> >
> > Good luck, Marek
> >
> > Thanks,
> > Ondra
> > _______________________________________________
> > seam-dev mailing list
> > seam-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/seam-dev
>
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>
--
Daniel Hinojosa
Programmer, Instructor, and Consultant
dhinojosa(a)evolutionnext.com
http://www.evolutionnext.com
http://www.abqjug.org
13 years, 6 months
