As Ales says, Web Beans is being developed as a standalone project, it's not using the Seam codebase at all. We should probably rename the Seam deployer to seam2.deployer. Also, unlike Seam, Web Beans will be distributed as part of the app server, rather than as an application library. On 8 Jan 2009, at 14:00, Ales Justin wrote: >> How does that fit with the existing seam.deployer? > > What do you mean? > Those are 2 different things. ;-) > At least until Seam3, which is gonna be WB based. > > Although it's true that the concept is the same, > but it's the details that are very different: > - matching diff metadata files to determine deployment type > - adding different int libs > > And WB deployers do a lot more than just add int lib, > they add default metadata if we know deployment is WB: > - WB interceptor > - WB servlet listener > - isolated classloading > > There are some pieces I would like to make available for general > usage. > e.g. VDF integration layer: getting MC info from ServletContext's > attributes > I just need to find an appropriate place, and suggestions? > >> Pete Muir wrote: >>> I would like to discuss including the Web Beans RI in the next >>> release of JBoss 5. >>> >>> As Web Beans is quite young, I think we should include it as a >>> "Technology Preview". The included version should be at least >>> 1.0.0.ALPHA2, out in the next couple of weeks. >>> >>> We have a deployer for Web Beans, which looks like: >>> >>> $ ls -lR webbeans.deployer >>> total 1008 >>> drwxr-xr-x 4 pmuir admin 136 8 Jan 12:49 META-INF >>> -rw-r--r-- 1 pmuir admin 484056 8 Jan 12:49 google- >>> collections.jar >>> drwxr-xr-x 6 pmuir admin 204 8 Jan 12:49 lib-int >>> -rw-r--r-- 1 pmuir admin 26744 8 Jan 12:49 webbeans-ri-int- >>> microcontainer.jar >>> >>> webbeans.deployer/META-INF: >>> total 16 >>> -rw-r--r-- 1 pmuir admin 286 8 Jan 12:49 jboss-structure.xml >>> -rw-r--r-- 1 pmuir admin 1686 8 Jan 12:49 webbeans-deployers- >>> jboss-beans.xml >>> >>> webbeans.deployer/lib-int: >>> total 560 >>> -rw-r--r-- 1 pmuir admin 37664 8 Jan 12:49 webbeans-api.jar >>> -rw-r--r-- 1 pmuir admin 29714 8 Jan 12:49 webbeans-ri-int- >>> jbossas.jar >>> -rw-r--r-- 1 pmuir admin 6713 8 Jan 12:49 webbeans-ri-spi.jar >>> -rw-r--r-- 1 pmuir admin 201152 8 Jan 12:49 webbeans-ri.jar >>> >>> All jars in lib-int are inserted into the application's classpath >>> by a deployer. >>> >>> The only task I can see to include Web Beans is to add the >>> deployer to the JBoss AS build - I can do this (with Ales' >>> help ;-). >>> >>> Anything I'm missing? >>> >>> Pete >>> >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

