Adding Classes at Run-time
by Jason Lee
I have an odd question. I have a situation where I'm manually opening a
JAR and adding its classes to the ClassLoader. What I'd like to be able
to do is have Weld scan these classes for any relevant annotations and
take the proper actions, just as if the JARs were in the classpath when
the application started. I've been staring at the JavaDocs (build
locally, btw, as I can't find them on the web :| ) but I don't see any
way to request that Weld inspect a given class. Is it there and I'm
missing it? Am I going to have cobble together that functionality? Am
I asking for something that can't be done (right now)? Any nudges in
the right direction would be much appreciated. :)
--
Jason Lee, SCJP
President, Oklahoma City Java Users Group
Senior Java Developer, Sun Microsystems
http://blogs.steeplesoft.com
12 years, 6 months
CR1 of TCK 1.0.1 available
by Pete Muir
All,
I have tagged 1.0.1 CR1, and pushed it to both Maven and SourceForge (just waiting for the various servers to sync...).
Thanks to Gurkan and Mark (from OWB), Vivek, Santiago, Hong, Jitendra, Kyle and Roger (from Sun) for assiduously reporting issues. And also to David, Jozef and Marius for fixing them :-)
These release of TCK contains no known issues, and only excludes tests which are still failing in Weld.
We'll release 1.0.1 in two weeks, which I hope will have no excludes!
Best,
Pete
14 years, 9 months
Re: [weld-dev] [seam-dev] Replacing pages.xml
by Stuart Douglas
find . | grep xhtml | wc
392 392 21192
It's going to be a big enum... we would need to make sure that you could split it up.
The only real problem I have with this approach is that all the metadata that is availible is hard coded into the page class, which means the page class has to know about every module that wants to use page level metadata. Also, you can't really configure it via xml, which I am not too worried about but may alienate some users.
Stuart
On 19/02/2010, at 4:40 PM, Gavin King wrote:
> You should even be able to make this work:
>
> @View(.....)
> login {
> @Inject Login loginBean;
> public MyAppPage next(MyAppPage page, Object outcome) {
> if ( loginBean.isLoggedIn() )
> return main;
> else
> return login;
> }
> },
>
> of course we would need a little infrastructure for injecting into enum values.
>
> On Thu, Feb 18, 2010 at 11:37 PM, Gavin King <gavin.king(a)gmail.com> wrote:
>> Oops, this is a MUCH better way to write this code:
>>
>>
>> public enum MyAppPage implements Page<MyAppPage> {
>>
>> @View(.....)
>> login {
>> public MyAppPage next(MyAppPage page, Object outcome) {
>> if (Boolean.TRUE.equals(outcome))
>> return main;
>> else
>> return login;
>> }
>> },
>>
>> @View(.....)
>> main {
>> public MyAppPage next(MyAppPage page, Object outcome) {
>> return main;
>> }
>> },
>>
>> @View(.....)
>> logout {
>> public MyAppPage next(MyAppPage page, Object outcome) {
>> return login;
>> }
>> };
>>
>> }
>>
>
>
>
> --
> Gavin King
> gavin.king(a)gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
14 years, 9 months
Generic Beans
by Stuart Douglas
I have been looking into Gavin's ideas for generic beans, as specified at http://seamframework.org/Weld/PortableExtensionsPackage, and I have come up with a simple prototype. The details of the implementation is as follows:
- All AnnotatedTypes marked @Generic are vetoed and their details stored for later use.
- All beans that have a generic producer field have the details of the Generic annotation value stored
- after bean discovery a new bean is registered for every @Generic annotation type and every instance of the Generic annotation on a producer field. So in the example on the wiki page six beans would be registed, 3 Topics and 3 sessions, one each for 'default', 'prices' and 'deals'. these beans have a synthetic qualifier annotation added to them that only the PE knows about. Also at this point any @InjectGeneric on the annotated type is replaced with @Inject @SyntheticQualifier(value=?) so that generic beans can inject other generic beans.
- The injectionTarget for beans with a generic producer field is wrapped to set the initial value.
The prototype contains a simple test, it contains two generic beans, GenericMain and GenericDep, both are generic on TestAnnotation. GenericDep is injected into GenericMain which is then exposed via a producer field in GenericProducer and injected into InjectedBean. GenericDep injects an instance of TestAnnotation as configuration.
Could someone have a look at this and let me know if this approach is ok? (In order to build it you may need to get the most recent weld-extensions from svn)
Stuart
14 years, 9 months
A few thoughts on a caching support SPI
by Mark Struberg
Hi folks!
After doing lots of profiling in OpenWebBeans in the last few days, I really feel that we should introduce some common caching mechanism in the Context interface.
Let's start from the beginning.
1.) The first hotspot I experienced while profiling was that each EL-Expression is going all the way down and resolving a Bean<T> for the injection point (which is btw even more expensive, if we cannot find anything because it's e.g. a i18n resource EL of JSF which will only be resolved later in the EL chain) . This should be cacheable pretty well inside the container already, so there is nothing to do on SPI side.
2.) Another much harder to solve hotspot are the MethodHandlers of our bean proxies. Whenever you inject a NormalScoped bean, a proxy (aka contextual reference) will introduced itself. And for each method invocation on that very bean proxy, we need to go deep into the container, first looking up the right Context, and then ask the Context for the contextual instance. This happens really often and is not a cheap operation. Additionally, having to always go to the center of our application will basically serialize all operations through this very bottle neck. Thus I fear this approach will not scale well on systems with lots of CPUs.
Here is my suggestion:
I will try to explain from the most simple scenario up to the most complicated:
A) Let's look at an @ApplicationScoped contextual reference. The injected proxy instance at an injection point of that bean could simply remember the contextual instance once it got resolved for the first time (and after it was resolved again if it got lost by serialization):
public class AppScopedBeanMethodHandler<T> implements MethodHandler {
private transient volatile T theInstance == null;
private Bean<T> bean;
public Object invoke(Object instance, Method method, Method proceed, Object[] arguments) throws Exception {
if (theInstance == null) {
// resolve contextual instance of bean from Context
}
return proceed(theInstance, ..);
}
(Sidenote: I'm not 100% sure if we really need make it volatile, because in worst case - if another Core/CPU L1 cache doesn't see the variable set - it will get resolved number of cores times at maximum. And not making it volatile would even remove the cache writeback load. Not sure if it pays of though.)
B) It gets a bit more complicated for a @SessionScoped bean, because a Session will get created/closed and multiple of them may exist at the same time. But we still like to cache the resolved contextual instance in the MethodHandler for this scope. Thus, we have to somehow invalidate this cache of course! Since an active invalidation is not really practicable, we could simply ask the Context for the sessionId. And if the current sessionId is still the same as the one we got at the time we created the cached instance, then we can easily use that cached instance. Otherwise we have to ask the container to resolve the bean. Since there may be multiple sessions active at the same time, we should use a ThreadLocal for the cache (in fact caching one contextual instance per thread).
This is necessary since e.g. a contextual reference of a @SessionScoped bean injected into an @ApplicationScoped bean may get called from n threads in parallel but each thread may resolve to another Session!
We may need a bit synchronization here, but it is far better to do this in n proxies (which don't block each other) than to do this in the central context (which would block all other beans of that context too).
C) A MethodHandler for a @ReqeustScoped bean is not much more complex. A concatenated ThreadId+Sytem.nanoTime() should do the trick for acting as unique requestId (need to check how expensive nanoTime is in praxis). Oh yes, please dont use the sessionId here, since it theoretically may get invalidated in the middle of a request.
The SPI Extension:
Until here, all of those tricks may be done internally in OpenWebBeans. But those optimizations would not be applicable for 3rd party Context implementations like my Context for the @javax.faces.bean.ViewScoped.
This would require extend the Context SPI to hand over an optional unique identifier for the current context situation. And if the Context makes such an id available, the NormalScopedBeanMethodHandler could use it to provide a pretty decent caching scenario out of the box.
Imo the strongest part in this scenario is not only that it reduces work to resolve the bean instances, but to heavily de-centralize the burden, and thus would scale vastly better than always having to go to the central instance storage.
So, can it really be that easy? I somehow have the feeling that I forgot something, wdyt? Candidates to think about for sure are synchronization, multi-tier classloader scenarios and garbage collection issues.
oki, blame me, tell me nuts or give me pet names, any comment is welcome ;)
txs and LieGrue,
strub
__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails.
http://mail.yahoo.com
14 years, 9 months
CDI support in JBoss Tools 3.1 CR2
by Max Rydahl Andersen
Hi,
CDI support been in the nightly builds of JBoss Tools for a while but is now enabled fully in the CR2 release.
See http://docs.jboss.org/tools/whatsnew/cdi/cdi-news-3.1.0.CR2.html and http://bit.ly/cgCvVI
"We now support Contexts and Dependency Injection (CDI/JSR-299) annotations and it works on any Eclipse Java project, you simply need to go to the Configure menu and enable CDI.
When enabled this gives you nice code completion in EL for @Named beans, allows you to easily navigate to @Injection points via Ctrl+Click or use search for references finds all occurrences where a named bean are used and if you have validation enabled on the project the project will be checked for certain errors in your CDI constructs giving you instant feedback. Refactoring of methods on CDI beans will be reflected in EL expressions. "
It covers the basics and we will be covering more going forward in the nightly builds - but now we at least got a good start :)
--
/max
14 years, 9 months
[TCK] Bug in Passivation Capable Dependency Test
by Gurkan Erdogdu
Tests under the following packages
org.jboss.jsr299.tck.tests.context.passivating.broken.decoratorWithNonPassivatingBeanConstructor
org.jboss.jsr299.tck.tests.context.passivating.broken.decoratorWithNonPassivatingInitializerMethod
org.jboss.jsr299.tck.tests.context.passivating.broken.decoratorWithNonPassivatingInjectedField
packages tests decorators injection points to check they are passivation capable dependency or not. Even if they are not passivation capable dependency, it is ok becuase "UnderWaterCity" class in all of the above tests has not passivated scope.
In other words, even if UnderWaterCity class implements SErializable, it does not define passivated scope therefore it is not necessary to check its interceotırs or decorators
Is this a bug?
Thanks;
--Gurkan
___________________________________________________________________
Yahoo! Türkiye açıldı! http://yahoo.com.tr
İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!
14 years, 9 months
Weld 1.0.1 and CDI TCK 1.0.1 timeline
by Pete Muir
All,
As previously discussed, we are aiming for a 10-12w release cycle of patch releases for Weld and for the CDI TCK. This means the 1.0.1 releases should happen around the 4th Feb.
To this end, the release schedules are:
CDI TCK
1.0.1.CR1: 21st January (Thursday this week)
1.0.1: 4th Feb
Weld
1.0.1.CR1: 28th January (Thursday next week)
1.0.1: 4th Feb
If you are working on issues for 1.0.1 please review the issues you are assigned, and check that you think you can make the CR1 dates above. If you can't, please ping me and we can either slip the issue to 1.0.1 or find some help for you.
Current assignments by the numbers are:
* Aslak - 1 issue (WELD-362)
* Dan - 2 issues (WELD-27, WELD-287)
* David - 3 issues (WELD-4, WELD-337, WELD-365)
* Marius - 10 issues (WELD-291, WELD-269, WELD-312, WELD-325, WELD-36, WELD-314, WELD-377, WELD-356, WELD-272, WELD-274)
* Nik - 4 issues (WELD-32, WELD-271, WELD-361, WELD-348)
* Roger - 5 issues (WELD-273, WELD-30, WELD-206, WELD-31, WELD-303)
* Shane - 1 issue (WELD-257)
* Stuart - 2 issue (WELD-335, WELD-309)
leaving
* Pete/Unassigned - 27 issues
Thanks!
Pete
14 years, 9 months
