gmane.comp.java.cdi.weld.devel

Re: Windup - migration

Brad Davis — 2013-05-06T12:34:42

We have started some rules related to Seam to CDI, but could always use more contributions.

See:
https://github.com/windup/windup/blob/master/windup-rules/src/main/resources/windup/java/java-seam-to-cdi.windup.xml

Brad Davis
Red Hat Consulting
Email: bdavis-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org | c: 980.226.7865 | http://www.redhat.com 


----- Original Message -----
From: "Pete Muir" <pmuir-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>
To: seam-dev-owner-yyZXR9kdEHCUeimprIcsAw< at >public.gmane.org, "Weld-Dev List" <weld-dev-yyZXR9kdEHCUeimprIcsAw< at >public.gmane.org>, "Brad Davis" <bdavis-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>
Cc: "Rebecca Searls" <rsearls-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>
Sent: Monday, May 6, 2013 8:29:01 AM
Subject: Windup - migration

Hi all,

Brad Davis has created a great tool called Windup. Windup can create a migration report, which highlights items which will need changing, provides suggested changes, and estimates the effort involved. It uses rulesets to do this, and the set of ru

Windup - migration

Pete Muir — 2013-05-06T12:29:01

Hi all,

Brad Davis has created a great tool called Windup. Windup can create a migration report, which highlights items which will need changing, provides suggested changes, and estimates the effort involved. It uses rulesets to do this, and the set of rules is extensible e.g. https://github.com/windup/windup/blob/master/windup-rules/src/main/resources/windup/java/java-persistence-config.windup.xml

It would be great to start building a Seam 2 -> Java EE 6 migration ruleset.

Pete

Weld 2.0.0.Final released

Jozef Hartinger — 2013-04-25T14:20:09

http://in.relation.to/Bloggers/Weld200FinalReleased

Re: Weld 2.0.0.Beta6 released

Jozef Hartinger — 2013-03-22T11:12:56

Hi Daniel,

please file an issue at https://issues.jboss.org/browse/WELD. If 
possible include the sample application for us to be able to reproduce 
easily.

Jozef

On 03/19/2013 08:59 PM, Daniel Sachse wrote:

_______________________________________________
weld-dev mailing list
weld-dev-yyZXR9kdEHCUeimprIcsAw< at >public.gmane.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: Weld 2.0.0.Beta6 released

Daniel Sachse — 2013-03-19T19:59:10

Hey all,

I just tried JBoss AS 7.1.1 with Weld 2.0.0.Beta3 and Weld 2.0.0.Beta6, JBoss EAP 6.1 Alpha 1 with Weld 2.0.0.Beta6 and I have encountered the following issue when deploying a small sample application:

20:55:52,495 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-14) MSC00001: Failed to start service jboss.deployment.unit."Foodeys.war".WeldService: org.jboss.msc.service.StartException in service jboss.deployment.unit."Foodeys.war".WeldService: org.jboss.weld.exceptions.DeploymentException: WELD-001414 Bean name is ambiguous. Name csfFLOWDISCOVERYCDIHELPER resolves to beans [Managed Bean [class com.sun.faces.flow.FlowDiscoveryCDIHelper] with qualifiers [< at >Default < at >Named < at >Any], Managed Bean [class com.sun.faces.flow.FlowDiscoveryCDIHelper] with qualifiers [< at >Default < at >Named < at >Any]]
at org.jboss.as.weld.services.WeldService.start(WeldService.java:84)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.j

Weld 2.0.0.Beta6 released

Jozef Hartinger — 2013-03-18T14:41:09

Hi all,

Weld 2.0.0.Beta6 has been released. We are not quite yet at being a 
feature-complete implementation of CDI 1.1 but we are getting there. You 
can test it yourself if you take JBoss EAP 6.1 Alpha (from 
http://www.jboss.org/jbossas/downloads/) and patch it using Weld 2 
installer from here https://github.com/weld/as7-weld-subsystem (use the 
2.0.0.Beta6 tag).

Jozef

Re: [jira] [Commented] (DELTASPIKE-113) Review andDiscuss ServiceHandlers

Mehdi Heidarzadeh — 2013-02-08T08:08:47

Hi all lovely developers,
Please sign this petition to ask Larry Ellison to remove Ask Toollbar
bundled into JDK installation.
Oracle Corporation: Stop bundling Ask Toolbar with the Java installer
<https://www.change.org/petitions/oracle-corporation-stop-bundling-ask-toolbar-with-the-java-installer>
Also please ask all your friends and mailing lists you know.
Thanks

Re: Improving the performance of weld formicro-deployments.

Jozef Hartinger — 2013-01-30T11:33:59

Later this week. It is staged actually already so you can try it if you 
do not mind using the staging repository.

On 01/29/2013 11:33 PM, Lincoln Baxter, III wrote:

_______________________________________________
weld-dev mailing list
weld-dev-yyZXR9kdEHCUeimprIcsAw< at >public.gmane.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: Improving the performance of weld formicro-deployments.

Martin Kouba — 2013-01-30T10:43:28

Dne 29.1.2013 23:33, Lincoln Baxter, III napsal(a):