In going through the integration of the current webeans 1.0.0.Alpha1 RI with the jbossas-5.0.0.GA release, the number guess example fails to deploy on startup with: Caused by: java.lang.NullPointerException at org.jboss.webbeans.integration.jbossas.ejb3.EjbDiscoveryEnvironment.lookup(EjbDiscoveryEnvironment.java:123) at org.jboss.webbeans.integration.jbossas.ejb3.EjbDiscoveryEnvironment.<init>(EjbDiscoveryEnvironment.java:41) at org.jboss.webbeans.integration.jbossas.WebBeanDiscoveryImpl.<init>(WebBeanDiscoveryImpl.java:25) ... 65 more 10:30:59,909 INFO [WebBeansBootstrap] Starting Web Beans RI 1.0.0.ALPHA1 10:30:59,909 ERROR [[/webbeans-numberguess]] Exception sending context initialized event to listener instance of class org.jboss.webbeans.servlet.WebBeansListener So I guess we need to focus on web beans integration tests as well. _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Dimitris, you worded that wrong. You should have said: "We are ABSOLUTELY NOT integrating Web Beans into 5.0.1. But I will ALLOW you to merge a STABLE implementation into 5.1." Let them know who's boss. :-) - DML On 01/14/2009 04:03 PM, Dimitris Andreadis wrote: > Shouldn't we leave the webbeans integration for 5.1? (Branch_5_x) > > 5.0.1 is a bug fixing release... > Scott Stark wrote: >> In going through the integration of the current webeans >> 1.0.0.Alpha1 RI with the jbossas-5.0.0.GA release, the number >> guess example fails to deploy on startup with: >> >> Caused by: java.lang.NullPointerException >> at >> org >> .jboss >> .webbeans >> .integration >> .jbossas >> .ejb3.EjbDiscoveryEnvironment.lookup(EjbDiscoveryEnvironment.java: >> 123) >> at >> org >> .jboss >> .webbeans >> .integration >> .jbossas >> .ejb3.EjbDiscoveryEnvironment.<init>(EjbDiscoveryEnvironment.java: >> 41) >> at >> org >> .jboss >> .webbeans >> .integration >> .jbossas.WebBeanDiscoveryImpl.<init>(WebBeanDiscoveryImpl.java:25) >> ... 65 more >> 10:30:59,909 INFO [WebBeansBootstrap] Starting Web Beans RI >> 1.0.0.ALPHA1 >> 10:30:59,909 ERROR [[/webbeans-numberguess]] Exception sending >> context initialized event to listener instance of class >> org.jboss.webbeans.servlet.WebBeansListener >> >> So I guess we need to focus on web beans integration tests as well. >> >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Do you have a reasoned argument (other than a needing a quick power trip) about why we should not be pushing new software that we develop into JBoss AS (clearly marked as a technology preview), to allow early access and increase the feedback we get?For example, EJB3 was optionally included in JBoss 4.0.x. Reading between the lines, I hope that this will address your concerns: First, please see https://jira.jboss.org/jira/browse/JBAS-6371 - you can see that I am suggesting 5.1 as the place to introduce WB. Second, as I stated earlier (obviously not clearly enough) we built the integration such that none of the WB libraries are included in the AS or application classpath unless the deployment is a Web Beans deployment (as marked by a {META-INF|WEB_INF}/web-beans.xml). Of course, this doesn't apply to the WB deployers which deploy the app, and push the WB libraries onto the app classpath. Thus, whether or not WB is stable, shouldn't affect non-web-bean apps applied to the AS. On 14 Jan 2009, at 22:11, David M. Lloyd wrote: > Dimitris, you worded that wrong. You should have said: > > "We are ABSOLUTELY NOT integrating Web Beans into 5.0.1. But I will > ALLOW you to merge a STABLE implementation into 5.1." > > Let them know who's boss. :-) > > - DML > > On 01/14/2009 04:03 PM, Dimitris Andreadis wrote: >> Shouldn't we leave the webbeans integration for 5.1? (Branch_5_x) >> >> 5.0.1 is a bug fixing release... >> Scott Stark wrote: >>> In going through the integration of the current webeans 1.0.0.Alpha1 >>> RI with the jbossas-5.0.0.GA release, the number guess example fails >>> to deploy on startup with: >>> >>> Caused by: java.lang.NullPointerException >>> at >>> org.jboss.webbeans.integration.jbossas.ejb3.EjbDiscoveryEnvironment.lookup(EjbDiscoveryEnvironment.java:123) >>> >>> at >>> org.jboss.webbeans.integration.jbossas.ejb3.EjbDiscoveryEnvironment.<init>(EjbDiscoveryEnvironment.java:41) >>> >>> at >>> org.jboss.webbeans.integration.jbossas.WebBeanDiscoveryImpl.<init>(WebBeanDiscoveryImpl.java:25) >>> >>> ... 65 more >>> 10:30:59,909 INFO [WebBeansBootstrap] Starting Web Beans RI >>> 1.0.0.ALPHA1 >>> 10:30:59,909 ERROR [[/webbeans-numberguess]] Exception sending >>> context initialized event to listener instance of class >>> org.jboss.webbeans.servlet.WebBeansListener >>> >>> So I guess we need to focus on web beans integration tests as well. >>> >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Do you have a reasoned argument (other than a needing a quick power trip) about why we should not be pushing new software that we develop into JBoss AS (clearly marked as a technology preview), to allow early access and increase the feedback we get?For example, EJB3 was optionally included in JBoss 4.0.x. Reading between the lines, I hope that this will address your concerns: First, please see https://jira.jboss.org/jira/browse/JBAS-6371 - you can see that I am suggesting 5.1 as the place to introduce WB. Second, as I stated earlier (obviously not clearly enough) we built the integration such that none of the WB libraries are included in the AS or application classpath unless the deployment is a Web Beans deployment (as marked by a {META-INF|WEB_INF}/web-beans.xml). Of course, this doesn't apply to the WB deployers which deploy the app, and push the WB libraries onto the app classpath. Thus, whether or not WB is stable, shouldn't affect non-web-bean apps applied to the AS. On 14 Jan 2009, at 22:11, David M. Lloyd wrote: > Dimitris, you worded that wrong. You should have said: > > "We are ABSOLUTELY NOT integrating Web Beans into 5.0.1. But I will > ALLOW you to merge a STABLE implementation into 5.1." > > Let them know who's boss. :-) > > - DML > > On 01/14/2009 04:03 PM, Dimitris Andreadis wrote: >> Shouldn't we leave the webbeans integration for 5.1? (Branch_5_x) >> >> 5.0.1 is a bug fixing release... >> Scott Stark wrote: >>> In going through the integration of the current webeans 1.0.0.Alpha1 >>> RI with the jbossas-5.0.0.GA release, the number guess example fails >>> to deploy on startup with: >>> >>> Caused by: java.lang.NullPointerException >>> at >>> org.jboss.webbeans.integration.jbossas.ejb3.EjbDiscoveryEnvironment.lookup(EjbDiscoveryEnvironment.java:123) >>> >>> at >>> org.jboss.webbeans.integration.jbossas.ejb3.EjbDiscoveryEnvironment.<init>(EjbDiscoveryEnvironment.java:41) >>> >>> at >>> org.jboss.webbeans.integration.jbossas.WebBeanDiscoveryImpl.<init>(WebBeanDiscoveryImpl.java:25) >>> >>> ... 65 more >>> 10:30:59,909 INFO [WebBeansBootstrap] Starting Web Beans RI >>> 1.0.0.ALPHA1 >>> 10:30:59,909 ERROR [[/webbeans-numberguess]] Exception sending >>> context initialized event to listener instance of class >>> org.jboss.webbeans.servlet.WebBeansListener >>> >>> So I guess we need to focus on web beans integration tests as well. >>> >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

