Project Leads, The next planned AS release is 5.1 Beta which we are targeting for a March release, and a following GA in April (provided no major problems). I need to know what versions of your respective components you would like included in this release. These would preferably be of CR or better quality, although a beta release may be OK if you are confident you can get a GA shortly thereafter. It would also be helpful if you could limit the scope of whatever version you are targeting for AS inclusion to be the features that benefit AS. Keep in mind that we are transitioning to a frequent release cycle for the AS, so there is no need to rush your project to make this release. The more stable the project releases are, the less time it takes getting the AS ready to release. Thanks! -- Jason T. Greene JBoss, a division of Red Hat

Project Leads, The next planned AS release is 5.1 Beta which we are targeting for a March release, and a following GA in April (provided no major problems). I need to know what versions of your respective components you would like included in this release. These would preferably be of CR or better quality, although a beta release may be OK if you are confident you can get a GA shortly thereafter. It would also be helpful if you could limit the scope of whatever version you are targeting for AS inclusion to be the features that benefit AS. Keep in mind that we are transitioning to a frequent release cycle for the AS, so there is no need to rush your project to make this release. The more stable the project releases are, the less time it takes getting the AS ready to release. Thanks!

Not JBC 3.1.0 with NBST? Even though NBST is new and relatively unproven, it can be disabled in the default cfg. There are a number of important bug fixes in 3.1.0 that you will probably want. If you really don't want 3.1.0, I could cut 3.0.3 with the said fixes, which are: http://tinyurl.com/brg35m

On 4 Feb 2009, at 20:31, Brian Stansberry wrote: > JBC 3.0.2.GA (there now) > POJO Cache 3.0.1.GA -- if you release one ;) > JGroups 2.6.8 > ha-server-cache-spi & ha-server-cache-jbc -- perhaps 2.0.0, but not > really a big change there > > Jason T. Greene wrote: >> Project Leads, >> The next planned AS release is 5.1 Beta which we are targeting for a >> March release, and a following GA in April (provided no major problems). >> I need to know what versions of your respective components you would >> like included in this release. These would preferably be of CR or >> better quality, although a beta release may be OK if you are >> confident you can get a GA shortly thereafter. It would also be >> helpful if you could limit the scope of whatever version you are >> targeting for AS inclusion to be the features that benefit AS. >> Keep in mind that we are transitioning to a frequent release cycle >> for the AS, so there is no need to rush your project to make this >> release. The more stable the project releases are, the less time it >> takes getting the AS ready to release. >> Thanks! > > > -- > Brian Stansberry > Lead, AS Clustering > JBoss, a division of Red Hat > brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com> > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development -- Manik Surtani Lead, JBoss Cache http://www.jbosscache.org manik(a)jboss.org <mailto:manik@jboss.org> ------------------------------------------------------------------------ _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

On 5 Feb 2009, at 15:56, Brian Stansberry wrote: > Manik Surtani wrote: >> Not JBC 3.1.0 with NBST? Even though NBST is new and relatively >> unproven, it can be disabled in the default cfg. >> There are a number of important bug fixes in 3.1.0 that you will >> probably want. If you really don't want 3.1.0, I could cut 3.0.3 >> with the said fixes, which are: >> http://tinyurl.com/brg35m > > I see 4 of 47 issues resolved for 3.1.0. :) I need to revise that roadmap. We decided to cut 3.1.0 with the 4 bug fixes and NBST, push the rest out to 3.2.0. :)

> https://jira.jboss.org/jira/browse/JBCACHE/fixforversion/12311895 > > One of the things I want to get out of AS moving to > release-early-release-often is getting out of the cycle of trying to > cram in component upgrades. > > That said, I'd of course like to see non-blocking-state-transfer in AS > 5.1. But I don't want to try and cram it in -- needs to be highly > stable and in a highly stable release ready well ahead of time. To me > clustering in 5.1 is about profile service and embedded console stuff. This is why I suggested that by default NBST could be disabled. But your call either way, reckon you want a 3.0.3 then?

