On 12/11/2009 04:02 PM, Jason T. Greene wrote: > Hi Guys, > > Now that M1 is out lets talk about M2 and what can make the release. The > tentative release plan we have talked about is a integration freeze on > Feb 1, with an eventual freeze in late Feb. However, before we get more > absolute dates we really need to nail down on what we aim to deliver in > that time frame. > > From an EE perspective it seems the following are close enough that > they could make such a schedule: > > Full Servlet 3 > Full JPA 2 > Some EJB 3.1 capabilities (but which ones?) > > Other updates that have been proposed: > - Inclusion of Remoting 3 (but full service porting to occur later) What does that mean? There'd be parallel connectors for a while? (Not objecting, just realize I don't know.)

On 12/11/2009 04:14 PM, Brian Stansberry wrote: > On 12/11/2009 04:02 PM, Jason T. Greene wrote: >> >> Other updates that have been proposed: >> - Inclusion of Remoting 3 (but full service porting to occur later) > > What does that mean? There'd be parallel connectors for a while? (Not > objecting, just realize I don't know.) Yes, parallel connectors. It means that at a minimum, Remoting 3 would be integrated with an XML schema to create basic endpoint and service deployments, but it wouldn't necessarily relate to any existing services using Remoting 2 in any way. The idea is that we could then start moving stuff over to use Remoting 3 gradually. Though that might not really be possible in practice. Just seems like a way to make the migration bite-sized.

EL 2.2 should make it in.

Hi Guys, Now that M1 is out lets talk about M2 and what can make the release. The tentative release plan we have talked about is a integration freeze on Feb 1, with an eventual freeze in late Feb. However, before we get more absolute dates we really need to nail down on what we aim to deliver in that time frame. From an EE perspective it seems the following are close enough that they could make such a schedule: Full Servlet 3 Full JPA 2 Some EJB 3.1 capabilities (but which ones?) Other updates that have been proposed: - Inclusion of Remoting 3 (but full service porting to occur later) - Inclusion of HornetQ (need to understand more about the effort to migrate) If your project is on the above list, let me know what your schedule is like, and if it can fit the above timeline. If your project update is not on the list, but would like to have it included, and the above timeframe is workable, let me know. Thanks! -- Jason T. Greene JBoss, a division of Red Hat _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Module?

As in sub-deployment? You once tried to explain me this via JEE modules, which I know nothing about. OK, I guess did/should, but forgot. :-) Can you explain it now? Emmanuel Bernard wrote: > We should probably implement the module injection BV requires. Today > we have a global BV ValidatorFactory for the whole application. > > On 11 déc. 2009, at 23:02, Jason T. Greene wrote: > > >> Hi Guys, >> >> Now that M1 is out lets talk about M2 and what can make the >> release. The tentative release plan we have talked about is a >> integration freeze on Feb 1, with an eventual freeze in late Feb. >> However, before we get more absolute dates we really need to nail >> down on what we aim to deliver in that time frame. >> >> From an EE perspective it seems the following are close enough that >> they could make such a schedule: >> >> Full Servlet 3 Full JPA 2 Some EJB 3.1 capabilities (but which >> ones?) >> >> Other updates that have been proposed: - Inclusion of Remoting 3 >> (but full service porting to occur later) - Inclusion of HornetQ >> (need to understand more about the effort to migrate) >> >> If your project is on the above list, let me know what your >> schedule is like, and if it can fit the above timeline. >> >> If your project update is not on the list, but would like to have >> it included, and the above timeframe is workable, let me know. >> >> Thanks! >> >> -- Jason T. Greene JBoss, a division of Red Hat >> _______________________________________________ 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

OK, so how does the forecast look for completion of this by Feb 1? I would love to add it, but I am just wanting to make sure we can do it.

