You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by buddhika chamith <ch...@gmail.com> on 2010/03/12 12:32:53 UTC
Re: GSOC 2010
Hi All,
I am interested in working on the JMX related project idea. I am in the
process of going through the documentation and sources relating to JMX in
Tomcat. Excerpt of the idea mentions that "Tomcat instance to be configured
entirely via JMX" is the goal of project. Since the JMX infrastructure is
already present, are there any specific areas that you have already
identified as lacking support in order to achieve above goal? I noticed in
another thread that Apache Pivot folks are also interested in providing an
administrative front end to Tomcat perhaps using JMX.
Regards,
Chamith
Re: GSOC 2010
Posted by buddhika chamith <ch...@gmail.com>.
Hi Mark,
I have put the required information as a comment in the GSOC app. since it
seems editing the original proposal is disabled. I am posting the break down
here as well for the benefit of anyone else interested.
The breakdown by the packages is given below.
Package Days
org.apache.catalina 5
org.apache.catalina.authenticator 4
org.apache.catalina.connector 1
org.apache.catalina.core 10
org.apache.catalina.deploy 3
org.apache.catalina.ha 2
org.apache.catalina.ha.authenticator 1
org.apache.catalina.ha.deploy 1
org.apache.catalina.ha.session 3
org.apache.catalina.ha.tcp 7
org.apache.catalina.loader 1
org.apache.catalina.mbeans 3
Approx. - Mid evaluation
org.apache.catalina.realm 5
org.apache.catalina.session 1
org.apache.catalina.startup 2
org.apache.catalina.tribes 2
org.apache.catalina.tribes.membership 1
org.apache.catalina.tribes.transport 5
org.apache.catalina.users 1
org.apache.catalina.valves 6
org.apache.jasper.servlet 1
____
65
The basic criteria for this breakdown is the number of currently JMX
instrumented classes in each pacakge plus some insights I have about certain
pacakages that I am familiar with. I have left about 3 - 4 weeks buffer time
in case
- Any other new packages are identified in the process which would need
JMX instrumentation.
- Documentation if any
- Bug fixes etc.
Any comments on this are appreciated if there are any issues with the
schedule (deviating from realistic values according to the work to be done)
since I may not have the whole idea about certain packages and the amount of
work that needs to be done in such packages, without some further study.
Best Regards,
Chamith
Re: GSOC 2010
Posted by Mark Thomas <ma...@apache.org>.
On 07/04/2010 12:06, buddhika chamith wrote:
> Hi All,
>
> I have prepared my proposal on JMX enhancement GSOC project. You can find it
> here.
> http://wiki.apache.org/general/BuddhikaChamith/Tomcat_GSOC2010_Proposal_BuddhikaChamith
>
> Any suggestions and comments are welcome.
I have commented on your proposal in the GSoC application. Please
respond (also in GSoC app) asap as the deadline for evaluation is fast
approaching.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: GSOC 2010
Posted by buddhika chamith <ch...@gmail.com>.
Hi All,
I have prepared my proposal on JMX enhancement GSOC project. You can find it
here.
http://wiki.apache.org/general/BuddhikaChamith/Tomcat_GSOC2010_Proposal_BuddhikaChamith
Any suggestions and comments are welcome.
Best Regards,
Chamith
Re: GSOC 2010
Posted by Mark Thomas <ma...@apache.org>.
On 02/04/2010 17:33, buddhika chamith wrote:
> Hi Mark,
>
> Thanks for the reply. Since I was hoping to put a proposal regarding the JMX
> idea I was wondering whether it would be viable if I have not satisfied with
> the criteria "not be accepting applications from a student unless they have
> already provided an acceptable patch for at least one and preferably more
> currently open, non-trivial bugzilla items (bugs or enhancements).".
> Currently I have done some work on an enhancement regarding a command line
> client for AJP. (https://issues.apache.org/bugzilla/show_bug.cgi?id=47242).
> I searched bugzilla for JMX related bugs or enhancements but couldn't find
> satisfactory issues on that front which hasn't been addressed already. I
> would like to know your comments on the above.
My thoughts are that there is plenty that needs fixing with the the JMX
implementation - hence the GSoC project. Providing quality patches for
some of those issues would be an advantage for anyone looking to apply
for that project.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: GSOC 2010
Posted by buddhika chamith <ch...@gmail.com>.
Hi Mark,
Thanks for the reply. Since I was hoping to put a proposal regarding the JMX
idea I was wondering whether it would be viable if I have not satisfied with
the criteria "not be accepting applications from a student unless they have
already provided an acceptable patch for at least one and preferably more
currently open, non-trivial bugzilla items (bugs or enhancements).".
Currently I have done some work on an enhancement regarding a command line
client for AJP. (https://issues.apache.org/bugzilla/show_bug.cgi?id=47242).
I searched bugzilla for JMX related bugs or enhancements but couldn't find
satisfactory issues on that front which hasn't been addressed already. I
would like to know your comments on the above.
Regards,
Chamith
Re: GSOC 2010
Posted by Mark Thomas <ma...@apache.org>.
On 31/03/2010 12:48, buddhika chamith wrote:
> Hi,
>
> I went through the some source codes to understand Tomcat's JMX
> implementation. Here are some of the things as I understood. Please correct
> me if I am wrong.
>
> 1. As I understood it uses a commons modeler type implementation (which I
> saw within a comment and went to explore).
> 2. Uses Dynamic MBeans and BaseModelBeans (extension of DynamicMBeans)
> 3. Uses ManagedBean class to store meta data about a bean and instantiate
> it.
> 4. Uses Registry to load ManagedBeans from meta-data files and register the
> MBean with the MBean server.
> 5. MBeanFactory class contains all the useful methods to create most of the
> Tomcat components along with the MBeans.
>
> I noticed the MBeanFactory class methods are not utilised inside Tomcat
> internal codes to create Tomcat server side components. Is this because that
> it is only meant to be used remotely?
Correct.
> Regarding the missing createStandardService() in MBeanFactory, issue, I
> looked as to how normally StarndardService is created within Tomcat. I
> noticed that the Service component is created using configuration data read
> by server.xml using a Digester. Now do you think a similar approach can be
> utilized to provide the missing method? (But this approach misses the point
> of configuring a Tomcat instance from the scratch without configuration
> files. Isn't it?).
Take a look in the svn history. The removed method will give you some clues.
> What were the issues with ServerFactory that it had to be
> removed?
It assumed that there was only ever one Server instance in a JVM and as
a result created all sorts of issues, particularly when embedding Tomcat.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: GSOC 2010
Posted by buddhika chamith <ch...@gmail.com>.
Hi,
I went through the some source codes to understand Tomcat's JMX
implementation. Here are some of the things as I understood. Please correct
me if I am wrong.
1. As I understood it uses a commons modeler type implementation (which I
saw within a comment and went to explore).
2. Uses Dynamic MBeans and BaseModelBeans (extension of DynamicMBeans)
3. Uses ManagedBean class to store meta data about a bean and instantiate
it.
4. Uses Registry to load ManagedBeans from meta-data files and register the
MBean with the MBean server.
5. MBeanFactory class contains all the useful methods to create most of the
Tomcat components along with the MBeans.
I noticed the MBeanFactory class methods are not utilised inside Tomcat
internal codes to create Tomcat server side components. Is this because that
it is only meant to be used remotely?
Regarding the missing createStandardService() in MBeanFactory, issue, I
looked as to how normally StarndardService is created within Tomcat. I
noticed that the Service component is created using configuration data read
by server.xml using a Digester. Now do you think a similar approach can be
utilized to provide the missing method? (But this approach misses the point
of configuring a Tomcat instance from the scratch without configuration
files. Isn't it?). What were the issues with ServerFactory that it had to be
removed?
Regards,
Chamith
Re: GSOC 2010
Posted by buddhika chamith <ch...@gmail.com>.
Hi Mark,
Thanks for the clarifications. I will look along in those lines that you
mentioned. I will drop a mail to the list if I come up with any issue during
the code run through.
Chamith
Re: GSOC 2010
Posted by Mark Thomas <ma...@apache.org>.
On 12/03/2010 12:13, Mark Thomas wrote:
> On 12/03/2010 11:32, buddhika chamith wrote:
>> Hi All,
>>
>> I am interested in working on the JMX related project idea.
> Great.
>
>> I am in the
>> process of going through the documentation and sources relating to JMX in
>> Tomcat. Excerpt of the idea mentions that "Tomcat instance to be configured
>> entirely via JMX" is the goal of project. Since the JMX infrastructure is
>> already present, are there any specific areas that you have already
>> identified as lacking support in order to achieve above goal?
>
> The createStandardService method declared for the MBeanFactory doesn't
> exist. That pretty much kills any attempt to do this stone dead before
> you start.
>
> Looks like I did that in error almost a year ago. I'll add that method
> and the other methods removed at the time back.
Looks like I spoke too soon. Thsoe changes were in
http://svn.apache.org/viewvc?rev=778200&view=rev which as to get rid of
ServerFactory. Step one of this project will almost certainly be to
re-implement those methods without using the now deleted ServerFactory.
Mark
> With those in place it is a matter of testing to see what works and what
> doesn't. The problems are likely to be a combination of the following:
> - JMX getters/setters not aligned with changes to underlying objects
> - attributes exposed as read/write that should be read-only or need more
> work to make write operations safe
> - new objects not exposed via JMX
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: GSOC 2010
Posted by Mark Thomas <ma...@apache.org>.
On 12/03/2010 11:32, buddhika chamith wrote:
> Hi All,
>
> I am interested in working on the JMX related project idea.
Great.
> I am in the
> process of going through the documentation and sources relating to JMX in
> Tomcat. Excerpt of the idea mentions that "Tomcat instance to be configured
> entirely via JMX" is the goal of project. Since the JMX infrastructure is
> already present, are there any specific areas that you have already
> identified as lacking support in order to achieve above goal?
The createStandardService method declared for the MBeanFactory doesn't
exist. That pretty much kills any attempt to do this stone dead before
you start.
Looks like I did that in error almost a year ago. I'll add that method
and the other methods removed at the time back.
With those in place it is a matter of testing to see what works and what
doesn't. The problems are likely to be a combination of the following:
- JMX getters/setters not aligned with changes to underlying objects
- attributes exposed as read/write that should be read-only or need more
work to make write operations safe
- new objects not exposed via JMX
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org