> > >> On 4 Feb 2009, at 20:31, Brian Stansberry wrote: >>> JBC 3.0.2.GA (there now) >>> POJO Cache 3.0.1.GA -- if you release one ;) >>> JGroups 2.6.8 >>> ha-server-cache-spi & ha-server-cache-jbc -- perhaps 2.0.0, but not >>> really a big change there >>> >>> Jason T. Greene wrote: >>>> Project Leads, >>>> The next planned AS release is 5.1 Beta which we are targeting for >>>> a March release, and a following GA in April (provided no major >>>> problems). >>>> I need to know what versions of your respective components you >>>> would like included in this release. These would preferably be of >>>> CR or better quality, although a beta release may be OK if you are >>>> confident you can get a GA shortly thereafter. It would also be >>>> helpful if you could limit the scope of whatever version you are >>>> targeting for AS inclusion to be the features that benefit AS. >>>> Keep in mind that we are transitioning to a frequent release cycle >>>> for the AS, so there is no need to rush your project to make this >>>> release. The more stable the project releases are, the less time it >>>> takes getting the AS ready to release. >>>> Thanks! >>> >>>

Project Leads, The next planned AS release is 5.1 Beta which we are targeting for a March release, and a following GA in April (provided no major problems). I need to know what versions of your respective components you would like included in this release. These would preferably be of CR or better quality, although a beta release may be OK if you are confident you can get a GA shortly thereafter. It would also be helpful if you could limit the scope of whatever version you are targeting for AS inclusion to be the features that benefit AS. Keep in mind that we are transitioning to a frequent release cycle for the AS, so there is no need to rush your project to make this release. The more stable the project releases are, the less time it takes getting the AS ready to release. Thanks!

Security: JBoss Security 2.0.2.SP5 JBoss XACML 2.0.3.CR1 AS JIRAs: JBAS-6425 JBAS-6419 Carlo de Wolf wrote: > EJB 3 1.1.0 or better. > JPA 1.0 or better. > > Carlo > > Jason T. Greene wrote: >> Project Leads, >> >> The next planned AS release is 5.1 Beta which we are targeting for a >> March release, and a following GA in April (provided no major >> problems). >> >> I need to know what versions of your respective components you would >> like included in this release. These would preferably be of CR or >> better quality, although a beta release may be OK if you are >> confident you can get a GA shortly thereafter. It would also be >> helpful if you could limit the scope of whatever version you are >> targeting for AS inclusion to be the features that benefit AS. >> >> Keep in mind that we are transitioning to a frequent release cycle >> for the AS, so there is no need to rush your project to make this >> release. The more stable the project releases are, the less time it >> takes getting the AS ready to release. >> >> Thanks! >>

Project Leads, The next planned AS release is 5.1 Beta which we are targeting for a March release, and a following GA in April (provided no major problems). I need to know what versions of your respective components you would like included in this release. These would preferably be of CR or better quality, although a beta release may be OK if you are confident you can get a GA shortly thereafter. It would also be helpful if you could limit the scope of whatever version you are targeting for AS inclusion to be the features that benefit AS. Keep in mind that we are transitioning to a frequent release cycle for the AS, so there is no need to rush your project to make this release. The more stable the project releases are, the less time it takes getting the AS ready to release. Thanks!

Project Leads, The next planned AS release is 5.1 Beta which we are targeting for a March release, and a following GA in April (provided no major problems). I need to know what versions of your respective components you would like included in this release. These would preferably be of CR or better quality, although a beta release may be OK if you are confident you can get a GA shortly thereafter. It would also be helpful if you could limit the scope of whatever version you are targeting for AS inclusion to be the features that benefit AS. Keep in mind that we are transitioning to a frequent release cycle for the AS, so there is no need to rush your project to make this release. The more stable the project releases are, the less time it takes getting the AS ready to release. Thanks!

Project Leads, The next planned AS release is 5.1 Beta which we are targeting for a March release, and a following GA in April (provided no major problems). I need to know what versions of your respective components you would like included in this release. These would preferably be of CR or better quality, although a beta release may be OK if you are confident you can get a GA shortly thereafter. It would also be helpful if you could limit the scope of whatever version you are targeting for AS inclusion to be the features that benefit AS. Keep in mind that we are transitioning to a frequent release cycle for the AS, so there is no need to rush your project to make this release. The more stable the project releases are, the less time it takes getting the AS ready to release. Thanks!

On 02/04/2009 01:50 PM, Jason T. Greene wrote: > Project Leads, > > The next planned AS release is 5.1 Beta which we are targeting for a > March release, and a following GA in April (provided no major problems). Something that has come up a few times since even a while before the 5.0 release is updating all the AS components to more effectively use jbossmc classloader/deployment facilities to do all kinds of wonderful things like: - Carefully controlling what APIs are available to what types of deployments - Only starting up services that are needed, through clever use of on-demand imports and that sort of thing - Changing or improving the way profiles are built to make the distro more space-efficient - etc. It usually goes like this. Someone brings up something peripheral to this, and I or one of the MC guys would say, "hey this stuff is all possible to do", then folks like Sacha would come in and say "this sounds great!", everyone would get enthused, and then everyone would just kind of stare at their shoes and hope that someone else would make it happen. I know that at least a couple new projects are doing this, going forward, but is there any chance we could start this process for 5.1 for existing stuff? Maybe start by attaching jboss-classloading.xml and so forth to the various libraries and/or moving them in with their related deployers, figuring out what it would take to get the deployers only linking the right APIs to the various deployment types, etc. Just brainstorming some ideas would be a great start. From there it could move to a wiki page for requirements and/or a JIRA task list, etc. Is there a person who is actually *on* the AS team who could take point on this, for existing components? Or should we officially just let the idea die for 5.x?