I must say I'm enjoying this discussion :) I think the answer is simple, really. If we want to: (a) respect our versioning strategy (major/minor/point) (b) speed up the release cycle then we need to push features to minor releases. Project leads will always want to include their latest stuff to whichever is the next AS release, the reason being we didn't respect both (a) & (b) in the past. And I have too many stories to tell of "smallish" changes with cascading dependencies or causing unpredictable results. As it is now Branch_5_0 looks pretty stable testsuite/tck-wise and that makes my life a lot easier if I want to make the release date, so why risk breaking it? Besides 5.1 shouldn't be far way, end of February most probably. And if you are too eager to integrate, perform your work in Branch_5_x/trunk, then test against 5.0.x and release the webbeans deployer independently. Exception to the rules will always be, but let's try to stick to the rule first :) David M. Lloyd wrote: > Yes: 5.0.x is a stable branch and should only get bug fixes. > > By all means, integrate it into 5.1. But if it were me running the > project, I'd say, make sure that when it does get into the 5.x branch > that it is stable (a GA release), as merging snapshots and betas and > CRs at this stage will serve only to delay the release which is > supposed to be on a fixed schedule now. > > The point of my email really has nothing to do with Web Beans - I > don't really know the status at all. I was just trying to get > Dimitris to be more assertive - he just seems so darn apologetic and > polite all the time. :-) > > I would take it even a step farther and say that Dimitris should have > a fixed window during which people are allowed to merge new features > into the 5.x branch (which should be on a public calendar somewhere), > to give plenty of time to get the release stable before doing the > release. But I guess he'll only put up with me telling him how to do > his job for so long before telling me to get bent :) > > - DML > > On 01/15/2009 06:33 AM, Pete Muir wrote: >> Do you have a reasoned argument (other than a needing a quick power >> trip) about why we should not be pushing new software that we >> develop into JBoss AS (clearly marked as a technology preview), to >> allow early access and increase the feedback we get?For example, >> EJB3 was optionally included in JBoss 4.0.x. >> >> Reading between the lines, I hope that this will address your concerns: >> >> First, please see https://jira.jboss.org/jira/browse/JBAS-6371 - you >> can see that I am suggesting 5.1 as the place to introduce WB. >> >> Second, as I stated earlier (obviously not clearly enough) we built >> the integration such that none of the WB libraries are included in >> the AS or application classpath unless the deployment is a Web Beans >> deployment (as marked by a {META-INF|WEB_INF}/web-beans.xml). Of >> course, this doesn't apply to the WB deployers which deploy the app, >> and push the WB libraries onto the app classpath. Thus, whether or >> not WB is stable, shouldn't affect non-web-bean apps applied to the AS. >> >> On 14 Jan 2009, at 22:11, David M. Lloyd wrote: >> >>> Dimitris, you worded that wrong. You should have said: >>> >>> "We are ABSOLUTELY NOT integrating Web Beans into 5.0.1. But I >>> will ALLOW you to merge a STABLE implementation into 5.1." >>> >>> Let them know who's boss. :-) >>> >>> - DML >>> >>> On 01/14/2009 04:03 PM, Dimitris Andreadis wrote: >>>> Shouldn't we leave the webbeans integration for 5.1? (Branch_5_x) >>>> >>>> 5.0.1 is a bug fixing release... >>>> Scott Stark wrote: >>>>> In going through the integration of the current webeans >>>>> 1.0.0.Alpha1 RI with the jbossas-5.0.0.GA release, the number >>>>> guess example fails to deploy on startup with: >>>>> >>>>> Caused by: java.lang.NullPointerException >>>>> at >>>>> org.jboss.webbeans.integration.jbossas.ejb3.EjbDiscoveryEnvironment.lookup(EjbDiscoveryEnvironment.java:123) >>>>> >>>>> at >>>>> org.jboss.webbeans.integration.jbossas.ejb3.EjbDiscoveryEnvironment.<init>(EjbDiscoveryEnvironment.java:41) >>>>> >>>>> at >>>>> org.jboss.webbeans.integration.jbossas.WebBeanDiscoveryImpl.<init>(WebBeanDiscoveryImpl.java:25) >>>>> >>>>> ... 65 more >>>>> 10:30:59,909 INFO [WebBeansBootstrap] Starting Web Beans RI >>>>> 1.0.0.ALPHA1 >>>>> 10:30:59,909 ERROR [[/webbeans-numberguess]] Exception sending >>>>> context initialized event to listener instance of class >>>>> org.jboss.webbeans.servlet.WebBeansListener >>>>> >>>>> So I guess we need to focus on web beans integration tests as well. >>>>> >>>>> _______________________________________________ >>>>> jboss-development mailing list >>>>> jboss-development(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>> _______________________________________________ >>>> jboss-development mailing list >>>> jboss-development(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >> >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Carlo de Wolf wrote: > That's the reason why we're working on the EJB3 plugin. It works in a > similar manner to the WB RI update. Use ant to patch AS. > > In future this is going to be handled by the patching functionality of > the Profile Service. It'll be backed up by a Maven repository where > it'll download the version of a bundle/package specified by the > administrator. Ugh, I really hope we reconsider integrating maven's buggy codebase into AS.

Further this kind of thing really only seems useful for applying simple support patches, not so much for feature upgrades.

It's perfectly fine for a component library to do their own AS upgrade,

however that doesn't escape the need for frequent AS releases.

Also, updating a minor AS rev is simpler for users to manage, and all of the components are actually tested together.

Once you start talking about resolving transitive dependencies from a maven repository, as you do below, you need to either use the maven code, or reimplement maven's logic.

> Envision AS as nothing more than a base runtime which supports > arbitrary stuff to be deployed into it. ... OK That does sound cool. However when you do a major feature upgrade to something like EJB3, then dependencies start to clash, and you can end up with either major conflicts (and subsequent install failure), or an entire app server update. Such a feature would be more interesting if we had a number of services that are truly independent.

The real problem here is that our "configuration" files aren't configuration, they are essentially a meta-language that exposes internal implementation details that 99% of our users could care less about.

The other issue is that user deployments and system deployments get intermixed, but this can be resolved by giving users their own deployment directory that is initially empty.