Improving the performance of weld for micro-deployments.
by Lincoln Baxter, III
Hi Jozef, Stuart, and Weld-devs,
In Forge 2 we are using Weld extensively, and one of the things we do is
start up many instances simultaneously.
We may have anywhere from one to one-hundred or more weld instances.
Currently we have only seen around 10-12 instances, and performance is
"Okay", but in theory, we could see hundreds of instances, at which point,
performance starts to be a concern. We're working around this problem by
disabling CDI support on some internal addons, but... it's not really
reasonable to expect that everyone will do this.
Which means... we need to figure out how to shave as much time off the
bootstrap as possible. Currently each weld instance takes anywhere from
80ms to 450ms to start (not really sure why such variation yet,) and we'd
hopefully like to get that down even lower, around 10-20ms. Classloading
time only would be optimal, but obviously difficult to achieve.
How can we get the most speed out of Weld? Most of our deployments have
only ~15 bean classes at most. It seems like a lot of time (~30-40%) is
being spent in the Google concurrent collections.
(Screenshot attached.)
Thanks,
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
10 years, 8 months
[OSGi] How to deal with CDI extensions in other bundles
by Guillaume Nodet
I'm trying to have CDI and OSGi work well together and I'm trying to deploy
DeltaSpike in OSGi.
Doing so, I'm hitting https://issues.jboss.org/browse/WELD-1309
I wonder if any of the CDI / OSGi guys around have already thought about
the problem.
So sum up, the problem is how to package / use CDI extensions in OSGi.
DeltaSpike provide some bundles which can be deployed, but they don't work
well in OSGi. The reason is that a lot of the CDI stuff assume a flat
classloader. The Weld-Osgi project tries to make that work better but
there are still problems:
* extension discovery: atm, the META-INF/services declaration for
extensions are only found in the bundle, not in other bundles
* only classes from the bundle are considered as beans, not classes that
may be part of the extension
I would think, we want extensions to be specifically declared for a given
bundle : we need to know for a given bundle which extensions should be
loaded. I've trying so far by doing discovery of beans and extensions
using the bundle classloader and the classloaders of required bundles. It
seems to work, but I'm not really sure it's the way to go, especially I'm
not sure that all beans defined by a bundle which is an extension should be
added to the bundle using that extension (the extension being itself a
bundle can already have its own CDI container).
Thoughts ?
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
10 years, 8 months
Problem with beanManager.getReference(InjectionPoint, CreationalContext)
by Lincoln Baxter, III
Hey all,
I have a problem with "Faking an injection point," with the current Weld 2
code, seems to be throwing an NPE instead of using the InjectionPoint that
I am providing the BeanManager with.
This can be reproduced right now by checking out the forge core repository
branch 2.0. Just run, mvn clean install.
https://github.com/forge/core/tree/2.0
The crux of the matter, we have a producer method in a CDI instance A:
@Produces
public static Coverter<?,?> produceRemoteConverter(AddonRegistry registry,
InjectionPoint ip)
There are, however, no injection points actually consuming this
type/producer method from within CDI instance A. (And adding one would not
really help.)
In CDI instance, B, however, we are using the following code, with a
reference to the BeanManager from CDI instance A, to get an instance of a
Converter:
Bean<R> bean = (Bean<R>) manager.resolve(manager.getBeans(type));
context = manager.createCreationalContext(bean);
Object delegate = manager.getInjectableReference(injectionPoint, context);
We have an InjectionPoint for the Converter type in CDI instance B, and are
delegating to container A to get the instance (using an extension.)
However, even though we are passing in our own InjectionPoint(B) into CDI
instance A, CDI instance A still tries to look up the InjectionPoint on its
internal stack, and throws a NullpointerException.
I think this is a bug, since InjectionPoint is an interface, (but obviously
very edge case if so.)
Any help would be appreciated. Otherwise, we have no way to support looking
up beans for types which are produced with Producer Methods requiring an
injection point (those without work fine, and normal type lookups obviously
work fine.)
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
10 years, 8 months
Weld Servlet 2.0.0.Beta2 Issue
by Luigi Bitonti
Hi All,
I am "playing" with Weld Servlet 2.0.0.Beta2, deploying a JSF application to Tomcat 7.0.32 and I believe I've found 2 issues.
1) If use weld-servlet as artifact in Maven, i.e.
...
<dependency>
<groupId>org.jboss.weld.servlet</groupId>
<artifactId>weld-servlet</artifactId>
<version>2.0.0.Beta2</version>
...
the presence of the el-api classes in the jar prevents the application from deploying, as the classes are already present in Tomcat. The exception is as follows:
01-Jan-2013 13:44:53 org.apache.catalina.loader.WebappClassLoader validateJarFile
INFO: validateJarFile(E:\devel\java\tomcat\apache-tomcat-7.0.32\webapps\palindrome-weld2-jsf\WEB-INF\lib\weld-servlet-2.0.0.Beta2.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: javax/el/Expression.class
01-Jan-2013 13:44:54 org.apache.catalina.core.StandardContext startInternal
SEVERE: Error listenerStart
01-Jan-2013 13:44:54 org.apache.catalina.core.StandardContext startInternal
2) If I use weld-servlet-core, so that I can exclude the el-api jar like this:
...
<dependency>
<groupId>org.jboss.weld</groupId>
<artifactId>weld-core</artifactId>
<version>2.0.0.Beta2</version>
<exclusions>
<exclusion>
<groupId>javax.el</groupId>
<artifactId>el-api</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.jboss.weld.servlet</groupId>
<artifactId>weld-servlet-core</artifactId>
<version>2.0.0.Beta2</version>
<exclusions>
<exclusion>
<groupId>javax.el</groupId>
<artifactId>el-api</artifactId>
</exclusion>
</exclusions>
</dependency>
...
I get the following error at application deployment:
SEVERE: Exception sending context initialized event to listener instance of class com.sun.faces.config.ConfigureListener
java.lang.RuntimeException: com.sun.faces.config.ConfigurationException:
Source Document: jar:file:/E:/devel/java/tomcat/apache-tomcat-7.0.32/webapps/palindrome-weld2-jsf/WEB-INF/lib/weld-servlet-core-2.0.0.Beta2.jar!/META-INF/faces-config.xml
Cause: Unable to find class 'org.jboss.weld.jsf.WeldPhaseListener'
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:292)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4791)
...
The JSF phase listener existed in weld 1.x but has been removed from weld 2.x. If I edit the faces-config.xml file and remove the phase listener reference everything works as expected. I checked github and the latest version of faces-config.xml has still got a reference to the missing class.
I hope this makes sense. Apologies if this is not the right mailing list for this message, or if it's a duplicate (I searched but I could not find anything similar).
Cheers,
Luigi
10 years, 9 months