Jason T. Greene wrote: > David M. Lloyd wrote: >> On 02/04/2009 01:50 PM, Jason T. Greene wrote: >>> Project Leads, >>> >>> The next planned AS release is 5.1 Beta which we are targeting for a >>> March release, and a following GA in April (provided no major >>> problems). >> >> Something that has come up a few times since even a while before the >> 5.0 release is updating all the AS components to more effectively use >> jbossmc classloader/deployment facilities to do all kinds of >> wonderful things like: >> >> - Carefully controlling what APIs are available to what types of >> deployments >> - Only starting up services that are needed, through clever use of >> on-demand imports and that sort of thing >> - Changing or improving the way profiles are built to make the distro >> more space-efficient >> - etc. >> >> It usually goes like this. Someone brings up something peripheral to >> this, and I or one of the MC guys would say, "hey this stuff is all >> possible to do", then folks like Sacha would come in and say "this >> sounds great!", everyone would get enthused, and then everyone would >> just kind of stare at their shoes and hope that someone else would >> make it happen. >> >> I know that at least a couple new projects are doing this, going >> forward, but is there any chance we could start this process for 5.1 >> for existing stuff? Maybe start by attaching jboss-classloading.xml >> and so forth to the various libraries and/or moving them in with >> their related deployers, figuring out what it would take to get the >> deployers only linking the right APIs to the various deployment >> types, etc. Just brainstorming some ideas would be a great start. >> From there it could move to a wiki page for requirements and/or a >> JIRA task list, etc. Is there a person who is actually *on* the AS >> team who could take point on this, for existing components? Or >> should we officially just let the idea die for 5.x? >> > > I am hoping we can keep the scope narrow for 5.1 (embedded console and > related profile service work + component updates). So I think we > should delay this work until 6.x. > > Although if anyone wants to get a head start and do this for their > project in 5.1 that's fine with me, as long as it doesn't delay the > schedule. > Right now EJB3 is looking to create JNDI bindings with proxies that on demand contact the containers. In the first step this will only be done for no-interface view (while the container may still start eagerly). Maybe we'll go over the existing views as well. Still it's not a requirement for 5.1 and if it's done, it's done, if not, then nothing is lost. Carlo _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

On 02/04/2009 01:50 PM, Jason T. Greene wrote: > Project Leads, > > The next planned AS release is 5.1 Beta which we are targeting for a > March release, and a following GA in April (provided no major problems). Here's the deal with logging. From a features perspective, there's two major pieces being developed. The first is getting JDK logging integrated nicely with the rest of the AS. This feature will be done for 5.1 *no matter what* - this week if I can help it - and it will involve a "fixed" JDK logmanager as well as a JDK-log4j bridge component.

Facelets uses JDK logging as well, but it doesn't ship with AS. However, because it is so common, I have bridge code in there to handle Facelets loggers in the same manner as JSF. So all the code for the logging bridges can go away now? Will the mapping of log levels between Log4J and JUL remain the same as specified here? http://www.jboss.org/community/docs/DOC-10379 Stan David M. Lloyd wrote: > On 02/19/2009 01:34 PM, David M. Lloyd wrote: >> On 02/04/2009 01:50 PM, Jason T. Greene wrote: >>> Project Leads, >>> >>> The next planned AS release is 5.1 Beta which we are targeting for a >>> March release, and a following GA in April (provided no major >>> problems). >> >> Here's the deal with logging. >> >> From a features perspective, there's two major pieces being >> developed. The first is getting JDK logging integrated nicely with >> the rest of the AS. This feature will be done for 5.1 *no matter >> what* - this week if I can help it - and it will involve a "fixed" >> JDK logmanager as well as a JDK-log4j bridge component. > > This part is done. If you have components using JDK logging (JSF is > the only one I know of for sure), please make sure everything looks > right, and bask in the awesomeness of having your logging work - > finally :) > > - DML >