Fwd: [jboss-dev] Include Web Beans RI in next JBoss 5 release
by Pete Muir
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
15 years, 3 months
Re: [jboss-dev] Include Web Beans RI in next JBoss 5 release
by Dimitris Andreadis
Sacha Labourey wrote:
> Why don't we:
> - keep ONE "x.y" quiet i.e. don't do much work on them
> - keep the following "x.y+1" branch open to changes for some time (i.e.
> innovation period
> - then x.y+1 becomes the quiet branch
> - and we create a x.y+2 crazy branch
That's exactly the plan.
> That way we always have a PUBLIC branch with releases where we don't have
> to observe any backward compatibility rules which would prevent
> innovation.
>
> And if users want fixes on the quiet x.y branch, either they do it by
> themselves or they use the EAP.
>
> In this case:
> - the quiet branch would be 5.0 (don't touch it anymore)
> - the crazy branch would be 5.1
> - in a few months, 5.1 becomes a quiet branch (or you rebrand it 5.2 if
> you want to avoid confusion)
- We need to release a 5.0.1 to address some initial glitches
- 5.1 will be the next version, not so crazy because we want to keep stable enough for EAP
- trunk can be "crazy" and 5.x to a lesser extend (after 5.1 is released)
> The reason why I think we need a crazy branch is that if we just use
> "beta" and "alpha" qualifiers then i) we don't do much releases and ii)
> people tend not to test them and provide feedback. By having a real branch
> with real z-dot releases you really open it to the user-community.
>
>> -----Original Message-----
>> From: jboss-development-bounces(a)lists.jboss.org [mailto:jboss-
>> development-bounces(a)lists.jboss.org] On Behalf Of Carlo de Wolf
>> Sent: vendredi, 16 janvier 2009 12:01
>> To: dimitris(a)redhat.com; JBoss.org development list
>> Subject: Re: [jboss-dev] Include Web Beans RI in next JBoss 5 release
>>
>> I agree with both arguments. We must stick to rule we set for
>> versioning. But we must also have a means to bring in new technologies
>> onto the AS platform.
>>
>> For me I don't see option (b) happening in a fashion project leads want
>> to benefit of it. Most likely we'll have a quarterly or bi-monthly AS
>> release, while I would want a bi-weekly release of EJB3.
>>
>> 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.
>>
>> Some stuff I don't see happening, for example OSGi class loading
>> bundles. For example, jboss-metadata must only appear once because else
>> JBossSessionBeanMetaData != JBossSessionBeanMetaData anymore and you
>> can
>> visualize how WB, WS, REST are ignoring EJB 3.1 beans.
>>
>> Other things I think we should be able to do now like a meta xml
>> describing the bundle/package and it's dependencies, jarring it up,
>> putting that into a Maven repo and downloading it (and the dependencies
>> again).
>>
>> Merging of config files will be an interesting problem and thus left
>> out
>> of scope for the moment. :-)
>>
>> Installation of jar files can for the moment be handled by Ant.
>>
>> So you'll get something like:
>>
>> repository.jboss.org/maven2/org/jboss/metadata/jboss-metadata-
>> 1.0.0.package
>> repository.jboss.org/maven2/org/jboss/metadata/jboss-ejb3-1.0.0.package
>> repository.jboss.org/maven2/org/jboss/metadata/jboss-webbeans-
>> 1.0.0.package
>>
>> Each containing:
>> META-INF/jboss-profile.xml
>> META-INF/jboss-package-build.xml
>> lib/myjars.jar
>>
>> With jboss-package-build.xml targets: install, uninstall.
>>
>> Now I can see some mismatch between this idea and the Profile Service
>> designs, so I would like to move the EJB3 plugin to the next step
>> without slicing my fingers.
>>
>> Note that developing in Branch_5_x and releasing against AS 5.0.0 is
>> impossible. Been there, done that. ;-)
>>
>> Carlo
>>
>> Threads on Profile Service:
>> [1] http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201376
>> [2] http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4192175
>>
>> Dimitris Andreadis wrote:
>>> 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.loo
>> kup(EjbDiscoveryEnvironment.java:123)
>>>>>>>> at
>>>>>>>>
>> org.jboss.webbeans.integration.jbossas.ejb3.EjbDiscoveryEnvironment.<in
>> it>(EjbDiscoveryEnvironment.java:41)
>>>>>>>> at
>>>>>>>>
>> org.jboss.webbeans.integration.jbossas.WebBeanDiscoveryImpl.<init>(WebB
>> eanDiscoveryImpl.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
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
15 years, 3 months
Re: [jboss-dev] Include Web Beans RI in next JBoss 5 release
by Pete Muir
On 15 Jan 2009, at 15:20, David M. Lloyd wrote:
> Yes: 5.0.x is a stable branch and should only get bug fixes.
Fine by me :-) The big update we currently have to do in 5.0.0.GA (and
the problem Scott saw) is around updating EJB3; this update is in 5.0.1.
> 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.
I cetainly don't want to hold up AS. This was why I suggested it as a
preview of some sort - so that the JBoss AS release isn't held up by
not having a stable WB release. Worst comes to worst, we decide WB
isn't ready to integrate into AS 5.1.0.GA, and we just remove the
deployer (which is why the point about the WB libraries being isolated
is important).
But I think saying "all projects which make up AS *must* be in GA" is
too conservative - there are cases (like this one) where we want to
get some tech preview into the AS to give people a taste, and get
feedback. So, I would amend it to be "all projects must which make us
AS *must* be in GA or marked as tech preview. If the project is marked
tech preview, it should be isolated from the AS, and easy to remove".
> The point of my email really has nothing to do with Web Beans
The status is that we have preview releases we would like to get
feedback on. We probably won't have a GA by the time AS 5.1 goes out,
but that doesn't stop the features we do have (and the integration)
being relatively stable.
> - 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),
Sounds sensible to me. So, tell me the window, and I'll get the work
in for that window :-)
> 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
15 years, 3 months
JBoss Query
by div_gect
Hi
Here i m working on custom filter java file for JBoss Logging. I m
giving the entry of the java file in log4j.xml. My problem is that - if
the java file is in default package and its class file is in
jboss\server\default\conf then that class is instantiating fine but if
that java file is in package
com.propo.tools.mergemanager.profiles(where i want) and its package
entry is in java file then this file is not getting instantiated
properly by server. Can anyone help me here.
Thanks And Regards
Divya Garg
--
View this message in context: http://www.nabble.com/JBoss-Query-tp21476199p21476199.html
Sent from the JBoss - Dev mailing list archive at Nabble.com.
15 years, 3 months
Re: [jboss-dev] Include Web Beans RI in next JBoss 5 release
by Pete Muir
It's very likely the EJB3 update failed (again, most likely because
you don't have ANT_HOME set) [1]. Unfortunately the updater script in
the alpha1 release didn't fail if the EJB3 update fails (now fixed for
the upcoming alpha2).
[1] http://seamframework.org/Community/Webbeans10AlphaErrorCreatingWebBeanDis...
On 14 Jan 2009, at 18:40, 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
15 years, 3 months
JBoss Software Patterns
by chamandi podi
Hello All,
We are a group of students (six to be exact) currently
working on an assignment of a course on Software Patterns which is
part of our Master's Programme. The assignment involves the mining and
evaluation of both architectural and design patterns from a
non-trivial open source project. We have chosen JBoss for this
assignment and have prepared a report which includes our research to
understand the architecture of JBoss, description of relevant patterns
and a brief evaluation at the end. The report itself is a result of
four weeks of work, keeping in mind that all the students in the group
also have two other courses to follow. Even though, the report is a
work in progress, it contains all the important elements required for
the assignment.
We would be highly obliged if any (many) of you could
take a quick look at the report and give us some feedback (positive as
well as negative). Comments or suggestions regarding the amount of
research done , our understanding of the architecture and pattern
extraction / evaluation would be really helpful for us. If you cannot
do so, we would really appreciate it if you could point us to some
person (or group) who could help us.
Best Regards,
Cheri
15 years, 3 months