This is normal for the default ExecutorServices impl
(org.jboss.weld.executor.FixedThreadPoolExecutorServices). You can
change the impl - set the "threadPoolType" option either to
SINGLE_THREAD or FIXED_TIMEOUT (see the doc link Jozef's pointing at).

Re: [forge-dev] Improving the performance of weld for micro-deployments.

Ståle W. Pedersen — 2013-01-30T08:54:07

when we profile as7/eap6 we've often use oprofile since it seems more
accurate regarding finding the correct hotspots and it isnt as intrusive
as jprofiler/yourkit. then we often use jprofiler to look at
call-graphs, blocking threads, etc.

ståle

On Tue 2013-01-29 17:30, Lincoln Baxter, III wrote:

Re: Improving the performance of weld formicro-deployments.

Stuart Douglas — 2013-01-29T23:18:55

If you look at the back traces in the profiler it should tell you what 
is calling it.

Stuart

Lincoln Baxter, III wrote:

Re: Improving the performance of weld formicro-deployments.

Lincoln Baxter, III — 2013-01-29T22:37:25

Okay, good to know. What kind of info would you need to get into things?

Also, any idea why the report says that my Bootstrap.main(String[]) is
called over 1000 times? Seems a bit odd to me. This method literally does a
little string parsing, then calls starts Forge in a Thread (and waits for
that thread to finish.)


On Tue, Jan 29, 2013 at 5:33 PM, Stuart Douglas
<stuart.w.douglas-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>wrote:

Re: Improving the performance of weld formicro-deployments.

Lincoln Baxter, III — 2013-01-29T22:33:56

Thanks Jozef,

When will Beta3 be out?

Also, I've noticed that weld-worker threads are left hanging around after
weld has started. Is this normal? Is it possible that the weld Executor is
being left running un-intentionally?


On Tue, Jan 29, 2013 at 4:49 PM, Jozef Hartinger <jharting-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>wrote:

Re: Improving the performance of weld formicro-deployments.

Stuart Douglas — 2013-01-29T22:33:43

Tracing is pretty useless at identifying slow parts, as the overhead it 
adds distorts the profile too much. The only thing it is really good for 
is identifying methods that are called too often.

Sampling is generally much better.


Stuart

Lincoln Baxter, III wrote:

Re: Improving the performance of weld formicro-deployments.

Lincoln Baxter, III — 2013-01-29T22:30:45

What kind of information do you need? I was unable to get YourKit to dump a
.snapshot file for some reason. If that's what you need, I can try again.
Which profile mode? This was done using tracing.

Thanks!


On Tue, Jan 29, 2013 at 4:32 PM, Stuart Douglas
<stuart.w.douglas-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>wrote:

Re: Improving the performance of weld formicro-deployments.

Jozef Hartinger — 2013-01-29T21:49:09

I worked on Weld's bootstrap performance about 6 months ago but the 
focus was mainly on large deployments. I am not aware of any obvious 
bottlenecks that would get into the way of micro deployments. If you 
could do a further analysis that would be great.

As for guava showing up in the stats, a lot of work Weld does is done 
within computing maps (e.g. reading metadata using reflection, etc.) so 
you would need to get more in depth here.

Weld uses its own thread pool for concurrent loading, deployment and 
validation of beans. Furthermore, there is a service that pre-resolves 
extension observer methods in multiple additional threads. The thread 
pool sizes default to a configuration that should utilize the most of 
CPU in cases when a single Weld instance is running. However, in your 
environment where multiple Weld instances are booting at the same time 
this may actually harm performance. As a first step I would suggest 
disabling concurrent deployment and the preloader or playing with thread 
pool si

Re: Improving the performance of weld formicro-deployments.

Stuart Douglas — 2013-01-29T21:32:41

The screenshot does not really tell us much. We would need to see the 
actual profile information.

Stuart

Lincoln Baxter, III wrote:

Improving the performance of weld for micro-deployments.

Lincoln Baxter, III — 2013-01-29T18:19:03

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

Re: [OSGi] How to deal with CDI extensions in otherbundles

Ales Justin — 2013-01-23T14:22:17

I'm actually just in the process of going over all existing Weld-OSGi issues, and will check this one as well.
I'll ping you for any help / questions, if that's OK?

-Ales

On Jan 23, 2013, at 3:15 PM, Guillaume Nodet <gnodet-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:


_______________________________________________
weld-dev mailing list
weld-dev-yyZXR9kdEHCUeimprIcsAw< at >public.gmane.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[OSGi] How to deal with CDI extensions in other bundles

Guillaume Nodet — 2013-01-23T14:15:36

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

Re: Problem with beanManager.getReference(InjectionPoint,CreationalContext)

Jozef Hartinger — 2013-01-12T19:36:35

Hi Lincoln,

can you provide a stack trace? I tried reproducing as described but I 
only see a NPE being thrown from Maven so I assume I am observing 
something else. What you do should work. Please file a Weld issue.

Btw, is there a reason why you need to "fake" the InjectionPoint?. Since 
you have a Bean object and a CreationalContext object available in your 
code you can obtain a contextual reference using the 
BeanManager.getReference() method without faking the IP.

JH

On 01/11/2013 11:27 PM, Lincoln Baxter, III wrote:

_______________________________________________
weld-dev mailing list
weld-dev-yyZXR9kdEHCUeimprIcsAw< at >public.gmane.org
https://lists.jboss.org/mailman/listinfo/weld-dev