On 12/14/2009 12:03 PM, Ales Justin wrote: > Module? > Module as in JavaEE module. E.g. a deployment unit which might be assembled in an EAR containing META-INF/validation.xml (BV 1.0 Final Ch 7). Injection should then happen in accordance to JavaEE 6 PFD EE 5.16. @Resource Validator validator; @Resource ValidatorFactory validatorFactory; and the associated JNDI names: java:comp/Validator java:comp/ValidatorFactory The BV deployer should bind a ValidatorFactory into global JNDI per module. The setup of JNDI namespaces need to be refactored. First I need to expedite RELOADED-9 into trunk. That should be easy now that the name server has become a MC bean. Second we need to get JNDI namespace deployers, so that java:app, java:module and java:comp are basically installed via deployments. Third we need to refactor the current EncInjectors to make them more generic (and out of ejb3-core) so that they can setup the java:comp environment for real. This would probably be a deployer (or part of java:comp deployer) with incallbacks. Last we need to change all the current JavaEE containers to consume the newly created JNDI context. And finally create an 'EncInjector' for java:comp/Validator...

Carlo > As in sub-deployment? > > You once tried to explain me this via JEE modules, > which I know nothing about. OK, I guess did/should, but forgot. :-) > > Can you explain it now? > > Emmanuel Bernard wrote: > >> We should probably implement the module injection BV requires. Today >> we have a global BV ValidatorFactory for the whole application. >> >> On 11 déc. 2009, at 23:02, Jason T. Greene wrote: >> >> >>> Hi Guys, >>> >>> Now that M1 is out lets talk about M2 and what can make the >>> release. The tentative release plan we have talked about is a >>> integration freeze on Feb 1, with an eventual freeze in late Feb. >>> However, before we get more absolute dates we really need to nail >>> down on what we aim to deliver in that time frame. >>> >>> From an EE perspective it seems the following are close enough that >>> they could make such a schedule: >>> >>> Full Servlet 3 Full JPA 2 Some EJB 3.1 capabilities (but which >>> ones?) >>> >>> Other updates that have been proposed: - Inclusion of Remoting 3 >>> (but full service porting to occur later) - Inclusion of HornetQ >>> (need to understand more about the effort to migrate) >>> >>> If your project is on the above list, let me know what your >>> schedule is like, and if it can fit the above timeline. >>> >>> If your project update is not on the list, but would like to have >>> it included, and the above timeframe is workable, let me know. >>> >>> Thanks! >>> >>> -- Jason T. Greene JBoss, a division of Red Hat

Module? As in sub-deployment? You once tried to explain me this via JEE modules, which I know nothing about. OK, I guess did/should, but forgot. :-) Can you explain it now? Emmanuel Bernard wrote: > We should probably implement the module injection BV requires. Today > we have a global BV ValidatorFactory for the whole application. > > On 11 déc. 2009, at 23:02, Jason T. Greene wrote: > >> Hi Guys, >> >> Now that M1 is out lets talk about M2 and what can make the >> release. The tentative release plan we have talked about is a >> integration freeze on Feb 1, with an eventual freeze in late Feb. >> However, before we get more absolute dates we really need to nail >> down on what we aim to deliver in that time frame. >> >> From an EE perspective it seems the following are close enough that >> they could make such a schedule: >> >> Full Servlet 3 Full JPA 2 Some EJB 3.1 capabilities (but which >> ones?) >> >> Other updates that have been proposed: - Inclusion of Remoting 3 >> (but full service porting to occur later) - Inclusion of HornetQ >> (need to understand more about the effort to migrate) >> >> If your project is on the above list, let me know what your >> schedule is like, and if it can fit the above timeline. >> >> If your project update is not on the list, but would like to have >> it included, and the above timeframe is workable, let me know. >> >> Thanks! >> >> -- Jason T. Greene JBoss, a division of Red Hat >> _______________________________________________ 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

Hi Guys, Now that M1 is out lets talk about M2 and what can make the release. The tentative release plan we have talked about is a integration freeze on Feb 1, with an eventual freeze in late Feb. However, before we get more absolute dates we really need to nail down on what we aim to deliver in that time frame. From an EE perspective it seems the following are close enough that they could make such a schedule: Full Servlet 3 Full JPA 2 Some EJB 3.1 capabilities (but which ones?) Other updates that have been proposed: - Inclusion of Remoting 3 (but full service porting to occur later) - Inclusion of HornetQ (need to understand more about the effort to migrate) If your project is on the above list, let me know what your schedule is like, and if it can fit the above timeline. If your project update is not on the list, but would like to have it included, and the above timeframe is workable, let me know.

Hi Guys, Now that M1 is out lets talk about M2 and what can make the release. The tentative release plan we have talked about is a integration freeze on Feb 1, with an eventual freeze in late Feb. However, before we get more absolute dates we really need to nail down on what we aim to deliver in that time frame. From an EE perspective it seems the following are close enough that they could make such a schedule: Full Servlet 3 Full JPA 2 Some EJB 3.1 capabilities (but which ones?) Other updates that have been proposed: - Inclusion of Remoting 3 (but full service porting to occur later) - Inclusion of HornetQ (need to understand more about the effort to migrate) If your project is on the above list, let me know what your schedule is like, and if it can fit the above timeline. If your project update is not on the list, but would like to have it included, and the above timeframe is workable, let me know. Thanks!

Hi Guys, Now that M1 is out lets talk about M2 and what can make the release. The tentative release plan we have talked about is a integration freeze on Feb 1, with an eventual freeze in late Feb. However, before we get more absolute dates we really need to nail down on what we aim to deliver in that time frame. From an EE perspective it seems the following are close enough that they could make such a schedule: Full Servlet 3 Full JPA 2 Some EJB 3.1 capabilities (but which ones?) Other updates that have been proposed: - Inclusion of Remoting 3 (but full service porting to occur later) - Inclusion of HornetQ (need to understand more about the effort to migrate) If your project is on the above list, let me know what your schedule is like, and if it can fit the above timeline. If your project update is not on the list, but would like to have it included, and the above timeframe is workable, let me know. Thanks!

Ok, thanks. On 01/12/2010 03:34 PM, Scott Stark wrote: > I believe that there is a need for a 5.1.x naming release to expose the > new namespaces so that admin views like JNDIView start working > correctly. It mostly likely would only include JBNAME-44 and JBNAME-41 > if we want to drop the default java:comp creation. > >

Hi Guys, Now that M1 is out lets talk about M2 and what can make the release. The tentative release plan we have talked about is a integration freeze on Feb 1, with an eventual freeze in late Feb. However, before we get more absolute dates we really need to nail down on what we aim to deliver in that time frame. From an EE perspective it seems the following are close enough that they could make such a schedule: Full Servlet 3 Full JPA 2 Some EJB 3.1 capabilities (but which ones?) Other updates that have been proposed: - Inclusion of Remoting 3 (but full service porting to occur later) - Inclusion of HornetQ (need to understand more about the effort to migrate) If your project is on the above list, let me know what your schedule is like, and if it can fit the above timeline. If your project update is not on the list, but would like to have it included, and the above timeframe is workable, let me know. Thanks!

> Are we going to do a new release of the org.jboss.mx artifacts (AS is > currently using 6.0.0.Beta1)? Does this mean we're using our externalized JBossMX? Afaik, we're not yet ready to switch AS to use externalized version. * http://lists.jboss.org/pipermail/jboss-development/2009-December/015142.html Adrian? _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

I changed trunk to use the external JBossMX last February. There was a release of Beta2 in March which was mainly a tidyup release. Anil's fix was in May. but since he hasn't created a JBMX jira for his fix is doesn't appear on that project's roadmap. https://jira.jboss.org/jira/secure/IssueNavigator.jspa?reset=true&pid... I'll do a Beta3 release for that. The mc-jmx-int and deployers-jmx stuff was only in the 2.2.x branches of the MC projects. Now that you've upgraded trunk to those versions it should be a lot easier to use the external versions. ejb3 was already using it. I'll test it, and change trunk to use them. Then we can remove the duplicate code from system-jmx. The only additional issue is whether we still want to use the JBossMX mbeanserver now that I have a way to use the JDK's MBeanServer. https://jira.jboss.org/jira/browse/JBMX-11 We could keep the choice, since its just a case of changing the MBeanServerBuilder system property. We still need the j2se and mbeans stuff for the legacy XMBean support. On Wed, 2010-01-13 at 11:34 +0100, Ales Justin wrote: >> Are we going to do a new release of the org.jboss.mx artifacts (AS is >> currently using 6.0.0.Beta1)? > Does this mean we're using our externalized JBossMX? > Afaik, we're not yet ready to switch AS to use externalized version. > * > http://lists.jboss.org/pipermail/jboss-development/2009-December/015142.html > > Adrian? > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development

On Thu, 2010-01-14 at 12:45 +0200, Dimitris Andreadis wrote: > It would be interesting to see if their is any performance difference using our or JDK's > mbeanserver implementation. > It doesn't seem to make an appreachable difference for the boot time or running the basic tests. It might show a difference if you stressed an MBeanServer.invoke() like we do in EJB2? Anyway, I've added this to trunk now. You can try it with ./run.sh -Djavax.management.builder.initial=org.jboss.jmx.mbeanserver.JBossMBeanServerBuilder I seem to have a bug with the remote jmx usage and classloading which I need to investigate. e.g. using the jmx-remoting.sar classloader instead of the jmx deployment's classloader.

Excellent; thanks Adrian. I added a sentence to the JBJMX project description pointing to JBMX. Perhaps we should change the name of it in JIRA as well from "JBoss JMX" to something that warns people of like "Legacy JBoss JMX (Closed)". A couple days ago I was poking around trying to investigate history and ended up in the wrong project.

On Thu, 2010-01-14 at 11:33 +0100, Adrian Brock wrote: > The mc-jmx-int and deployers-jmx stuff was only in the 2.2.x branches > of the MC projects. Now that you've upgraded trunk to those versions it > should be a lot easier to use the external versions. > > ejb3 was already using it. > > I'll test it, and change trunk to use them. Then we can remove the > duplicate code from system-jmx. This is in now. There's only four pieces left in system-jmx: 1) org.jboss.deployment This is the legacy MainDeployer api 2) org.jboss.system.deployers.managed I think this should be in deployers-jmx but it has a dependency on the profile service? 3) org.jboss.system.pm This has a dependency on ServerConfig. If the configuration was injected this could move to jmx-mc-int 4) org.jboss.system.microcontainer.jmx I think this should replaced with jmx-aop-mc-int Kabir, is that correct? > > xxxxxxxxxxxxxxxxxxxxxxxxxxxx > Adrian Brock > Chief Scientist > JBoss by Red Hat > xxxxxxxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Adrian, I don't understand your question regarding 4) On 18 Jan 2010, at 18:51, Ales Justin wrote: > I see I actually never updated @Jmx to integration::annotations. :-( > Emanuel what's the status of integration project (in/wrt AS trunk)? > > Afaik, (4) should be fine when replaced. > > Adrian Brock wrote: >> On Thu, 2010-01-14 at 11:33 +0100, Adrian Brock wrote: >>> The mc-jmx-int and deployers-jmx stuff was only in the 2.2.x branches >>> of the MC projects. Now that you've upgraded trunk to those versions it >>> should be a lot easier to use the external versions. >>> >>> ejb3 was already using it. >>> >>> I'll test it, and change trunk to use them. Then we can remove the >>> duplicate code from system-jmx. >> This is in now. >> There's only four pieces left in system-jmx: >> 1) org.jboss.deployment >> This is the legacy MainDeployer api >> 2) org.jboss.system.deployers.managed >> I think this should be in deployers-jmx >> but it has a dependency on the profile service? >> 3) org.jboss.system.pm >> This has a dependency on ServerConfig. >> If the configuration was injected this could >> move to jmx-mc-int >> 4) org.jboss.system.microcontainer.jmx >> I think this should replaced with jmx-aop-mc-int >> Kabir, is that correct? >>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx >>> Adrian Brock >>> Chief Scientist >>> JBoss by Red Hat >>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development

Hi Guys, Now that M1 is out lets talk about M2 and what can make the release. The tentative release plan we have talked about is a integration freeze on Feb 1, with an eventual freeze in late Feb. However, before we get more absolute dates we really need to nail down on what we aim to deliver in that time frame. From an EE perspective it seems the following are close enough that they could make such a schedule: Full Servlet 3 Full JPA 2 Some EJB 3.1 capabilities (but which ones?)