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
Is @Specializes transitive?
by Mark Struberg
Hi folks!
I have the following situation and couldn't find a _clear_ answer to my question (various hints, but as I said: not really clear):
class CodiConfig
@Specializes
class Jsf1CodiConfig extends CodiConfig
@Specializes
class Jsf2CodiConfig extends Jsf1CodiConfig
If I
@Inject CodiConfig cc;
is it well defined in the spec that I must get Jsf2CodiConfig?
Imo it should be, but before I 'fix' this in OWB, I need an ok that this transitive behaviour is conform with the spec. And of course that Weld is behaving in the same way ;)
txs and LieGrue,
strub
14 years
Automatic non contextual injection using bytecode instrumentation
by Stuart Douglas
I just had an idea for something that I think would be rather cool,
and allow objects created using new to be injected automatically.
Conceptually it would look something like this:
@AutoInject
public class AccountService
{
private final Account account;
@Inject
private PaymentProcessor paymentProcessor;
AccountService(Account account)
{
this.account = account;
}
public void doPayment(double amount)
{
paymentProcessor.processPayment(account, amount);
}
}
We could then create the object using new and the fields will still be injected:
AccountService a = new AccountService(account);
a.doPayment(10);
To implement this will require a javaagent, which will modify the
bytecode of @AutoInject annotated classes as they are loaded, so that
the constructor bytecode looks up the values to inject and sets the
injected field values appropriately. Would this be something that is
worth putting into weld extensions?
Stuart
14 years
CDITCK-174 - ProcessObserverMethod type parameters
by Scott Ferguson
Hi Pete,
I'm looking at the TCK snapshot and at CDITCK-174, but I don't
understand the change. The original looks correct to me and I don't see
how the new change is supposed to work or why it was made.
In ProcessObserverMethodErrorTest, there's a listener:
public void observeObserverMethodForEventB(
@Observes ProcessObserverMethod<?,EventB> event
);
But the ProcessObserverMethod is defined as
public interface ProcessObserverMethod<T,X> {
public ObserverMethod<T> getObserverMethod();
public AnnotatedMethod<X> getAnnotatedMethod();
public void addDefinitionError(Throwable t);
}
In other words, "T" is the type of the event and "X" is the type of the
listener, but the observer flips those around.
I double checked with the latest weld and with cdi-api.sig, but it
doesn't look like the ProcessObserverMethod itself has changed.
Is there something I'm missing?
-- Scott
14 years
Weld's Performance
by Stuart Douglas
As most of you are probably aware I have been looking at performance issues this week, mainly focusing on memory usage and startup time. I have managed to get a fair bit done, and right now I can't really see anything that would give any more significant improvements (not all my changes have been merged into master, but they should be merged soon).
To give everyone an idea of where the performance is at now, and where it was, I did up a few quick tables, these were done using weld-se so there is no jbossas overhead.
Startup Time (Seconds)
Beans 1.0.1-Final 1.1.0.Beta1 Latest
500 4 4 2.1
1000 8 7 3
5000 140 89 8.5
10000 600+ 396 14
Memory Usage (Mb)
Beans 1.0.1-Final 1.1.0.Beta1 Latest
500 42 27 10
1000 82 53 19
5000 403 255 87
10000 ~800 507 172
As you can see, we have come a long way since weld 1.0.1 :-)
Stuart
14 years
@New beans
by Stuart Douglas
After doing some more profiling I think we can massively reduce startup time for a large number of beans.
At the moment we add an @New bean for every managed bean, while according to the spec I think this is only necessary for beans that are actually injected into an @New injection point. I performed a quick test where I removed the @New beans (and skipped the tests) and in the 5000 bean case it reduced the AS startup time form 90s to 60s (this is actually a 50% speedup as the AS takes 30s to start with a 5000 class deployment without weld), and reduces the memory usage by a further 20Mb (bringing the total saving so far to 100Mb). This speedup will probably be less for smaller deployment, because parts of the startup process are O(n^2) on the number of beans (in particular TypeSafeResolver.findMatching).
Is my interpretation of the spec correct? The spec actually says that these @New beans that do not match an injection point still exist but are disabled, which as far as I can tell is the same as just not creating them.
Stuart
14 years
Re: [weld-dev] A significantly negative article on Weld
by Mark Struberg
Sorry to drop in here, but I think there might be a conceptional problem. Why do we pickup each and every class as @Dependent? In most cases this is either unnecessary or even leads to AmbiguousResolutionExceptions.
I'd strongly favour to drop this and instead only pickup a bean as managed if it has a scope annotation or a few other very limited cases. This would also highly increase startup time imo...
LieGrue,
strub
--- On Wed, 11/10/10, Stuart Douglas <stuart.w.douglas(a)gmail.com> wrote:
From: Stuart Douglas <stuart.w.douglas(a)gmail.com>
Subject: Re: [weld-dev] A significantly negative article on Weld
To: "Pete Muir" <pmuir(a)bleepbleep.org.uk>
Cc: "Samuel Mendenhall" <samuel.mendenhall(a)gmail.com>, "Weld Dev List" <weld-dev(a)lists.jboss.org>
Date: Wednesday, November 10, 2010, 9:12 AM
I just ran some very quick and dirty profiling with the latest Jbossas and the results are as follows:
Beans
Startup Time
Startup (WELDX)
Memory Usage
Mem Usage(no beans.xml)
No Deployment
17
135
20
20
22
149
500
24
26
178
2000
35
43
265
5000
87
104
440
210
So jboss uses 135Mb normally, and 210Mb when a war with 5000 classes is deployed that does not have beans.xml. When you add weld to the mix the memory usage jumps by 230Mb to 440Mb.
According to yjp WeldClassImpl (and it's retained WeldMethod/Field etc) is responsible for 120Mb of this. Other major culprits seem to be TypeSafeObserverResolver at 24Mb (as it is caching ProcessAnnotatedType<Bean*> * 5000) and TypeSafeDecoratorResolver at 13Mb. Not much else stands out.
The beans used where quite simple (1 injection point, 7 fields, 6 methods), no normal scoped beans, no interceptors, not decorators. Weldx does have a notable effect on startup time, which I will also investigate.
I don't think it will be to hard to significantly reduce this. Reducing the number of HashMap's in WeldClassImpl (and replacing some with ImmutableArraySet) should give a significant gain, and clearing the TypeSafeObserverResolver and TypeSafeDecoratorResolver after startup should also save around 40Mb. I'll try and do some work this week and see how much I can get this down.
Stuart
On 10/11/2010, at 8:48 AM, Pete Muir wrote:
I'm about to post a blog about this.
On 9 Nov 2010, at 21:43, Lincoln Baxter, III wrote:
Are these points valid?
If so, are we aware of them? Just trying to raise awareness to what people are saying out in the world. I have noticed a relatively high memory footprint in Seam Forge, using Weld SE.
http://www.dzone.com/links/r/cdi_a_major_risk_factor_in_java_ee_6.html
Is there anything we can address here and attempt to demystify this blog?
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
-----Inline Attachment Follows-----
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
14 years
Re: [weld-dev] A significantly negative article on Weld
by Mark Struberg
Yes, you can either do it via an Extension or much easier via a @Produces method ;)
In any case, it wont work without adding code or configuration!
LieGrue,
strub
--- On Wed, 11/10/10, Dan Allen <dan.j.allen(a)gmail.com> wrote:
From: Dan Allen <dan.j.allen(a)gmail.com>
Subject: Re: [weld-dev] A significantly negative article on Weld
To: "Clint Popetz" <cpopetz(a)gmail.com>
Cc: "Mark Struberg" <struberg(a)yahoo.de>, "Samuel Mendenhall" <samuel.mendenhall(a)gmail.com>, "Pete Muir" <pmuir(a)bleepbleep.org.uk>, "Weld Dev List" <weld-dev(a)lists.jboss.org>
Date: Wednesday, November 10, 2010, 9:01 PM
On Wed, Nov 10, 2010 at 3:52 PM, Clint Popetz <cpopetz(a)gmail.com> wrote:
If you go that route, you lose the ability to inject instances of
third party classes without defining a @Produces method. That may be
preferable to the existing problems caused by default @Dependents, but
I wanted to point it out for clarity.
Actually, there is one other approach to registering a class from a non-bean archive (no beans.xml), which is used in Weld Extensions. You can add the annotated types explicitly in an extension:
void beforeBeanDiscovery(@Observes BeforeBeanDiscovery event, BeanManager beanManager) { event.addAnnotatedType(beanManager.createAnnotatedType(BeanIAm.class));
}
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
14 years
Re: [weld-dev] A significantly negative article on Weld
by Stuart Douglas
FYI my memory usage branch can be found here: https://github.com/stuartwdouglas/core/tree/memoryUsage
With the last lot of changes to WeldClassImpl memory usage is down by about 60Mb ( ~30%) for the 5000 class benchmark. The fields that I have removed are only used at startup of during de-serialisation.
The effect on startup time is not noticeable, and I think that cost of de serialisation will be significantly higher than any overhead imposed by these changes, although I have not benchmarked this yet.
There is still plenty more that can be done here, I think reducing the memory usage by 50% should be easily achievable.
Stuart
On 10/11/2010, at 9:57 PM, David Allen wrote:
> Stuart,
>
> Excellent! There shouldn't be too many hash maps left in WeldClassImpl. Most of these have already been replaced with array set implementations; the ones left are a bit more complicated to replace due to use cases.
>
> Pete also wanted to redo the reflection data that we maintain and cache. It should be possible to release most of this cached data after bootstrapping the app. As it is now, everything is kept in memory permanently with the app which really isn't necessary.
>
> I'm supposed to be working on this, but I don't think I'll have much time till January 2011 to really do much. Keep us posted and I'll try to take a look on weekends or whenever I have a little time.
>
> Thanks,
>
> David
>
> On Wed, Nov 10, 2010 at 11:12 AM, Stuart Douglas <stuart.w.douglas(a)gmail.com> wrote:
> Clearing the resolvers after startup saves about 42Mb in the 5000 bean case (~20% of the memory attributable to weld, and ~10% of total memory usage).
>
> Stuart
>
>
> On Wed, Nov 10, 2010 at 8:12 PM, Stuart Douglas <stuart.w.douglas(a)gmail.com> wrote:
>
> I just ran some very quick and dirty profiling with the latest Jbossas and the results are as follows:
>
>
> Beans Startup Time Startup (WELDX) Memory Usage Mem Usage(no beans.xml)
> No Deployment 17 135
> 20 20 22 149
> 500 24 26 178
> 2000 35 43 265
> 5000 87 104 440 210
>
>
> So jboss uses 135Mb normally, and 210Mb when a war with 5000 classes is deployed that does not have beans.xml. When you add weld to the mix the memory usage jumps by 230Mb to 440Mb.
>
> According to yjp WeldClassImpl (and it's retained WeldMethod/Field etc) is responsible for 120Mb of this. Other major culprits seem to be TypeSafeObserverResolver at 24Mb (as it is caching ProcessAnnotatedType<Bean*> * 5000) and TypeSafeDecoratorResolver at 13Mb. Not much else stands out.
>
> The beans used where quite simple (1 injection point, 7 fields, 6 methods), no normal scoped beans, no interceptors, not decorators. Weldx does have a notable effect on startup time, which I will also investigate.
>
> I don't think it will be to hard to significantly reduce this. Reducing the number of HashMap's in WeldClassImpl (and replacing some with ImmutableArraySet) should give a significant gain, and clearing the TypeSafeObserverResolver and TypeSafeDecoratorResolver after startup should also save around 40Mb. I'll try and do some work this week and see how much I can get this down.
>
> Stuart
>
> On 10/11/2010, at 8:48 AM, Pete Muir wrote:
>
>> I'm about to post a blog about this.
>>
>> On 9 Nov 2010, at 21:43, Lincoln Baxter, III wrote:
>>
>>> Are these points valid?
>>>
>>> If so, are we aware of them? Just trying to raise awareness to what people are saying out in the world. I have noticed a relatively high memory footprint in Seam Forge, using Weld SE.
>>>
>>> http://www.dzone.com/links/r/cdi_a_major_risk_factor_in_java_ee_6.html
>>>
>>> Is there anything we can address here and attempt to demystify this blog?
>>>
>>> --
>>> Lincoln Baxter, III
>>> http://ocpsoft.com
>>> http://scrumshark.com
>>> "Keep it Simple"
>>> _______________________________________________
>>> weld-dev mailing list
>>> weld-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>>
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>
>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>
14 years
