5:02 p.m.
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
5:14 p.m.
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.)
- 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!
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
5:41 p.m.
Brian Stansberry wrote:
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.)
That was my understanding. I'll let David comment further.
--
Jason T. Greene
JBoss, a division of Red Hat
5:42 p.m.
On 12/11/2009 04:14 PM, Brian Stansberry wrote:
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.)
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.
- DML
5:45 p.m.
On 12/11/2009 04:42 PM, David M. Lloyd wrote:
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.
Great; thanks.
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
6:09 p.m.
EL 2.2 should make it in.
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!
8:43 a.m.
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?)
1) no-interface view for EJBs
2) Support for deployment of EJBs in .war files (Carlo has been working
on this)
-Jaikiran
5:11 a.m.
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
6:03 a.m.
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
6:25 a.m.
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
>> _______________________________________________ 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
7:23 a.m.
Basically a module is either:
- an ejb-jar
- a war
So an ear can be composed of several modules (say 3 ejb-jars and 1 war).
When injecting or doing a JNDI lookup of java:comp/Validator or
java:comp/ValidatorFactory
the container has to inject the VF related to the module the injection occurs.
While in many cases the same VF configuration is used and thus the same VF can be
injected, some modules might want to override some of the VF behavior and add a
META-INF/validator.xml file in the module packaging.
On 14 déc. 2009, at 12:03, Ales Justin wrote:
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
7:48 a.m.
Another non trivial thing worth a look for M2 is how the list of JPA providers is handled
in JBoss AS.
Basically, each app has a custom list of providers (it depends on what libs are
available). In OSGi, it's even worse as these people tend to hot redeploy JPA
providers to show that... well they can :)
Today the default implementation of PersistenceProviderResolver caches the list of
providers (with a weak key) per classloader. Very likely the AS has the hooks to:
- know at deployment the list of persistence providers and thus can pre populate the
list
- know when an app is undeployed and thus remove the list from the cache.
- in case of OSGi apply some more magic.
So JBoss AS needs a custom PersistenceProviderResolver implementation.
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
1:17 p.m.
Carlo de Wolf wrote:
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
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.
--
Jason T. Greene
JBoss, a division of Red Hat
1:38 p.m.
On Tue, Dec 15, 2009 at 7:17 PM, Jason T. Greene
<jason.greene(a)redhat.com> wrote:
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.
Works for me, I'm planning to put out a Web beta 1 tomorrow. I would
agree Carlo's RELOADED-9 is the biggest blocker.
Rémy
8:27 a.m.
On 12/15/2009 07:38 PM, Rémy Maucherat wrote:
On Tue, Dec 15, 2009 at 7:17 PM, Jason T. Greene
<jason.greene(a)redhat.com> wrote:
> 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.
Works for me, I'm planning to put out a Web beta 1 tomorrow.
We will tag AS trunk for that... Please mail here if there is something
broken (due to partial commit for example) and don't break trunk today.
Cheers
Jean-Frederic
I would
agree Carlo's RELOADED-9 is the biggest blocker.
Rémy
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
1:52 p.m.
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)
- 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.
What can we do on boot time and memory footprint? What pieces can we fit
into the timeframe? Personally I don't care how small. I'm concerned if
we wait for big pieces we'll never get anywhere. If possible for each
milestone we should identify some things and get them done.
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
2:04 p.m.
From a CDI perspective we should:
* update to Weld 1.0.1 which should be out in time for your dates
* switch to non-flat deployment structure (Ales is working on this)
* provide proper binding for the BeanManager (this depends on the same stuff as
ValidatorFactory) to java:comp/BeanManager
* ensure that EJB is using the 1.1 interceptors API
Thanks,
On 11 Dec 2009, at 22: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
2:49 p.m.
On 12/14/2009 05:25 AM, Carlo de Wolf wrote:
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...
Are there JBAS JIRA(s) for these?
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
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
3:22 p.m.
An integration freeze of Feb 1 for most libraries is fine, but to ensure
we actually ship the AS in Feb I think we should shoot for an earlier
cutoff for core stuff like MC/VDF/VFS/ProfileService. I'd be a lot more
comfortable with January 15 for those. Even earlier if possible.
Ales, you mentioned on another thread today that you thought MC 2.2
would be ready in a week or so. Could you commit to a January 8 date for
getting it into AS trunk?
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)
- 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!
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
3:45 p.m.
On 12/17/2009 01:49 PM, Brian Stansberry wrote:
On 12/14/2009 05:25 AM, Carlo de Wolf wrote:
> 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...
>
Are there JBAS JIRA(s) for these?
Never mind, I see https://jira.jboss.org/jira/browse/JBAS-7556
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
5:51 a.m.
An integration freeze of Feb 1 for most libraries is fine, but to
ensure
we actually ship the AS in Feb I think we should shoot for an earlier
cutoff for core stuff like MC/VDF/VFS/ProfileService. I'd be a lot more
comfortable with January 15 for those. Even earlier if possible.
Ales, you mentioned on another thread today that you thought MC 2.2
would be ready in a week or so. Could you commit to a January 8 date for
getting it into AS trunk?
Yes, that's doable.
4:34 p.m.
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.
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!
6:23 p.m.
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.
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!
>
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
6:31 p.m.
Are we going to do a new release of the org.jboss.mx artifacts (AS is
currently using 6.0.0.Beta1)? 6.0.0.Beta1 is missing
https://jira.jboss.org/jira/browse/JBAS-6945. This is the cause of the 5
testsuite failures discussed at
https://jira.jboss.org/jira/browse/JBAS-7606.
There are a lot more differences between trunk and 6.0.0.Beta1 than
JBAS-6945. I have a full diff if anyone wants me to send it to them.
(Bit big to send to the list.)
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)
- 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!
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
6:40 p.m.
Actually, looking at org.jboss.reloaded.naming.*, the naming ENCFactory
is only used for legacy purposes. Any type of EE component namespace
accessor spi would have to be in jboss-reloaded-naming. I'll take a look
introducing it there and getting a JNDIView working there and create a
JBREFLECT issue as needed.
Brian Stansberry wrote:
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.
>
>
5:34 a.m.
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?
9:32 a.m.
Trunk is currently using the components under
https://repository.jboss.org/maven2/org/jboss/mx/ -- specifically the
6.0.0.Beta1 release of each of those. The jmx/mbeans/j2se modules
formerly found Branch_5_x are not used in trunk.
I see there's a 6.0.0.Beta2 up there; seems to have been uploaded the
same day; no idea what the code differences are. It doesn't have the
JBAS-6945 fix.
If we're not ready to move to the trunk version of these components in
M2, we should find a strategy to patch 6.0.0.Beta1 to fix known
regressions from M1. I'd also need to reevaluate the check I did for
JBAS-7500 on where AS trunk stands vs what was in M1. I realize now I
compared the M1 tag's jmx/mbeans/j2se modules with the trunk version of
externalized jmx, not with the 6.0.0.Beta1 tag that AS trunk is using.
On 01/13/2010 04:34 AM, 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
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
9:33 a.m.
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?)
I'll have most JAX-RS integration. Full integration (and spec required)
can't happen without MC/EJB changes. I need scanning features and field
injection SPIs.
I'll have initial commit in by Feb 1st.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
5:33 a.m.
New subject: JMX stuff WAS Re: M2 planning and timeline
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
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss by Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
5:45 a.m.
New subject: JMX stuff WAS Re: M2 planning and timeline
It would be interesting to see if their is any performance difference using our or
JDK's
mbeanserver implementation.
Adrian Brock wrote:
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
11:16 a.m.
New subject: JMX stuff WAS Re: M2 planning and timeline
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 01/14/2010 04:33 AM, Adrian Brock wrote:
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
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
11:29 a.m.
New subject: JMX stuff WAS Re: M2 planning and timeline
JBJMX are the legacy JBossMX issues converted from sourceforge,
before it got rolled into the appserver.
When I split it out again, I decided to start again with JBMX.
Mainly because JMX is a Sun trademark.
http://www.sun.com/suntrademarks/#J
That's why we didn't call it JBossJMX originally. ;-)
On Thu, 2010-01-14 at 10:16 -0600, Brian Stansberry wrote:
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.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss by Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
3:32 a.m.
New subject: JMX stuff WAS Re: M2 planning and timeline
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.
Adrian Brock wrote:
> 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
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss by Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
10:35 a.m.
New subject: JMX stuff WAS Re: M2 planning and timeline
On Fri, 2010-01-15 at 09:32 +0100, Adrian Brock wrote:
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.
I've fixed the classloader problem.
We might want to run the full testsuite over it at some point when the
testsuite has been tidied up?
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss by Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
11:19 a.m.
New subject: JMX stuff WAS Re: M2 planning and timeline
I've fixed the classloader problem.
Hard work I see, moving one code line 3 lines up. :-)
-------------------------------------------------
Modified:
projects/jbossmx/trunk/mbeanserver/src/main/org/jboss/jmx/mbeanserver/JBossMBeanServer.java
===================================================================
---
projects/jbossmx/trunk/mbeanserver/src/main/org/jboss/jmx/mbeanserver/JBossMBeanServer.java
2010-01-15 14:02:43 UTC (rev 99475)
+++
projects/jbossmx/trunk/mbeanserver/src/main/org/jboss/jmx/mbeanserver/JBossMBeanServer.java
2010-01-15 14:05:27 UTC (rev 99476)
@@ -334,10 +334,10 @@
NotCompliantMBeanException,
InstanceNotFoundException
{
- RegistryEntry previous = checkCurrent(name, null);
+ ClassLoader cl = getOuter().getClassLoader(loaderName);
+ RegistryEntry previous = checkCurrent(name, cl);
try
{
- ClassLoader cl = getOuter().getClassLoader(loaderName);
ClassLoader previousCl = null;
ps: nice catch
11:30 a.m.
New subject: JMX stuff WAS Re: M2 planning and timeline
On Fri, 2010-01-15 at 17:19 +0100, Ales Justin wrote:
> I've fixed the classloader problem.
Hard work I see, moving one code line 3 lines up. :-)
Yeh, but then I had to release it, do a clean build of the AS,
run the smoke tests (twice - once for each mbeanserver impl)
and then check the remote jmx tests had all been fixed.
That'll learn me to do it properly in the first place. ;-)
-------------------------------------------------
Modified:
projects/jbossmx/trunk/mbeanserver/src/main/org/jboss/jmx/mbeanserver/JBossMBeanServer.java
===================================================================
---
projects/jbossmx/trunk/mbeanserver/src/main/org/jboss/jmx/mbeanserver/JBossMBeanServer.java
2010-01-15 14:02:43 UTC (rev 99475)
+++
projects/jbossmx/trunk/mbeanserver/src/main/org/jboss/jmx/mbeanserver/JBossMBeanServer.java
2010-01-15 14:05:27 UTC (rev 99476)
@@ -334,10 +334,10 @@
NotCompliantMBeanException,
InstanceNotFoundException
{
- RegistryEntry previous = checkCurrent(name, null);
+ ClassLoader cl = getOuter().getClassLoader(loaderName);
+ RegistryEntry previous = checkCurrent(name, cl);
try
{
- ClassLoader cl = getOuter().getClassLoader(loaderName);
ClassLoader previousCl = null;
ps: nice catch
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss by Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
1:12 p.m.
New subject: JMX stuff WAS Re: M2 planning and timeline
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
1:51 p.m.
New subject: JMX stuff WAS Re: M2 planning and timeline
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
6:32 p.m.
New subject: JMX stuff WAS Re: M2 planning and timeline
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
3:51 a.m.
New subject: JMX stuff WAS Re: M2 planning and timeline
He's asking if we can replace
AS system-jmx's org.jboss.system.microcontainer.jmx
*
http://anonsvn.jboss.org/repos/jbossas/trunk/system-jmx/src/main/java/org...
with
MC's org.jboss.system.microcontainer.jmx
*
http://anonsvn.jboss.org/repos/jbossas/projects/kernel/trunk/jmx-aop-mc-i...
My quick answer would be yes.
Kabir Khan wrote:
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
3:54 a.m.
New subject: JMX stuff WAS Re: M2 planning and timeline
On 01/18/2010 07:51 PM, 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)?
I updated trunk to use the latest release of jboss-integration, which
was done in 2 months ago or so. This should also include the
integration::annotations.
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
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
5207
days inactive
5247
days old
jboss-development@lists.jboss.org
42 comments
17 participants
participants (17)
-
Adrian Brock -
Ales Justin -
Bill Burke -
Brian Stansberry -
Carlo de Wolf -
David M. Lloyd -
Dimitris Andreadis -
Emanuel Muckenhuber -
Emmanuel Bernard -
Jaikiran Pai -
Jason T. Greene -
jean-frederic clere -
Kabir Khan -
Pete Muir -
Rémy Maucherat -
Scott Stark -
Stan Silvert