gmane.comp.java.cdi.weld.devel

Re: Weld branches

Jozef Hartinger — 2013-05-23T11:54:43

That is basically what's happening. The only difference is that the new 
master branch will not appear immediately but sometime in June. I 
someone happens to miss this info and do a pull on their master branch 
in the meantime, a missing remote branch will be less confusing than a 
huge conflict.

On 05/23/2013 01:39 PM, Stuart Douglas wrote:

Re: Weld branches

Stuart Douglas — 2013-05-23T11:39:58

Why not just start a new master based off 2.0, and remove the 2.0 
branch? It does not look like the current master branch will get much 
adoption, and this would make weld consistent with pretty much every 
other JBoss project.
Stuart

Jozef Hartinger wrote:

Weld branches

Jozef Hartinger — 2013-05-23T11:27:42

Team,

there are currently three main branches for Weld Core:

- 1.1 - the Weld 1.1 branch used in JBoss AS 7, JBoss EAP and other EE6 
application servers
- master - Weld 1.2 - basically the 1.1 branch with weld-osgi on top
- 2.0 - Weld 2.0 (CDI 1.1 implementation)

This is confusing as git users usually expect to find the latest and 
greatest in the master branch which is not the case for Weld. Therefore, 
I am going to rename the master branch to a more appropriate name - 
"1.2". If you do any work on the current master branch make sure to 
apply your changes to "1.2" from now on.

A new master branch will be added eventually when we start working on 
Weld 2.1. In the meantime there will be no branch named "master".

Jozef

Re: Remove JSF from Weld Core?

Jozef Hartinger — 2013-05-22T14:53:34

OK, that sounds reasonable. https://issues.jboss.org/browse/WELD-1429

On 05/21/2013 02:03 PM, ssilvert-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org wrote:

Re: Remove JSF from Weld Core?

2013-05-21T12:03:29

It all has to do with the way Multi-JSF works[1].  The JSF subsystem
figures out which version of JSF the app wants to use.  Then it adds
that version to the deployment.  For each JSF version, we need a group
of modules that are hard-wired together in their respective module.xml
files.  We can't add something to the deployment that depends on the
wrong JSF version.

So that's why we want to limit the number of modules that declare a
dependency on JSF.  It makes for less modules to install when we install
a new JSF version.  Right now, there are three modules needed for a new
JSF version.  They are jsf-api, jsf-impl, and jsf-injection.  For
weld-jsf, I will probably place its artifact in the same module as the
jsf-injection artifact.  That seems like a logical place for it to
live.  Thus, we keep the number required JSF modules per version at three.

I don't think it's wise to just do this with all of Weld Core.  Lots of
other modules depend on Weld Core.  Most of them (all of them?) don't
care about Weld/JSF classes.  But if some module did care about Weld/JSF
classes, we would need to make sure that this module loads those classes
in a way that is compatible with Multi-JSF.  It would get pretty hairy.

[1] https://community.jboss.org/wiki/DesignOfAS7Multi-JSFFeature

Re: Remove JSF from Weld Core?

Jozef Hartinger — 2013-05-21T09:05:46

Hi Stan,

it is not a problem to separate the code that depends on JSF into a 
separate artifact. However, it is unclear to me how that changes the 
situation in WF. How will the JSF dependency of the new artifact (let's 
call it weld-jsf) be setup in WildFly? Could we not use the same 
mechanism to setup the JSF dependency of the current weld-core artifact 
in the first place? (instead of the hard-coded dependency on JSF API you 
mentioned)?

Jozef

On 05/20/2013 06:32 PM, ssilvert-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org wrote:

Remove JSF from Weld Core?

2013-05-20T16:32:55

Hi Guys,

I'd like to get your thoughts on the possibility of removing JSF
dependencies from Weld Core and putting them in their own artifact.  The
reason I want to do this is so that in WildFly we can more easily allow
Weld JSF classes to work with multiple JSF versions.

As it is now, Weld Core has a hard-coded dependency on the single JSF
version that ships with WildFly.   So whether someone uses the Multi-JSF
feature or uses WAR_BUNDLES_JSF_IMPL, you can get Linkage errors when
trying to use Weld Core.

rest of Weld Core.  Instead they are instantiated via the Weld
subsystem's inclusion of the ConversationAwareViewHandler in its
faces-config.xml.

The only part of Weld Core that "sort of" uses a JSF dependency is
BeanDeployment.  This instantiates an instance of JsfApiAbstraction and
registers it the Weld ServiceRegistry.  JsfApiAbstraction is only there
to determine the JSF spec version.  But I haven't been able to find
anywhere it is actually used in the wild.

Specifically, I would like to move the org.jboss.weld.jsf package into
its own jar artifact. 
org.jboss.weld.servlet.ConversationPropagationFilter would go in there
too.   Weld Core would then list the new artifact as a dependency so as
not to break backward compatibility.

If you think it's a good idea I'll be glad to do the work to make it
happen.  Please let me know.

Thanks,

Stan

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 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

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.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
Caused by: 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.weld.bootstrap.ConcurrentValidator$5.doWork(ConcurrentValidator.java:133)
at org.jboss.weld.bootstrap.ConcurrentValidator$5.doWork(ConcurrentValidator.java:129)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_15]
at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_15]
... 3 more

Do you know where this comes from and how one can solve it?

Cheers,

Daniel

Am 18.03.2013 um 15:41 schrieb Jozef Hartinger <jharting-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>:


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

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: