date:20071207


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Viet Hung Nguyen resolved GERONIMO-3679.


   Resolution: Fixed
Fix Version/s: 2.1

 Montitoring console should display 'available statistics' in a more organized 
 way
 -

 Key: GERONIMO-3679
 URL: https://issues.apache.org/jira/browse/GERONIMO-3679
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: monitoring
Affects Versions: 2.1
 Environment: All
Reporter: Anita Kulshreshtha
Assignee: Viet Hung Nguyen
 Fix For: 2.1

 Attachments: geronimo-3679.patch


 Currently the Monitoring Console shows all statistics in a list. It is very 
 hard to make out what they are for.
 We need to categorize them according to their J2EETypes, e.g. for 
 J2EEType=WebModule, we should list them under
 Web Applications. The non standard J2EEtype, e.g WebConnectors should go 
 under a separate category.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [DISCUSS] Monitoring Client may need a new graphing engine

2007-12-07 Thread Paul McMahan

I have to agree with John that browser and platform support is the  
most important factor.  Furthermore, I think the ajax library in  
library in Geronimo should continue to be shared across its webapps.   
On both of these accounts I would lean heavily towards upgrading the  
monitoring client (and the admin console) to Dojo 1.0.1 since it has  
IE  Safari support and IMO is quickly becoming the open source ajax  
library of choice.   I am excited about running the admin console on  
my ipod touch :-)


Best wishes,
Paul

On Dec 7, 2007, at 6:46 AM, John Sisson wrote:


Erik B. Craig wrote:

All,

Currently the monitoring client is using Dojo 0.4.3 charting,  
which does not necessarily behave as expected on Firefox/Safari on  
a mac, or on IE6 on Windows.
I consider this to be a shortcoming, and given the new version of  
Dojo available (1.0.1), began investigating migrating the  
monitoring client over to the new version of Dojo, only to find  
that the new version of dojo appears to be a significant rewrite  
of the old code base, leaving out some features that I consider to  
be very visually pleasing and important for statistics viewing.  
While rummaging through the Dojo forums, I stumbled upon another  
Javascript graphing framework called Timeplot, which is part of  
the SIMILE project at MIT, and while this has it's own set of  
limitations... I'm trying to figure out the lesser of three evils  
before it comes a time that this monitoring plugin will be  
released, so that I have enough time (read: 3-5 days) to migrate  
the javascript generation over to something new if necessary.


I have created a small demonstration page that shows all three  
options graphed with the same data series, as well as weighing  
some of the advantages/disadvantages I could come up with,

Please have a look, and let me know your thoughts.

http://people.apache.org/~ecraig/graphdemo/

Personally, I think it would be really cool if we could use the  
Timeplot graphing libraries, as it is all BSD licensed and  
therefore friendly I believe (right, Kevan?)... and also EXTREMELY  
cool for showing multiple data series in one chart.


IMHO, as much as I dislike saying this.. IE support should be  
mandatory considering the number of users who use it.  The  
disadvantages of Dojo 1.0.1 sound pretty minor compared the other  
options not supporting browsers.


Regards,
John

[jira] Closed: (GERONIMO-3654) Moving o.a.g.s.jaas.NamedUPCredentailLoginModule to o.a.g.s.realm.providers


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vamsavardhana Reddy closed GERONIMO-3654.
-

Resolution: Fixed

Completed: At revision: 602089  
o Copied o.a.g.s.jaas.NamedUPCredentailLoginModule to 
o.a.g.s.realm.providers.NamedUsernamePasswordCredentialLoginModule
 o Marked NamedUPCredentialLoginModule as deprecated
 o Changed all references from o.a.g.s.jaas.NamedUPCredentialLoginModule to 
o.a.g.s.realm.providers.NamedUsernamePasswordCredentialLoginModule


 Moving o.a.g.s.jaas.NamedUPCredentailLoginModule to o.a.g.s.realm.providers
 ---

 Key: GERONIMO-3654
 URL: https://issues.apache.org/jira/browse/GERONIMO-3654
 Project: Geronimo
  Issue Type: Task
  Security Level: public(Regular issues) 
  Components: security
Affects Versions: 2.0.x, 2.1
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
 Fix For: 2.0.x, 2.1


 David Jencks suggested that we move 
 org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to 
 org.apache.geronimo.security.realm.providers package.  I intend to do the 
 following.
 1. svn copy org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to 
 org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule
 2. Make org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule extend 
 org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule.
 3. Mark org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule as 
 deprecated.
 4. Change all references from 
 org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to 
 org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule
 Does anyone see this coming in the way of compatibility?  I do not intend to 
 change the option name 
 org.apache.geronimo.jaas.NamedUPCredentialLoginModule.Name as this will 
 surely break compatibility.  Whether or not the move breaks compatibility, 
 should we consider this move only in trunk and not in branches\2.0?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [DISCUSS] Monitoring Client may need a new graphing engine

2007-12-07 Thread John Sisson


Erik B. Craig wrote:

All,

Currently the monitoring client is using Dojo 0.4.3 charting, which 
does not necessarily behave as expected on Firefox/Safari on a mac, or 
on IE6 on Windows.
I consider this to be a shortcoming, and given the new version of Dojo 
available (1.0.1), began investigating migrating the monitoring client 
over to the new version of Dojo, only to find that the new version of 
dojo appears to be a significant rewrite of the old code base, leaving 
out some features that I consider to be very visually pleasing and 
important for statistics viewing. While rummaging through the Dojo 
forums, I stumbled upon another Javascript graphing framework called 
Timeplot, which is part of the SIMILE project at MIT, and while this 
has it's own set of limitations... I'm trying to figure out the lesser 
of three evils before it comes a time that this monitoring plugin will 
be released, so that I have enough time (read: 3-5 days) to migrate 
the javascript generation over to something new if necessary.


I have created a small demonstration page that shows all three options 
graphed with the same data series, as well as weighing some of the 
advantages/disadvantages I could come up with,

Please have a look, and let me know your thoughts.

http://people.apache.org/~ecraig/graphdemo/

Personally, I think it would be really cool if we could use the 
Timeplot graphing libraries, as it is all BSD licensed and therefore 
friendly I believe (right, Kevan?)... and also EXTREMELY cool for 
showing multiple data series in one chart.


IMHO, as much as I dislike saying this.. IE support should be mandatory 
considering the number of users who use it.  The disadvantages of Dojo 
1.0.1 sound pretty minor compared the other options not supporting browsers.


Regards,
John

[jira] Created: (GERONIMO-3685) Monitoring Console should display TimeStatistics and BoundedRangeStatistics correctly

2007-12-07 Thread Anita Kulshreshtha (JIRA)

Monitoring Console should display TimeStatistics and BoundedRangeStatistics 
correctly
-

 Key: GERONIMO-3685
 URL: https://issues.apache.org/jira/browse/GERONIMO-3685
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: monitoring
 Environment: All
Reporter: Anita Kulshreshtha
Priority: Critical
 Fix For: 2.1


 . The Monitoring Console (MC) should display TimeStatistics and 
BoundedRangeStatistics as a single value. 
For example JVM Heap  or RequestTime or openConnections with a single link  
for graph.
. A band-aid solution to displaying TimeStatistics and BoundedRangeStatistics, 
and RangeStatistics is to add a field 'StatisticsType' to activeDB.
and graph 'count/totalTime' for Timestatistics and 'current' for 
BoundedRangeStatistics, RangeStatistics. 
. The graph builder recomputes min, max and avg. It is wasteful but acceptable 
for now.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] Make Yoko core orb a Yoko subproject.

2007-12-07 Thread Aaron Mulder

Sounds fine to me.

Thanks,
  Aaron

On Dec 6, 2007 9:43 AM, Rick McGuire [EMAIL PROTECTED] wrote:
 The discussion thread has been out there long enough for comment, and
 those who have responded appear positive about the prospect.  I think
 it's time to put this to a vote.  The full proposal from Matt Hogstrom
 is attached at the end, but the basic proposal we're voting on
 implementing in Geronimo is:

 1)  Accept the Yoko core modules (corba spec, corba core implemenation,
 rmi spec and rmi implementation) as a subproject of Geronimo.
 2)  The Yoko subproject will be maintained as a stand-alone component so
 it can be used by Harmony as well as Geronimo.
 3)  Lars Kuhn, Alexey Petrenko, and Darren Middleman be invited to join
 the Geronimo project as commiters so that they may continue contributing
 to the Yoko ORB.

 This is a single vote on the entire proposal (accepting the code and
 inviting the commiters).

 [ ] +1 Implement the Yoko ORB subproject in Geronimo as proposed above.
 [ ] 0 No opinion
 [ ] -1 Do not implement the Yoko subproject as proposed.

 Only PMC member's votes are binding, but we invite anybody in the
 community to speak up and vote on this.

 Since the vote runs over the weekend, I'll conclude it at 10::00 Eastern
 time on Monday.

 Rick

 Matt's full proposal presented to the Yoko project:

 The members of project yoko have been considering the future of Yoko as
 a project.  There have been several milestones delivered and the project
 is used by other ASF projects.   The project is not as active as other
 ASF projects and it makes sense to move the code from Yoko to other
 projects.  The Yoko team has the following proposal for your consideration.

 Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo

 The Yoko community has been successful in delivering several milestones
 of the ORB implementation while in the Apache Incubator.  These
 milestones are used by other Apache projects (namely Geronimo and
 Harmony) to support their releases.  The WebServices bindings are
 dependent on CXF.  The Yoko community has decided that the Yoko project
 does not have quite the momentum to carry itself as an independent
 project but has sufficient value for other projects for them to consider
 receiving the code and committers for that code-base as sub-projects.
 Since the code under consideration is used by Apache Geronimo, Apache
 CXF and Apache Harmony the movement of the code should continue to allow
 for independent releases so the code can be easily shared with other
 dependent projects.

 The proposed division is:

 yoko-spec-corba - this is the org.omg interface classes.
 rmi-spec - this is the javax.rmi spec implementation
 core - This is the actual ORB implementation.
 rmi-impl - This is the implementation of the RMIIIOP support.

 These modules are also used by Harmony.

 In addition to the code we propose that the following committers in
 Apache Yoko be accepted as committers in Apache Geronimo given their
 demonstration of delivering code, creating releases and functioning as a
 community.  Those noted with asterisks are already Geronimo committers.

 Continued involvement with the core:

 Rick McGuire *
 David Jencks *
 Alan Cabrera  *
 Lars Kuhne
 Alexey Petrenko
 Darren Middleman

 The remainder of the modules in Yoko are part of the webservices support
 and are independent of the underlying ORB implementation.

 api -- interface classes used for the web services support.
 bindings -- code to implement the CORBA-Web services bindings.
 tools -- tools for generation WSDL and IDL for the bindings
 maven-plugin -- some maven plugins that can use the tools for generating
 binding-related build artifacts.  None of the maven-plugin code is used
 by the ORB.

 There is also a distribution directory with some sample applications.
 One set of samples demonstrates using the core ORB, the other set is for
 WebServices.  We recommend that the distribution directory should move
 to Apache CXF as the webservices examples use the orb samples to bind
 them as web services.  Since Apache Geronimo's only use of CORBA is for
 exporting EJBs, these samples are not particularly valuable for Geronimo.

 The Yoko community did not have any committers that expressed an
 interest in continuing work on these bindings.  As such, only the code
 would be moving to apache CXF.

Re: How to get memory statistics from a remote Geronimo runtime?



On Dec 5, 2007, at 4:29 AM, Vamsavardhana Reddy wrote:




On Dec 4, 2007 11:23 PM, Anita Kulshreshtha [EMAIL PROTECTED]  
wrote:

  It is not clear to me if this is part of the earlier code or a
separate program. If it is part of the JMX code, then Runtime is from
the local jvm not remote. The non heap Memory for this program in
either case is negligible.
  You could start G with -Dcom.sun.management.jmxremote. Start
jconsole and click on the Memory tab to get the whole picture.
I have started G with the said option and hooked up jconsole.  The  
HeapMemoryUsage is showing exactly what Runtime is returning.


It is only the heap memory exhaustion that results in OOME.  I guess  
I am ok for now as this is what I am interested in.




One will get OOM Exceptions if there is insufficient native memory to  
satisfy a Java request.  For instance, when creating a thread, the OS  
has to allocate some native memory to create the Java Object. If that  
native allocation fails you will get an OOM even though you have  
plenty of heap memory.

Re: [VOTE] Release activation and jsvamail spec jars + javamail provider jars.

2007-12-07 Thread Guillaume Nodet

On Dec 7, 2007 1:36 PM, Rick McGuire [EMAIL PROTECTED] wrote:

 Guillaume Nodet wrote:
  I wasn't aware the parent pom had been released yesterday:
 http://repo1.maven.org/maven2/org/apache/geronimo/specs/specs/1.3/
  Did I miss something ?
 I wasn't sure a vote was needed on the parent pom...we'd never done that
 before.


Np, I had thought it would be part of the vote.




  Also, the associated tag (indicated in the pom) is missing:
 http://svn.apache.org/repos/asf/geronimo/specs/tags/1_3
 Yes, sorry.  I forgot to move that from branches to tags.


Great, thx for doing so.




 Rick
 
  On Dec 7, 2007 1:01 PM, Rick McGuire [EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED] wrote:
 
  [ ] +1 - Release the jars
  [ ] 0 - No opinion
  [ ] -1 - Do not release the jars
 
 
  We're voting on the following which are required for the Geronimo
 2.1
  release:
 
  1)  Release 1.0.0 of the activation 1.1 spec API.  The artifact in
  question is geronimo-activation_1.1_spec-1.0.1.  This is the
 OSGIfied
  jar file, needed because of the javamail dependency.   The release
  archive is located here:
 
 
 
 http://people.apache.org/~rickmcguire/releases/geronimo-activation_1.1_spec-1.0.1.tar.gzhttp://people.apache.org/%7Erickmcguire/releases/geronimo-activation_1.1_spec-1.0.1.tar.gz
  
 http://people.apache.org/%7Erickmcguire/releases/geronimo-activation_1.1_spec-1.0.1.tar.gz
 
 
  The current branch used to build the release candidate is at
 
 
 
 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-activation_1.1_spec-1.0.1
 
  The tag will be created at
 
 
 
 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-activation_1.1_spec-1.0.1
 
  2)  Release 1.2 of the javamail 1.4 spec API.  The artifact in
  question
  is geronimo-javamail_1.4_spec-1.2.  This jar has the OSGI changes,
  plus
  a number of bug fixes.  The release archive is located here:
 
 
 
 http://people.apache.org/~rickmcguire/releases/geronimo-javamail_1.4_spec-1.2.tar.gzhttp://people.apache.org/%7Erickmcguire/releases/geronimo-javamail_1.4_spec-1.2.tar.gz
  
 http://people.apache.org/%7Erickmcguire/releases/geronimo-javamail_1.4_spec-1.2.tar.gz
 
 
  The current branch used to build the release candidate is at
 
 
 
 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-javamail_1.4_spec-1.2
  
 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-javamail_1.4_spec-1.2
 
 
 
  The tag will be created at
 
 
 
 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-javamail_1.4_spec-1.2
  
 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-javamail_1.4_spec-1.2
 
 
  3)  Release 1.3 of the javamail 1.4 mail package.  This package
  includes
  new providers for the imap, imaps, and pop3s protocols and a
  significantly rewritten version of the pop3 provider. This package
  has a
  top level pom and two child artifacts:
 
  top level pom:  geronimo-javamail_1.4-1.3
  javamail providers:  geroinimo_javamail_1.4_provider-1.3
  javamail mail:geroinimo_javamail_1.4_mail-1.3
 
  The geroinimo_javamail_1.4_mail- 1.3 artifact is the uber-jar
  containing
  the merged spec and provider class files.  The release archive is
  located here:
 
 
 
 http://people.apache.org/~rickmcguire/releases/geronimo-javamail_1.4_-1.3.tar.gzhttp://people.apache.org/%7Erickmcguire/releases/geronimo-javamail_1.4_-1.3.tar.gz
  
 http://people.apache.org/%7Erickmcguire/releases/geronimo-javamail_1.4_-1.3.tar.gz
 
 
  The source used to build this is located at
 
 
 
 https://svn.apache.org/repos/asf/geronimo/javamail/branches/geronimo-javamail_1.4-1.3
 
 
  The tag will be created at
 
 
 
 https://svn.apache.org/repos/asf/geronimo/javamail/tags/geronimo-javamail_1.4-1.3
 
 
 
 
  --
  Cheers,
  Guillaume Nodet
  
  Blog: http://gnodet.blogspot.com/




-- 
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

[VOTE] Release activation and jsvamail spec jars + javamail provider jars.

2007-12-07 Thread Rick McGuire


[ ] +1 - Release the jars
[ ] 0 - No opinion
[ ] -1 - Do not release the jars


We're voting on the following which are required for the Geronimo 2.1 
release:


1)  Release 1.0.0 of the activation 1.1 spec API.  The artifact in 
question is geronimo-activation_1.1_spec-1.0.1.  This is the OSGIfied 
jar file, needed because of the javamail dependency.   The release 
archive is located here:


   
http://people.apache.org/~rickmcguire/releases/geronimo-activation_1.1_spec-1.0.1.tar.gz


The current branch used to build the release candidate is at

  
https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-activation_1.1_spec-1.0.1


The tag will be created at

  
https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-activation_1.1_spec-1.0.1


2)  Release 1.2 of the javamail 1.4 spec API.  The artifact in question 
is geronimo-javamail_1.4_spec-1.2.  This jar has the OSGI changes, plus 
a number of bug fixes.  The release archive is located here:


   
http://people.apache.org/~rickmcguire/releases/geronimo-javamail_1.4_spec-1.2.tar.gz


The current branch used to build the release candidate is at

  
https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-javamail_1.4_spec-1.2 



The tag will be created at

  
https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-javamail_1.4_spec-1.2


3)  Release 1.3 of the javamail 1.4 mail package.  This package includes 
new providers for the imap, imaps, and pop3s protocols and a 
significantly rewritten version of the pop3 provider. This package has a 
top level pom and two child artifacts:


top level pom:  geronimo-javamail_1.4-1.3
javamail providers:  geroinimo_javamail_1.4_provider-1.3
javamail mail:geroinimo_javamail_1.4_mail-1.3

The geroinimo_javamail_1.4_mail-1.3 artifact is the uber-jar containing 
the merged spec and provider class files.  The release archive is 
located here: 

   
http://people.apache.org/~rickmcguire/releases/geronimo-javamail_1.4_-1.3.tar.gz


The source used to build this is located at

  
https://svn.apache.org/repos/asf/geronimo/javamail/branches/geronimo-javamail_1.4-1.3 



The tag will be created at

  
https://svn.apache.org/repos/asf/geronimo/javamail/tags/geronimo-javamail_1.4-1.3

[jira] Assigned: (GERONIMO-3606) GShell-ize client


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarek Gawor reassigned GERONIMO-3606:
-

Assignee: Jarek Gawor  (was: David Jencks)

 GShell-ize client
 -

 Key: GERONIMO-3606
 URL: https://issues.apache.org/jira/browse/GERONIMO-3606
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: application client
Affects Versions: 2.1
Reporter: David Jencks
Assignee: Jarek Gawor
 Fix For: 2.1


 Run the app client from gshell

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk

2007-12-07 Thread Kevan Miller



On Dec 7, 2007, at 9:11 AM, Anita Kulshreshtha wrote:



--- Kevan Miller [EMAIL PROTECTED] wrote:



On Dec 6, 2007, at 7:38 AM, Anita Kulshreshtha wrote:



--- Viet Nguyen [EMAIL PROTECTED] wrote:


On Dec 5, 2007 11:36 PM, Anita Kulshreshtha [EMAIL PROTECTED]
wrote:

Eric,

.


  Perhaps I am not making it clear. The graph that is shown as
requestTime for tomcatWebConnector is incorrect. The value returned

by

tomcat is count not time. We need to have different methods to
generate
graphs for TimeStatistics, RangeStatistics, and
BoundedRangeStatistics.


OK. That's good information.


  But a very important one for a user who takes the trouble to install
the plugins and reads the document about monitoring and statistics.

But, IMO, that doesn't necessarily mean


we shouldn't move the monitoring plugin out of sandbox. It might mean

that we aren't ready to *release* the monitoring plugin. I don't
think
we're having a *release* discussion -- at least we shouldn't be.


   If the plugin is moved to trunk, as the title of the discussion
says, does it not get automatically released?


It would be released *when* we release the code in trunk (in this case  
with Geronimo 2.1). Until we release, it's under development just like  
the rest of the server (and subject to change).





We

can have the discussion that we don't want to hold up a Geronimo 2.1

release waiting for monitoring plugin problems to be resolved, but
I'd
prefer we discuss without a particular timeline in mind...

IMO, we have the following questions to answer:

1. Are we ready to move monitoring plugin out of sandbox?


yes


2. If yes, then where should we move it to? Should it be in server/
trunk/plugins or should the monitoring plugin be a subproject.


   I was thinking of plugins..


3. What bug fixes/new features need to be added to the monitoring
plugin before it's ready to be released?


  We should do the minimum and make sure all the information that is
displayed is correct, i.e. there is no discrepancy between the raw
value (displayed on the console) and the graph. We can address the  
fact

the values themselves are skewed later.


OK. Sounds good. I see you've been generating jira's against the admin  
console. I assume they are recording the functions that need to be  
fixed?


--kevan

Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk

2007-12-07 Thread Anita Kulshreshtha


--- Kevan Miller [EMAIL PROTECTED] wrote:

 
 On Dec 6, 2007, at 7:38 AM, Anita Kulshreshtha wrote:
 
 
  --- Viet Nguyen [EMAIL PROTECTED] wrote:
 
  On Dec 5, 2007 11:36 PM, Anita Kulshreshtha [EMAIL PROTECTED]
  wrote:
  Eric,
.
 
 Perhaps I am not making it clear. The graph that is shown as
  requestTime for tomcatWebConnector is incorrect. The value returned
 by
  tomcat is count not time. We need to have different methods to  
  generate
  graphs for TimeStatistics, RangeStatistics, and  
  BoundedRangeStatistics.
 
 OK. That's good information. 

   But a very important one for a user who takes the trouble to install
the plugins and reads the document about monitoring and statistics.

But, IMO, that doesn't necessarily mean 
 
 we shouldn't move the monitoring plugin out of sandbox. It might mean
  
 that we aren't ready to *release* the monitoring plugin. I don't
 think  
 we're having a *release* discussion -- at least we shouldn't be. 

If the plugin is moved to trunk, as the title of the discussion
says, does it not get automatically released? 

We  
 can have the discussion that we don't want to hold up a Geronimo 2.1 
 
 release waiting for monitoring plugin problems to be resolved, but
 I'd  
 prefer we discuss without a particular timeline in mind...
 
 IMO, we have the following questions to answer:
 
 1. Are we ready to move monitoring plugin out of sandbox?

yes

 2. If yes, then where should we move it to? Should it be in server/ 
 trunk/plugins or should the monitoring plugin be a subproject.

I was thinking of plugins..

 3. What bug fixes/new features need to be added to the monitoring  
 plugin before it's ready to be released?

   We should do the minimum and make sure all the information that is
displayed is correct, i.e. there is no discrepancy between the raw
value (displayed on the console) and the graph. We can address the fact
the values themselves are skewed later.

Thanks
Anita


 
 Anita,
 Your objections seem to be in category 3, but I may be wrong. So,
 help  
 us understand what you're thinking...
 
 --kevan
 
 



  

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

Re: [VOTE] Make Yoko core orb a Yoko subproject.

2007-12-07 Thread Tim Ellison

+1

Rick McGuire wrote:
 The discussion thread has been out there long enough for comment, and
 those who have responded appear positive about the prospect.  I think
 it's time to put this to a vote.  The full proposal from Matt Hogstrom
 is attached at the end, but the basic proposal we're voting on
 implementing in Geronimo is:
 
 1)  Accept the Yoko core modules (corba spec, corba core implemenation,
 rmi spec and rmi implementation) as a subproject of Geronimo.
 2)  The Yoko subproject will be maintained as a stand-alone component so
 it can be used by Harmony as well as Geronimo.
 3)  Lars Kuhn, Alexey Petrenko, and Darren Middleman be invited to join
 the Geronimo project as commiters so that they may continue contributing
 to the Yoko ORB.
 
 This is a single vote on the entire proposal (accepting the code and
 inviting the commiters).
 
 [ ] +1 Implement the Yoko ORB subproject in Geronimo as proposed above.
 [ ] 0 No opinion
 [ ] -1 Do not implement the Yoko subproject as proposed.
 Only PMC member's votes are binding, but we invite anybody in the
 community to speak up and vote on this.
 
 Since the vote runs over the weekend, I'll conclude it at 10::00 Eastern
 time on Monday.
 
 Rick
 
 Matt's full proposal presented to the Yoko project:
 
 The members of project yoko have been considering the future of Yoko as
 a project.  There have been several milestones delivered and the project
 is used by other ASF projects.   The project is not as active as other
 ASF projects and it makes sense to move the code from Yoko to other
 projects.  The Yoko team has the following proposal for your consideration.
 
 Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo
 
 The Yoko community has been successful in delivering several milestones
 of the ORB implementation while in the Apache Incubator.  These
 milestones are used by other Apache projects (namely Geronimo and
 Harmony) to support their releases.  The WebServices bindings are
 dependent on CXF.  The Yoko community has decided that the Yoko project
 does not have quite the momentum to carry itself as an independent
 project but has sufficient value for other projects for them to consider
 receiving the code and committers for that code-base as sub-projects. 
 Since the code under consideration is used by Apache Geronimo, Apache
 CXF and Apache Harmony the movement of the code should continue to allow
 for independent releases so the code can be easily shared with other
 dependent projects.
 
 The proposed division is:
 
 yoko-spec-corba - this is the org.omg interface classes.
 rmi-spec - this is the javax.rmi spec implementation
 core - This is the actual ORB implementation.
 rmi-impl - This is the implementation of the RMIIIOP support.
 
 These modules are also used by Harmony.
 
 In addition to the code we propose that the following committers in
 Apache Yoko be accepted as committers in Apache Geronimo given their
 demonstration of delivering code, creating releases and functioning as a
 community.  Those noted with asterisks are already Geronimo committers.
 
 Continued involvement with the core:
 
 Rick McGuire *
 David Jencks *
 Alan Cabrera  *
 Lars Kuhne
 Alexey Petrenko
 Darren Middleman
 
 The remainder of the modules in Yoko are part of the webservices support
 and are independent of the underlying ORB implementation.
 
 api -- interface classes used for the web services support.
 bindings -- code to implement the CORBA-Web services bindings.
 tools -- tools for generation WSDL and IDL for the bindings
 maven-plugin -- some maven plugins that can use the tools for generating
 binding-related build artifacts.  None of the maven-plugin code is used
 by the ORB.
 
 There is also a distribution directory with some sample applications. 
 One set of samples demonstrates using the core ORB, the other set is for
 WebServices.  We recommend that the distribution directory should move
 to Apache CXF as the webservices examples use the orb samples to bind
 them as web services.  Since Apache Geronimo's only use of CORBA is for
 exporting EJBs, these samples are not particularly valuable for Geronimo.
 
 The Yoko community did not have any committers that expressed an
 interest in continuing work on these bindings.  As such, only the code
 would be moving to apache CXF.

Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk

2007-12-07 Thread Anita Kulshreshtha

We definitely need such an adapter interface. This will allow us to
not corrupt the target instance, e.g. a minimal server, by installing
openejb.

Thanks
Anita

--- Jeff Genender [EMAIL PROTECTED] wrote:

 So I think we are kind of caught in a catch 22 here...
 
 The issue is, the server is pluggable for the most part.  People
 may/may
 not want EJB, but definitely want the management capabilities.
 
 Whats your thought on an adapter interface that provides for full
 JSR-77
 compatibility, thus requiring EJB, or a switch that allows for pure
 JMX
 remoting?  This would allow for compliance or be able to leverage the
 management without EJB if so desired.
 
 Thoughts?



  

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

Re: [VOTE] Release activation and jsvamail spec jars + javamail provider jars.

2007-12-07 Thread Guillaume Nodet

I wasn't aware the parent pom had been released yesterday:
   http://repo1.maven.org/maven2/org/apache/geronimo/specs/specs/1.3/
Did I miss something ?
Also, the associated tag (indicated in the pom) is missing:
   http://svn.apache.org/repos/asf/geronimo/specs/tags/1_3

On Dec 7, 2007 1:01 PM, Rick McGuire [EMAIL PROTECTED] wrote:

 [ ] +1 - Release the jars
 [ ] 0 - No opinion
 [ ] -1 - Do not release the jars


 We're voting on the following which are required for the Geronimo 2.1
 release:

 1)  Release 1.0.0 of the activation 1.1 spec API.  The artifact in
 question is geronimo-activation_1.1_spec-1.0.1.  This is the OSGIfied
 jar file, needed because of the javamail dependency.   The release
 archive is located here:



 http://people.apache.org/~rickmcguire/releases/geronimo-activation_1.1_spec-1.0.1.tar.gzhttp://people.apache.org/%7Erickmcguire/releases/geronimo-activation_1.1_spec-1.0.1.tar.gz

 The current branch used to build the release candidate is at



 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-activation_1.1_spec-1.0.1

 The tag will be created at



 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-activation_1.1_spec-1.0.1

 2)  Release 1.2 of the javamail 1.4 spec API.  The artifact in question
 is geronimo-javamail_1.4_spec-1.2.  This jar has the OSGI changes, plus
 a number of bug fixes.  The release archive is located here:



 http://people.apache.org/~rickmcguire/releases/geronimo-javamail_1.4_spec-1.2.tar.gzhttp://people.apache.org/%7Erickmcguire/releases/geronimo-javamail_1.4_spec-1.2.tar.gz

 The current branch used to build the release candidate is at



 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-javamail_1.4_spec-1.2


 The tag will be created at



 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-javamail_1.4_spec-1.2

 3)  Release 1.3 of the javamail 1.4 mail package.  This package includes
 new providers for the imap, imaps, and pop3s protocols and a
 significantly rewritten version of the pop3 provider. This package has a
 top level pom and two child artifacts:

 top level pom:  geronimo-javamail_1.4-1.3
 javamail providers:  geroinimo_javamail_1.4_provider-1.3
 javamail mail:geroinimo_javamail_1.4_mail-1.3

 The geroinimo_javamail_1.4_mail-1.3 artifact is the uber-jar containing
 the merged spec and provider class files.  The release archive is
 located here:



 http://people.apache.org/~rickmcguire/releases/geronimo-javamail_1.4_-1.3.tar.gzhttp://people.apache.org/%7Erickmcguire/releases/geronimo-javamail_1.4_-1.3.tar.gz

 The source used to build this is located at



 https://svn.apache.org/repos/asf/geronimo/javamail/branches/geronimo-javamail_1.4-1.3


 The tag will be created at



 https://svn.apache.org/repos/asf/geronimo/javamail/tags/geronimo-javamail_1.4-1.3




-- 
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Re: [VOTE] Make Yoko core orb a Yoko subproject.

2007-12-07 Thread Jacek Laskowski

+1

Jacek

On Dec 6, 2007 3:43 PM, Rick McGuire [EMAIL PROTECTED] wrote:
 The discussion thread has been out there long enough for comment, and
 those who have responded appear positive about the prospect.  I think
 it's time to put this to a vote.  The full proposal from Matt Hogstrom
 is attached at the end, but the basic proposal we're voting on
 implementing in Geronimo is:

 1)  Accept the Yoko core modules (corba spec, corba core implemenation,
 rmi spec and rmi implementation) as a subproject of Geronimo.
 2)  The Yoko subproject will be maintained as a stand-alone component so
 it can be used by Harmony as well as Geronimo.
 3)  Lars Kuhn, Alexey Petrenko, and Darren Middleman be invited to join
 the Geronimo project as commiters so that they may continue contributing
 to the Yoko ORB.

 This is a single vote on the entire proposal (accepting the code and
 inviting the commiters).

 [ ] +1 Implement the Yoko ORB subproject in Geronimo as proposed above.
 [ ] 0 No opinion
 [ ] -1 Do not implement the Yoko subproject as proposed.

 Only PMC member's votes are binding, but we invite anybody in the
 community to speak up and vote on this.

 Since the vote runs over the weekend, I'll conclude it at 10::00 Eastern
 time on Monday.

 Rick

 Matt's full proposal presented to the Yoko project:

 The members of project yoko have been considering the future of Yoko as
 a project.  There have been several milestones delivered and the project
 is used by other ASF projects.   The project is not as active as other
 ASF projects and it makes sense to move the code from Yoko to other
 projects.  The Yoko team has the following proposal for your consideration.

 Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo

 The Yoko community has been successful in delivering several milestones
 of the ORB implementation while in the Apache Incubator.  These
 milestones are used by other Apache projects (namely Geronimo and
 Harmony) to support their releases.  The WebServices bindings are
 dependent on CXF.  The Yoko community has decided that the Yoko project
 does not have quite the momentum to carry itself as an independent
 project but has sufficient value for other projects for them to consider
 receiving the code and committers for that code-base as sub-projects.
 Since the code under consideration is used by Apache Geronimo, Apache
 CXF and Apache Harmony the movement of the code should continue to allow
 for independent releases so the code can be easily shared with other
 dependent projects.

 The proposed division is:

 yoko-spec-corba - this is the org.omg interface classes.
 rmi-spec - this is the javax.rmi spec implementation
 core - This is the actual ORB implementation.
 rmi-impl - This is the implementation of the RMIIIOP support.

 These modules are also used by Harmony.

 In addition to the code we propose that the following committers in
 Apache Yoko be accepted as committers in Apache Geronimo given their
 demonstration of delivering code, creating releases and functioning as a
 community.  Those noted with asterisks are already Geronimo committers.

 Continued involvement with the core:

 Rick McGuire *
 David Jencks *
 Alan Cabrera  *
 Lars Kuhne
 Alexey Petrenko
 Darren Middleman

 The remainder of the modules in Yoko are part of the webservices support
 and are independent of the underlying ORB implementation.

 api -- interface classes used for the web services support.
 bindings -- code to implement the CORBA-Web services bindings.
 tools -- tools for generation WSDL and IDL for the bindings
 maven-plugin -- some maven plugins that can use the tools for generating
 binding-related build artifacts.  None of the maven-plugin code is used
 by the ORB.

 There is also a distribution directory with some sample applications.
 One set of samples demonstrates using the core ORB, the other set is for
 WebServices.  We recommend that the distribution directory should move
 to Apache CXF as the webservices examples use the orb samples to bind
 them as web services.  Since Apache Geronimo's only use of CORBA is for
 exporting EJBs, these samples are not particularly valuable for Geronimo.

 The Yoko community did not have any committers that expressed an
 interest in continuing work on these bindings.  As such, only the code
 would be moving to apache CXF.





-- 
Jacek Laskowski
http://www.JacekLaskowski.pl

[jira] Updated: (GERONIMO-3554) monitoring plugin: client should use an ArrayList instead of a Vector


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Viet Hung Nguyen updated GERONIMO-3554:
---

Attachment: geronimo-3554.patch

 monitoring plugin: client should use an ArrayList instead of a Vector
 -

 Key: GERONIMO-3554
 URL: https://issues.apache.org/jira/browse/GERONIMO-3554
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: monitoring
Affects Versions: 2.1
 Environment: windows
Reporter: Viet Hung Nguyen
Assignee: Viet Hung Nguyen
Priority: Trivial
 Attachments: geronimo-3554.patch


 There are some places in the client code where Vectors are used. ArrayLists 
 would be a better type for this particular instance because of efficiency. 
 Vectors are used for synchronization purposes, which the client does not need 
 to do. ArrayLists would be faster and serve the same purpose in this case.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-3625) Review WrappingLoginModule


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vamsavardhana Reddy closed GERONIMO-3625.
-

Resolution: Fixed

 Review WrappingLoginModule
 --

 Key: GERONIMO-3625
 URL: https://issues.apache.org/jira/browse/GERONIMO-3625
 Project: Geronimo
  Issue Type: Task
  Security Level: public(Regular issues) 
  Components: security
Affects Versions: 2.0.x, 2.1
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
 Fix For: 2.0.x, 2.1


 Review WrappingLoginModule for potential violations and security risks.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-3686) AsyncHttpClient does not reuse connection even if connections are persistent

[
https://issues.apache.org/jira/browse/GERONIMO-3686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549506
]

Sangjin Lee commented on GERONIMO-3686:
---

Here is a proposal on how the connection reuse may work.

- Once an IoSession is opened and used successfully for a request-response
cycle, at the end of the response processing, we cache the IoSession.
- The sessions are stored keyed by the remote peer (host + port). For the
given remote peer, sessions should be cached in a FIFO manner. A non-blocking
queue might be a good candidate.
- When sessions close for any reason (i.e. when the handler gets notified via
sessionClosed()), we remove the session from the cache.
- On sendRequest(), AsyncHttpClient should first check the session cache to see
if there is an available active session. It should also check if the session
is still connected. If not, it can keep peeling the queue until it finds one
or it exhausts the queue.
- If it fails to find a connected cached session, then it opens a new
connection.
- The keep-alive config on AsyncHttpClient should provide a different behavior.
If keepAlive is set to false, then AsyncHttpClient should always open a new
connection, ignoring the session cache. Furthermore, if keepAlive is set to
false, it should add a Connection: close header to make it explicit.
- The session cache may be global, and should be shared safely by multiple
instances of AsyncHttpClient.

Thoughts? Comments?

AsyncHttpClient does not reuse connection even if connections are persistent

Key: GERONIMO-3686
URL: https://issues.apache.org/jira/browse/GERONIMO-3686
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: AsyncHttpClient
Affects Versions: 1.x
Reporter: Sangjin Lee

Each time AsyncHttpClient.sendRequest() is called, a new TCP connection is
opened, even though connections may be kept alive per HTTP spec. If
connections are kept open, they should be reused for more requests.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-3686) AsyncHttpClient does not reuse connection even if connections are persistent

AsyncHttpClient does not reuse connection even if connections are persistent


 Key: GERONIMO-3686
 URL: https://issues.apache.org/jira/browse/GERONIMO-3686
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: AsyncHttpClient
Affects Versions: 1.x
Reporter: Sangjin Lee


Each time AsyncHttpClient.sendRequest() is called, a new TCP connection is 
opened, even though connections may be kept alive per HTTP spec.  If 
connections are kept open, they should be reused for more requests.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-3650) Review ConfiguredIdentityNamedUsernamePasswordLoginModule


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vamsavardhana Reddy closed GERONIMO-3650.
-

Resolution: Fixed

 Review ConfiguredIdentityNamedUsernamePasswordLoginModule
 -

 Key: GERONIMO-3650
 URL: https://issues.apache.org/jira/browse/GERONIMO-3650
 Project: Geronimo
  Issue Type: Task
  Security Level: public(Regular issues) 
  Components: security
Affects Versions: 2.0.x, 2.1
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
 Fix For: 2.0.x, 2.1


 Review ConfiguredIdentityNamedUsernamePasswordLoginModule for potential 
 violations and security risks.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-3626) Review NamedUPCredentialLoginModule


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vamsavardhana Reddy closed GERONIMO-3626.
-

Resolution: Fixed

 Review NamedUPCredentialLoginModule
 ---

 Key: GERONIMO-3626
 URL: https://issues.apache.org/jira/browse/GERONIMO-3626
 Project: Geronimo
  Issue Type: Task
  Security Level: public(Regular issues) 
  Components: security
Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
 Fix For: 2.0.x, 2.1


 Review NamedUPCredentialLoginModule for potential violations and security 
 risks.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-3652) Review CallerIdentityPasswordCredentialLoginModule


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vamsavardhana Reddy closed GERONIMO-3652.
-

Resolution: Fixed

 Review CallerIdentityPasswordCredentialLoginModule
 --

 Key: GERONIMO-3652
 URL: https://issues.apache.org/jira/browse/GERONIMO-3652
 Project: Geronimo
  Issue Type: Task
  Security Level: public(Regular issues) 
  Components: connector
Affects Versions: 2.0.x, 2.1
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
 Fix For: 2.0.x, 2.1


 Review CallerIdentityPasswordCredentialLoginModule for potential violations 
 and security risks.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-3640) Eliminate UPCredentialLoginModule


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vamsavardhana Reddy closed GERONIMO-3640.
-

Resolution: Fixed

 Eliminate UPCredentialLoginModule
 -

 Key: GERONIMO-3640
 URL: https://issues.apache.org/jira/browse/GERONIMO-3640
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: security
Affects Versions: 2.0.x, 2.1
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
 Fix For: 2.0.x, 2.1


 UPCredentialLoginModule seems to serve the same purpose as 
 GeronimoPasswordCredentialLoginModule.  Searching the codebase for references 
 to UPCredentialLoginModule yields no results. Also 
 GeronimoPasswordCredentialLoginModule is the one used by Security realms 
 portlet.  It may be a good idea to eliminate UPCredentialLoginModule and 
 related classes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-3686) AsyncHttpClient does not reuse connection even if connections are persistent

2007-12-07 Thread Jeff Genender (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-3686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549510
 ] 

Jeff Genender commented on GERONIMO-3686:
-

Cool stuff.  Yep...FIFO would be the way I would do the queues.  A 
ConcurrentLinkedQueue is perfect for this.  For the container that holds these 
queues, a ConcurrentHashmap would be great.

Instead of the sendRequest() checking the connection validation, why not make 
this a facet of the checking out.  In fact this whole thing could be part of a 
connection manager/connection cache that will return one if it exists (an is 
valid) or creates it if one doesn't.

The ideas look very sound and looks good to me.

 AsyncHttpClient does not reuse connection even if connections are persistent
 

 Key: GERONIMO-3686
 URL: https://issues.apache.org/jira/browse/GERONIMO-3686
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: AsyncHttpClient
Affects Versions: 1.x
Reporter: Sangjin Lee

 Each time AsyncHttpClient.sendRequest() is called, a new TCP connection is 
 opened, even though connections may be kept alive per HTTP spec.  If 
 connections are kept open, they should be reused for more requests.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-3685) Monitoring Console should display TimeStatistics and BoundedRangeStatistics correctly

2007-12-07 Thread Anita Kulshreshtha (JIRA)

[
https://issues.apache.org/jira/browse/GERONIMO-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Anita Kulshreshtha updated GERONIMO-3685:
-

Description:
. The Monitoring Console (MC) should display TimeStatistics and
BoundedRangeStatistics as a single value.
For example JVM Heap or RequestTime or openConnections with a single link
for graph.
. A band-aid solution to displaying TimeStatistics and BoundedRangeStatistics,
and RangeStatistics is to add a field 'StatisticsType' to activeDB.
and graph 'totalTime/count' for Timestatistics and 'current' for
BoundedRangeStatistics, RangeStatistics.
. The graph builder recomputes min, max and avg. It is wasteful but acceptable
for now.

was:
. The Monitoring Console (MC) should display TimeStatistics and
BoundedRangeStatistics as a single value.
For example JVM Heap or RequestTime or openConnections with a single link
for graph.
. A band-aid solution to displaying TimeStatistics and BoundedRangeStatistics,
and RangeStatistics is to add a field 'StatisticsType' to activeDB.
and graph 'count/totalTime' for Timestatistics and 'current' for
BoundedRangeStatistics, RangeStatistics.
. The graph builder recomputes min, max and avg. It is wasteful but acceptable
for now.

Monitoring Console should display TimeStatistics and BoundedRangeStatistics
correctly
-

Key: GERONIMO-3685
URL: https://issues.apache.org/jira/browse/GERONIMO-3685
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: monitoring
Environment: All
Reporter: Anita Kulshreshtha
Priority: Critical
Fix For: 2.1

. The Monitoring Console (MC) should display TimeStatistics and
BoundedRangeStatistics as a single value.
For example JVM Heap or RequestTime or openConnections with a single
link for graph.
. A band-aid solution to displaying TimeStatistics and
BoundedRangeStatistics, and RangeStatistics is to add a field
'StatisticsType' to activeDB.
and graph 'totalTime/count' for Timestatistics and 'current' for
BoundedRangeStatistics, RangeStatistics.
. The graph builder recomputes min, max and avg. It is wasteful but
acceptable for now.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [DISCUSS] Monitoring Client may need a new graphing engine

2007-12-07 Thread Joe Bohn

I had an off-line discussion with Erik about IE support of the various 
charting solutions.  I *thought* Erik was saying that Dojo 0.4.3 
charting works with IE, but just not always as expected.  Actually, it 
turns out that Dojo 0.4.3 charting does not work with IE at all (similar 
to timeplot).  That means that Dojo 1.0.1 charting is the only solution 
that will support IE.


I agree with John  Paul that browser support on windows is important. 
With this new understanding of IE support I'm now thinking Dojo 1.0.1 
might be the better choice (even though I like the look and labels of 
Dojo 0.4.3 better).


Joe



was under the impression that IE worked with

Paul McMahan wrote:
I have to agree with John that browser and platform support is the most 
important factor.  Furthermore, I think the ajax library in library in 
Geronimo should continue to be shared across its webapps.  On both of 
these accounts I would lean heavily towards upgrading the monitoring 
client (and the admin console) to Dojo 1.0.1 since it has IE  Safari 
support and IMO is quickly becoming the open source ajax library of 
choice.   I am excited about running the admin console on my ipod touch :-)


Best wishes,
Paul

On Dec 7, 2007, at 6:46 AM, John Sisson wrote:


Erik B. Craig wrote:

All,

Currently the monitoring client is using Dojo 0.4.3 charting, which 
does not necessarily behave as expected on Firefox/Safari on a mac, 
or on IE6 on Windows.
I consider this to be a shortcoming, and given the new version of 
Dojo available (1.0.1), began investigating migrating the monitoring 
client over to the new version of Dojo, only to find that the new 
version of dojo appears to be a significant rewrite of the old code 
base, leaving out some features that I consider to be very visually 
pleasing and important for statistics viewing. While rummaging 
through the Dojo forums, I stumbled upon another Javascript graphing 
framework called Timeplot, which is part of the SIMILE project at 
MIT, and while this has it's own set of limitations... I'm trying to 
figure out the lesser of three evils before it comes a time that this 
monitoring plugin will be released, so that I have enough time (read: 
3-5 days) to migrate the javascript generation over to something new 
if necessary.


I have created a small demonstration page that shows all three 
options graphed with the same data series, as well as weighing some 
of the advantages/disadvantages I could come up with,

Please have a look, and let me know your thoughts.

http://people.apache.org/~ecraig/graphdemo/

Personally, I think it would be really cool if we could use the 
Timeplot graphing libraries, as it is all BSD licensed and therefore 
friendly I believe (right, Kevan?)... and also EXTREMELY cool for 
showing multiple data series in one chart.


IMHO, as much as I dislike saying this.. IE support should be 
mandatory considering the number of users who use it.  The 
disadvantages of Dojo 1.0.1 sound pretty minor compared the other 
options not supporting browsers.


Regards,
John

Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk



On Dec 6, 2007, at 12:45 PM, Viet Nguyen wrote:


There are goods and bads to both sides to this. If we strictly follow
JSR 77, which means we will use MEJB and are forced to have OpenEJB as
a pre-req, we won't have to worry if our architecture is good or not
(I hope this is right), because we're following a standard for
monitoring and management. On the flip side, if we use JMX to get a
hold of the statistics, we will be able to monitor any type of server.


I'm aware that some commercial servers make sure that they support  
JSR-77 as they have to.  Unfortunately, JSR-77 can be heavy and the  
commercial servers, *they who must not be named*, use lighter weight  
stuff under the covers and use their statistics for monitoring and  
make JSR-77 available for those that want to code to it.  JSR-77 is a  
required implementation but not the only way to do it.

Re: [DISCUSS] Monitoring Client may need a new graphing engine



On Dec 7, 2007, at 6:46 AM, John Sisson wrote:



IMHO, as much as I dislike saying this.. IE support should be  
mandatory considering the number of users who use it.  The  
disadvantages of Dojo 1.0.1 sound pretty minor compared the other  
options not supporting browsers.



I think browser support should be primary consideration as well.  I  
think 1.0.1 is the best choice given the trade-offs.

[jira] Closed: (GSHELL-94) Update LICENSE and NOTICE info for 1.0-alpha-1 release


 [ 
https://issues.apache.org/jira/browse/GSHELL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kevan Miller closed GSHELL-94.
--

Resolution: Fixed

Done

 Update LICENSE and NOTICE info for 1.0-alpha-1 release
 --

 Key: GSHELL-94
 URL: https://issues.apache.org/jira/browse/GSHELL-94
 Project: GShell
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: Documentation
Affects Versions: 1.0-alpha-1
Reporter: Kevan Miller
Assignee: Kevan Miller
 Fix For: 1.0-alpha-1


 The LICENSE and NOTICE files for assembly and the root source directory need 
 to be updated with actual license and notice information

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (GERONIMO-3605) GShell-ize deployer commands


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarek Gawor reassigned GERONIMO-3605:
-

Assignee: Jarek Gawor  (was: David Jencks)

 GShell-ize deployer commands
 

 Key: GERONIMO-3605
 URL: https://issues.apache.org/jira/browse/GERONIMO-3605
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: deployment
Affects Versions: 2.1
Reporter: David Jencks
Assignee: Jarek Gawor
 Fix For: 2.1


 make the cli deployer commands such as list-plugins accessible through gshell 
 (and then remove the standalone deployer)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-3687) classloader deadlock during server startup


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kevan Miller closed GERONIMO-3687.
--

Resolution: Fixed

Working for me. Let me know if there are any problems...

 classloader deadlock during server startup
 --

 Key: GERONIMO-3687
 URL: https://issues.apache.org/jira/browse/GERONIMO-3687
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
Affects Versions: 2.0.2, 2.1
Reporter: Kevan Miller
Assignee: Kevan Miller
 Fix For: 2.0.x, 2.1


 I've been seeing regular deadlocks running Geronimo on Leopard.
 It's the same basic scenario as found in GERONIMO-3141. For some reason, the 
 work around in 3141 doesn't work for me on Leopard.
 Just another hack and I'm sure we can fix this...
 Here's background info...
 $ ./geronimo.sh run
 Using GERONIMO_BASE:   /Users/kevan/geronimo-jetty6-jee5-2.0.2
 Using GERONIMO_HOME:   /Users/kevan/geronimo-jetty6-jee5-2.0.2
 Using GERONIMO_TMPDIR: var/temp
 Using JRE_HOME:
 /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home
 You can then send the java process a QUIT signal (kill -3 pid) to have java 
 dump out the thread stack traces. The deadlock occurs during a load of an 
 Iterator class (IIRC). The JVM is not well behaved, IMO. Here's the thread 
 stack traces that I get:
 Full thread dump Java HotSpot(TM) Client VM (1.5.0_13-119 mixed mode):
 Low Memory Detector daemon prio=5 tid=0x01009d60 nid=0x858800 runnable 
 [0x..0x]
 CompilerThread0 daemon prio=9 tid=0x01009330 nid=0x857a00 waiting on 
 condition [0x..0x]
 Signal Dispatcher daemon prio=9 tid=0x01008e60 nid=0x855e00 waiting on 
 condition [0x..0x]
 Finalizer daemon prio=8 tid=0x01007d10 nid=0x81ba00 waiting for monitor 
 entry [0xb0a05000..0xb0a05d90]
   at 
 org.apache.geronimo.transformer.TransformerCollection.transform(TransformerCollection.java:35)
   at 
 sun.instrument.TransformerManager.transform(TransformerManager.java:122)
   at 
 sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:155)
   at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:82)
   at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
   at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
 Reference Handler daemon prio=10 tid=0x01007910 nid=0x81a200 in 
 Object.wait() [0xb0984000..0xb0984d90]
   at java.lang.Object.wait(Native Method)
   - waiting on 0x05a735f8 (a java.lang.ref.Reference$Lock)
   at java.lang.Object.wait(Object.java:474)
   at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
   - locked 0x05a735f8 (a java.lang.ref.Reference$Lock)
 main prio=5 tid=0x010018b0 nid=0xb0801000 waiting for monitor entry 
 [0xb07ff000..0xb0800188]
   at java.lang.ClassLoader.findBootstrapClass(Native Method)
   at java.lang.ClassLoader.findBootstrapClass0(ClassLoader.java:946)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:308)
   - locked 0x05a75b78 (a sun.misc.Launcher$ExtClassLoader)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
   - locked 0x05a73660 (a sun.misc.Launcher$AppClassLoader)
   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:280)
   - locked 0x05a73660 (a sun.misc.Launcher$AppClassLoader)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
   at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374)
   - locked 0x05a73660 (a sun.misc.Launcher$AppClassLoader)
 VM Thread prio=9 tid=0x01007060 nid=0x809800 runnable
 VM Periodic Task Thread prio=9 tid=0x0100aa00 nid=0x859c00 waiting on 
 condition
 Exception Catcher Thread prio=10 tid=0x01001b00 nid=0x80ae00 runnable
 Found one Java-level deadlock:
 =
 Finalizer:
  waiting to lock monitor 0x0081b070 (object 0x05a73660, a 
 sun.misc.Launcher$AppClassLoader),
  which is held by main
 main:
  waiting to lock monitor 0x0081b094 (object 0x09584b40, a [[I),
  which is held by Finalizer
 Java stack information for the threads listed above:
 ===
 Finalizer:
   at 
 org.apache.geronimo.transformer.TransformerCollection.transform(TransformerCollection.java:35)
   at 
 sun.instrument.TransformerManager.transform(TransformerManager.java:122)
   at 
 sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:155)
   at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:82)
   at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
   at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
 main:
   at java.lang.ClassLoader.findBootstrapClass(Native Method)
   at java.lang.ClassLoader.findBootstrapClass0(ClassLoader.java:946)

[jira] Closed: (GERONIMO-3629) Review GeronimoPropertiesFileMappedPasswordCredentialLoginModule


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vamsavardhana Reddy closed GERONIMO-3629.
-

Resolution: Fixed

 Review GeronimoPropertiesFileMappedPasswordCredentialLoginModule
 

 Key: GERONIMO-3629
 URL: https://issues.apache.org/jira/browse/GERONIMO-3629
 Project: Geronimo
  Issue Type: Task
  Security Level: public(Regular issues) 
  Components: security
Affects Versions: 2.0.x, 2.1
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
 Fix For: 2.0.x, 2.1


 Review GeronimoPropertiesFileMappedPasswordCredentialLoginModule for 
 potential violations and security risks.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-3628) Review GeronimoPasswordCredentialLoginModule


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vamsavardhana Reddy closed GERONIMO-3628.
-

Resolution: Fixed

 Review GeronimoPasswordCredentialLoginModule
 

 Key: GERONIMO-3628
 URL: https://issues.apache.org/jira/browse/GERONIMO-3628
 Project: Geronimo
  Issue Type: Task
  Security Level: public(Regular issues) 
  Components: security
Affects Versions: 2.0.x, 2.1
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
 Fix For: 2.0.x, 2.1


 Review GeronimoPasswordCredentialLoginModule for potential violations and 
 security risks.
  o LoginModule should remove/destroy credentials from subject upon logout.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-3606) GShell-ize client


[ 
https://issues.apache.org/jira/browse/GERONIMO-3606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549551
 ] 

Jarek Gawor commented on GERONIMO-3606:
---

Committed revision 602205.


 GShell-ize client
 -

 Key: GERONIMO-3606
 URL: https://issues.apache.org/jira/browse/GERONIMO-3606
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: application client
Affects Versions: 2.1
Reporter: David Jencks
Assignee: Jarek Gawor
 Fix For: 2.1


 Run the app client from gshell

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (GERONIMO-3606) GShell-ize client


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarek Gawor resolved GERONIMO-3606.
---

Resolution: Fixed

Added start-client GShell command for starting application client. 

I did not add stop-client command as I can't figure if there is a way to get 
the Process object from AntBuilder in order to kill the app client.  So we 
might need a different way of starting the server or client that gives us 
access to the Project object.


 GShell-ize client
 -

 Key: GERONIMO-3606
 URL: https://issues.apache.org/jira/browse/GERONIMO-3606
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: application client
Affects Versions: 2.1
Reporter: David Jencks
Assignee: Jarek Gawor
 Fix For: 2.1


 Run the app client from gshell

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-3687) classloader deadlock during server startup


[ 
https://issues.apache.org/jira/browse/GERONIMO-3687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549534
 ] 

Kevan Miller commented on GERONIMO-3687:


From the stacktrace, the deadlock occurs when we're attempting to load a class 
on line 35 of TransformerCollection:

   for (ClassFileTransformer transformer : transformers)

This enhanced for statement is equivalent to:
   for (Iterator i = transformer.iterator(); i.hasNext(); ) {
  transformer = i.next();
  ...
   }

So, the class being loaded on the Finalizer thread, when the deadlock occurs, 
must be an Iterator class. I think if we force a load of the Iterator class 
during the load of TransformerCollection, we'll be able to avoid this deadlock. 

IMO, the true culprit is the Sun classloader. However, doubt it will be fixed 
anytime soon.

Looks like this fixes my problem. I'll commit shortly. 

 classloader deadlock during server startup
 --

 Key: GERONIMO-3687
 URL: https://issues.apache.org/jira/browse/GERONIMO-3687
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
Affects Versions: 2.0.2, 2.1
Reporter: Kevan Miller
Assignee: Kevan Miller
 Fix For: 2.0.x, 2.1


 I've been seeing regular deadlocks running Geronimo on Leopard.
 It's the same basic scenario as found in GERONIMO-3141. For some reason, the 
 work around in 3141 doesn't work for me on Leopard.
 Just another hack and I'm sure we can fix this...
 Here's background info...
 $ ./geronimo.sh run
 Using GERONIMO_BASE:   /Users/kevan/geronimo-jetty6-jee5-2.0.2
 Using GERONIMO_HOME:   /Users/kevan/geronimo-jetty6-jee5-2.0.2
 Using GERONIMO_TMPDIR: var/temp
 Using JRE_HOME:
 /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home
 You can then send the java process a QUIT signal (kill -3 pid) to have java 
 dump out the thread stack traces. The deadlock occurs during a load of an 
 Iterator class (IIRC). The JVM is not well behaved, IMO. Here's the thread 
 stack traces that I get:
 Full thread dump Java HotSpot(TM) Client VM (1.5.0_13-119 mixed mode):
 Low Memory Detector daemon prio=5 tid=0x01009d60 nid=0x858800 runnable 
 [0x..0x]
 CompilerThread0 daemon prio=9 tid=0x01009330 nid=0x857a00 waiting on 
 condition [0x..0x]
 Signal Dispatcher daemon prio=9 tid=0x01008e60 nid=0x855e00 waiting on 
 condition [0x..0x]
 Finalizer daemon prio=8 tid=0x01007d10 nid=0x81ba00 waiting for monitor 
 entry [0xb0a05000..0xb0a05d90]
   at 
 org.apache.geronimo.transformer.TransformerCollection.transform(TransformerCollection.java:35)
   at 
 sun.instrument.TransformerManager.transform(TransformerManager.java:122)
   at 
 sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:155)
   at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:82)
   at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
   at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
 Reference Handler daemon prio=10 tid=0x01007910 nid=0x81a200 in 
 Object.wait() [0xb0984000..0xb0984d90]
   at java.lang.Object.wait(Native Method)
   - waiting on 0x05a735f8 (a java.lang.ref.Reference$Lock)
   at java.lang.Object.wait(Object.java:474)
   at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
   - locked 0x05a735f8 (a java.lang.ref.Reference$Lock)
 main prio=5 tid=0x010018b0 nid=0xb0801000 waiting for monitor entry 
 [0xb07ff000..0xb0800188]
   at java.lang.ClassLoader.findBootstrapClass(Native Method)
   at java.lang.ClassLoader.findBootstrapClass0(ClassLoader.java:946)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:308)
   - locked 0x05a75b78 (a sun.misc.Launcher$ExtClassLoader)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
   - locked 0x05a73660 (a sun.misc.Launcher$AppClassLoader)
   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:280)
   - locked 0x05a73660 (a sun.misc.Launcher$AppClassLoader)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
   at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374)
   - locked 0x05a73660 (a sun.misc.Launcher$AppClassLoader)
 VM Thread prio=9 tid=0x01007060 nid=0x809800 runnable
 VM Periodic Task Thread prio=9 tid=0x0100aa00 nid=0x859c00 waiting on 
 condition
 Exception Catcher Thread prio=10 tid=0x01001b00 nid=0x80ae00 runnable
 Found one Java-level deadlock:
 =
 Finalizer:
  waiting to lock monitor 0x0081b070 (object 0x05a73660, a 
 sun.misc.Launcher$AppClassLoader),
  which is held by main
 main:
  waiting to lock monitor 0x0081b094 (object 0x09584b40, a [[I),
  which is held by Finalizer
 Java stack information for the threads listed above:

[jira] Commented: (GERONIMO-3686) AsyncHttpClient does not reuse connection even if connections are persistent


[ 
https://issues.apache.org/jira/browse/GERONIMO-3686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549522
 ] 

Sangjin Lee commented on GERONIMO-3686:
---

I am also adding a few more convenience methods on HttpMessage on handling HTTP 
headers as part of this.  They include:

String getHeader(String name);
String[] getHeaders(String name); // returns all of them in case there are 
multiple under the same name which can happen (e.g. Set-Cookie)
void removeHeader(String name);
void setHeader(String name, String value); // overwrites existing instead of 
adding to them



 AsyncHttpClient does not reuse connection even if connections are persistent
 

 Key: GERONIMO-3686
 URL: https://issues.apache.org/jira/browse/GERONIMO-3686
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: AsyncHttpClient
Affects Versions: 1.x
Reporter: Sangjin Lee

 Each time AsyncHttpClient.sendRequest() is called, a new TCP connection is 
 opened, even though connections may be kept alive per HTTP spec.  If 
 connections are kept open, they should be reused for more requests.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-3687) classloader deadlock during server startup

classloader deadlock during server startup
--

 Key: GERONIMO-3687
 URL: https://issues.apache.org/jira/browse/GERONIMO-3687
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
Affects Versions: 2.0.2, 2.1
Reporter: Kevan Miller
Assignee: Kevan Miller
 Fix For: 2.0.x, 2.1


I've been seeing regular deadlocks running Geronimo on Leopard.

It's the same basic scenario as found in GERONIMO-3141. For some reason, the 
work around in 3141 doesn't work for me on Leopard.

Just another hack and I'm sure we can fix this...

Here's background info...

$ ./geronimo.sh run
Using GERONIMO_BASE:   /Users/kevan/geronimo-jetty6-jee5-2.0.2
Using GERONIMO_HOME:   /Users/kevan/geronimo-jetty6-jee5-2.0.2
Using GERONIMO_TMPDIR: var/temp
Using JRE_HOME:
/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home

You can then send the java process a QUIT signal (kill -3 pid) to have java 
dump out the thread stack traces. The deadlock occurs during a load of an 
Iterator class (IIRC). The JVM is not well behaved, IMO. Here's the thread 
stack traces that I get:

Full thread dump Java HotSpot(TM) Client VM (1.5.0_13-119 mixed mode):

Low Memory Detector daemon prio=5 tid=0x01009d60 nid=0x858800 runnable 
[0x..0x]

CompilerThread0 daemon prio=9 tid=0x01009330 nid=0x857a00 waiting on 
condition [0x..0x]

Signal Dispatcher daemon prio=9 tid=0x01008e60 nid=0x855e00 waiting on 
condition [0x..0x]

Finalizer daemon prio=8 tid=0x01007d10 nid=0x81ba00 waiting for monitor entry 
[0xb0a05000..0xb0a05d90]
at 
org.apache.geronimo.transformer.TransformerCollection.transform(TransformerCollection.java:35)
at 
sun.instrument.TransformerManager.transform(TransformerManager.java:122)
at 
sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:155)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:82)
at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)

Reference Handler daemon prio=10 tid=0x01007910 nid=0x81a200 in Object.wait() 
[0xb0984000..0xb0984d90]
at java.lang.Object.wait(Native Method)
- waiting on 0x05a735f8 (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:474)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
- locked 0x05a735f8 (a java.lang.ref.Reference$Lock)

main prio=5 tid=0x010018b0 nid=0xb0801000 waiting for monitor entry 
[0xb07ff000..0xb0800188]
at java.lang.ClassLoader.findBootstrapClass(Native Method)
at java.lang.ClassLoader.findBootstrapClass0(ClassLoader.java:946)
at java.lang.ClassLoader.loadClass(ClassLoader.java:308)
- locked 0x05a75b78 (a sun.misc.Launcher$ExtClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
- locked 0x05a73660 (a sun.misc.Launcher$AppClassLoader)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:280)
- locked 0x05a73660 (a sun.misc.Launcher$AppClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374)
- locked 0x05a73660 (a sun.misc.Launcher$AppClassLoader)

VM Thread prio=9 tid=0x01007060 nid=0x809800 runnable

VM Periodic Task Thread prio=9 tid=0x0100aa00 nid=0x859c00 waiting on 
condition

Exception Catcher Thread prio=10 tid=0x01001b00 nid=0x80ae00 runnable

Found one Java-level deadlock:
=
Finalizer:
 waiting to lock monitor 0x0081b070 (object 0x05a73660, a 
sun.misc.Launcher$AppClassLoader),
 which is held by main
main:
 waiting to lock monitor 0x0081b094 (object 0x09584b40, a [[I),
 which is held by Finalizer

Java stack information for the threads listed above:
===
Finalizer:
at 
org.apache.geronimo.transformer.TransformerCollection.transform(TransformerCollection.java:35)
at 
sun.instrument.TransformerManager.transform(TransformerManager.java:122)
at 
sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:155)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:82)
at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
main:
at java.lang.ClassLoader.findBootstrapClass(Native Method)
at java.lang.ClassLoader.findBootstrapClass0(ClassLoader.java:946)
at java.lang.ClassLoader.loadClass(ClassLoader.java:308)
- locked 0x05a75b78 (a sun.misc.Launcher$ExtClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
- locked 0x05a73660 (a sun.misc.Launcher$AppClassLoader)
at

[jira] Commented: (GERONIMO-3686) AsyncHttpClient does not reuse connection even if connections are persistent


[ 
https://issues.apache.org/jira/browse/GERONIMO-3686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549518
 ] 

Sangjin Lee commented on GERONIMO-3686:
---

Yes, actually in the implementation I've written the session validation occurs 
inside the session cache, and not by the caller.  Agreed on the container 
types, that's what I've been using: ConcurrentHashMap/ConcurrentLinkedQueue.  
One cannot live without them. :)

 AsyncHttpClient does not reuse connection even if connections are persistent
 

 Key: GERONIMO-3686
 URL: https://issues.apache.org/jira/browse/GERONIMO-3686
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: AsyncHttpClient
Affects Versions: 1.x
Reporter: Sangjin Lee

 Each time AsyncHttpClient.sendRequest() is called, a new TCP connection is 
 opened, even though connections may be kept alive per HTTP spec.  If 
 connections are kept open, they should be reused for more requests.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk



On Dec 7, 2007, at 9:11 AM, Anita Kulshreshtha wrote:


2. If yes, then where should we move it to? Should it be in server/
trunk/plugins or should the monitoring plugin be a subproject.


   I was thinking of plugins..


I'm not sure it really matters where the code goes in the interim.   
Plugins makes sense but I would move it to trunk first.  Trunk is  
certainly viable and would likely get more people to look at the code,  
report issues, and most likely ooh and awe about cool looking graphs  
and statistics.


If it turns out that the monitoring bloats the server in an  
unacceptable way, has incorrect statistics or consumes too many  
resources then I would think that moving it to plugins would be a  
reasonable approach.

Re: [DISCUSS] Monitoring Client may need a new graphing engine

2007-12-07 Thread Anita Kulshreshtha


--- Joe Bohn [EMAIL PROTECTED] wrote:

 The mouse-over feature is cool ... but considering all things listed
 as 
 advantages/disadvantages it seems to me that the dojo 0.4.3 comes out
 
 ahead for now.  After timeplot has addressed the IE issue and x/y
 axis 
 labels (with min/max) then it would be much more compelling to
 consider 
 a change.  Just my opinion based upon the very nice summary you
 provided.
   
I agree with Joe, that dojo 0.4.3 is the right candidate for now.
There is nothing obvious about the statistics. The y label with min,
max avg. is a necessity.

Thanks
Anita






  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

[BUILD] 2.1: Failed for Revision: 602335

2007-12-07 Thread prasad

OpenEJB trunk at 602289
Geronimo Revision: 602335 built with tests included
 
See the full build-0200.log file at 
http://people.apache.org/~prasad/binaries/trunk/20071208/build-0200.log
 
61K downloaded
[INFO] 

[INFO] Building Geronimo
[INFO]task-segment: [install]
[INFO] 

[INFO] artifact org.apache.maven.plugins:maven-site-plugin: checking for 
updates from central
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-6/maven-site-plugin-2.0-beta-6.pom
10K downloaded
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugins/10/maven-plugins-10.pom
7K downloaded
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/maven-parent/7/maven-parent-7.pom
20K downloaded
Downloading: http://repo1.maven.org/maven2/org/apache/apache/4/apache-4.pom
4K downloaded
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-6/maven-site-plugin-2.0-beta-6.jar
118K downloaded
[INFO] artifact org.apache.maven.plugins:maven-install-plugin: checking for 
updates from central
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-install-plugin/2.2/maven-install-plugin-2.2.pom
2K downloaded
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugins/8/maven-plugins-8.pom
5K downloaded
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/maven-parent/5/maven-parent-5.pom
14K downloaded
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-install-plugin/2.2/maven-install-plugin-2.2.jar
15K downloaded
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-enforcer-plugin/1.0-alpha-3/maven-enforcer-plugin-1.0-alpha-3.pom
4K downloaded
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-enforcer-plugin/1.0-alpha-3/maven-enforcer-plugin-1.0-alpha-3.jar
31K downloaded
[INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: checking for 
updates from central
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/2.0.2/maven-compiler-plugin-2.0.2.pom
2K downloaded
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/2.0.2/maven-compiler-plugin-2.0.2.jar
17K downloaded
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-idea-plugin/2.0/maven-idea-plugin-2.0.pom
2K downloaded
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugins/1/maven-plugins-1.pom
3K downloaded
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/maven-parent/1/maven-parent-1.pom
6K downloaded
Downloading: http://repo1.maven.org/maven2/org/apache/apache/1/apache-1.pom
3K downloaded
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-idea-plugin/2.0/maven-idea-plugin-2.0.jar
37K downloaded
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-release-plugin/2.0-beta-4/maven-release-plugin-2.0-beta-4.pom
5K downloaded
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-release-plugin/2.0-beta-4/maven-release-plugin-2.0-beta-4.jar
77K downloaded
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugin-plugin/2.3/maven-plugin-plugin-2.3.pom
6K downloaded
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugin-plugin/2.3/maven-plugin-plugin-2.3.jar
21K downloaded
Downloading: 
http://download.java.net/maven/1//org.apache.geronimo.genesis.config/poms/logging-config-1.2.pom
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/genesis/config/logging-config/1.2/logging-config-1.2.pom
Downloading: 
http://repo1.maven.org/maven2/org/apache/geronimo/genesis/config/logging-config/1.2/logging-config-1.2.pom
2K downloaded
Downloading: 
http://download.java.net/maven/1//org.apache.geronimo.genesis.config/jars/logging-config-1.2.jar
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/genesis/config/logging-config/1.2/logging-config-1.2.jar
Downloading: 
http://repo1.maven.org/maven2/org/apache/geronimo/genesis/config/logging-config/1.2/logging-config-1.2.jar
7K downloaded
Downloading: http://download.java.net/maven/1//junit/jars/junit-3.8.1.jar
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//junit/junit/3.8.1/junit-3.8.1.jar
Downloading: http://repo1.maven.org/maven2/junit/junit/3.8.1/junit-3.8.1.jar
118K downloaded
Downloading: 
http://repo1.maven.org/maven2/commons-lang/commons-lang/2.3/commons-lang-2.3.pom
10K downloaded
Downloading: 
http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.pom
1K downloaded
Downloading: 
http://repo1.maven.org/maven2/org/codehaus/plexus/plexus/1.0.11/plexus-1.0.11.pom
8K downloaded

[jira] Created: (GSHELL-94) Update LICENSE and NOTICE info for 1.0-alpha-1 release

Update LICENSE and NOTICE info for 1.0-alpha-1 release
--

 Key: GSHELL-94
 URL: https://issues.apache.org/jira/browse/GSHELL-94
 Project: GShell
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: Documentation
Affects Versions: 1.0-alpha-1
Reporter: Kevan Miller
Assignee: Kevan Miller
 Fix For: 1.0-alpha-1


The LICENSE and NOTICE files for assembly and the root source directory need to 
be updated with actual license and notice information

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-3681) The Monitoring Console should allow the type of graph to be chosen

2007-12-07 Thread Erik B. Craig (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549571
 ] 

Erik B. Craig commented on GERONIMO-3681:
-

Anita,
I'm not sure if this is something that will be able to work into a first 
release (I.E. 2.1), since it's kinda looking like Dojo 1.0.1 is going to be the 
route to go for maximum browser compatibility... as such I will be focusing 
efforts on moving towards that and enabling similar display to what we have 
currently

 The Monitoring Console should allow the type of graph to be chosen
 --

 Key: GERONIMO-3681
 URL: https://issues.apache.org/jira/browse/GERONIMO-3681
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: monitoring
Affects Versions: 2.1
 Environment: All
Reporter: Anita Kulshreshtha

   The CountStatistics can be displayed in 2 ways, the raw count and the 
 throughput/utilization (count/sec). For raw count
 like ErrorCount a bar graph is more appropriate. The curvedArea is good for 
 throughput. The user should be able to choose which 
 graph style (bar, curvedArea, etc) to use.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk

2007-12-07 Thread Erik B. Craig


Kevan Miller wrote:


OK. That's good information. But, IMO, that doesn't necessarily mean 
we shouldn't move the monitoring plugin out of sandbox. It might mean 
that we aren't ready to *release* the monitoring plugin. I don't think 
we're having a *release* discussion -- at least we shouldn't be. We 
can have the discussion that we don't want to hold up a Geronimo 2.1 
release waiting for monitoring plugin problems to be resolved, but I'd 
prefer we discuss without a particular timeline in mind...


IMO, we have the following questions to answer:

1. Are we ready to move monitoring plugin out of sandbox?

Yes, I definitely believe so, although I might be marginally biased =P
2. If yes, then where should we move it to? Should it be in 
server/trunk/plugins or should the monitoring plugin be a subproject.
I was thinking server/trunk/plugins myself... the only other option 
would be just straight plugins... however, correct me if I'm wrong on 
this, but I believe just /plugins is more for things that can be used 
independent of geronimo... which is definitely not the case for the 
monitoring plugin currently.
3. What bug fixes/new features need to be added to the monitoring 
plugin before it's ready to be released?
The single biggest thing on my mind for this currently is the new 
graphing engine that I mentioned, but whether or not it's part of 
server/trunk/plugins has no bearing on this getting done.


Anita,
Your objections seem to be in category 3, but I may be wrong. So, help 
us understand what you're thinking...


--kevan




Thanks,
Erik B. Craig
[EMAIL PROTECTED]

Tomcat webdav issue and Geronimo 2.1

2007-12-07 Thread Joe Bohn



I was just looking into updating Tomcat for the Geronimo 2.1 release 
with an eye toward getting a fix integrated for the Webdav servlet 
security issue.


There are 3 possible approaches:

1) Apply the Webdav patch to the 6.0.13 image with the annotation 
changes and one other minor change (basically our current 6.0.13_G543818 
build plus the WebDav fix).  Check this into our private repository in 
trunk.


2) Checkout 6.0.14, apply the Webdav patch and annotation changes. 
Check this into our private repository in trunk.


3) Checkout tomcat trunk (6.0.x) which already includes the Webdav patch 
but not the annotation changes.  Apply the annotation changes for our 
private build and check it into our repository in trunk.


I personally think #2 is probably best although it might expose some 
other issues in tomcat.  We could always fall back to #1 if necessary. 
There was an attempt made at a tomcat 6.0.15 a few weeks back but it 
failed due to some context and tck issues ... hence my reservations with 
6.0.x since it probably has those same issues.


Does anybody have any concerns with this approach or any better suggestions?

Joe

[jira] Commented: (GERONIMO-3554) monitoring plugin: client should use an ArrayList instead of a Vector

2007-12-07 Thread Erik B. Craig (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549529
 ] 

Erik B. Craig commented on GERONIMO-3554:
-

Patch Committed revision 602191.

Thanks Viet!

 monitoring plugin: client should use an ArrayList instead of a Vector
 -

 Key: GERONIMO-3554
 URL: https://issues.apache.org/jira/browse/GERONIMO-3554
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: monitoring
Affects Versions: 2.1
 Environment: windows
Reporter: Viet Hung Nguyen
Assignee: Viet Hung Nguyen
Priority: Trivial
 Attachments: geronimo-3554.patch


 There are some places in the client code where Vectors are used. ArrayLists 
 would be a better type for this particular instance because of efficiency. 
 Vectors are used for synchronization purposes, which the client does not need 
 to do. ArrayLists would be faster and serve the same purpose in this case.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-3654) Moving o.a.g.s.jaas.NamedUPCredentailLoginModule to o.a.g.s.realm.providers

[
https://issues.apache.org/jira/browse/GERONIMO-3654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549353
]

Vamsavardhana Reddy commented on GERONIMO-3654:
---

On the second thought, I am planning to skip step 2 from the above. I will
mark org.apache.geronimo.jaas.NamedUPCredentialLoginModule as deprecated only.
We can remove the class from the codebase after the next release.

Moving o.a.g.s.jaas.NamedUPCredentailLoginModule to o.a.g.s.realm.providers
---

Key: GERONIMO-3654
URL: https://issues.apache.org/jira/browse/GERONIMO-3654
Project: Geronimo
Issue Type: Task
Security Level: public(Regular issues)
Components: security
Affects Versions: 2.0.x, 2.1
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
Fix For: 2.0.x, 2.1

David Jencks suggested that we move
org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to
org.apache.geronimo.security.realm.providers package. I intend to do the
following.
1. svn copy org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to
org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule
2. Make org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule extend
org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule.
3. Mark org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule as
deprecated.
4. Change all references from
org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to
org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule
Does anyone see this coming in the way of compatibility? I do not intend to
change the option name
org.apache.geronimo.jaas.NamedUPCredentialLoginModule.Name as this will
surely break compatibility. Whether or not the move breaks compatibility,
should we consider this move only in trunk and not in branches\2.0?

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-3682) The Monitoring Console should keep information about Stats available from a managed object

2007-12-07 Thread Erik B. Craig (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-3682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549572
 ] 

Erik B. Craig commented on GERONIMO-3682:
-

I'm not sure that I agree with the idea of having the Description, Xlabel, and 
Ylabel being filled in for the user... I think this is something the user 
should be defining themselves... like the bytes/second for instance.. that's a 
derived value from the bytessent or bytesrecieved counter... and wouldn't 
necessarily be any information that would be retrieved anywhere other than when 
the graphs are defined.

 The Monitoring Console should keep information about Stats available from a 
 managed object
 --

 Key: GERONIMO-3682
 URL: https://issues.apache.org/jira/browse/GERONIMO-3682
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: monitoring
Affects Versions: 2.1
 Environment: All
Reporter: Anita Kulshreshtha

The monitoring console should do a getStats on each of the available 
 StatisticsProvider (without the query being enabled).
 It should use this information to build a DB about the nature of the 
 statistics. This information should be used to fill in the 
 default values in 'add a graph page'. Currently the description, x label, y 
 label show as empty.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: How to get memory statistics from a remote Geronimo runtime?

2007-12-07 Thread Vamsavardhana Reddy

On Dec 7, 2007 9:38 PM, Matt Hogstrom [EMAIL PROTECTED] wrote:


 On Dec 5, 2007, at 4:29 AM, Vamsavardhana Reddy wrote:

 
 
  On Dec 4, 2007 11:23 PM, Anita Kulshreshtha [EMAIL PROTECTED]
  wrote:
It is not clear to me if this is part of the earlier code or a
  separate program. If it is part of the JMX code, then Runtime is from
  the local jvm not remote. The non heap Memory for this program in
  either case is negligible.
You could start G with -Dcom.sun.management.jmxremote. Start
  jconsole and click on the Memory tab to get the whole picture.
  I have started G with the said option and hooked up jconsole.  The
  HeapMemoryUsage is showing exactly what Runtime is returning.
 
  It is only the heap memory exhaustion that results in OOME.  I guess
  I am ok for now as this is what I am interested in.
 

 One will get OOM Exceptions if there is insufficient native memory to
 satisfy a Java request.  For instance, when creating a thread, the OS
 has to allocate some native memory to create the Java Object. If that
 native allocation fails you will get an OOM even though you have
 plenty of heap memory.

You are right.  Any ideas on how to figure if we are exhausting that native
memory?

[jira] Commented: (GERONIMO-3685) Monitoring Console should display TimeStatistics and BoundedRangeStatistics correctly

[
https://issues.apache.org/jira/browse/GERONIMO-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549532
]

Viet Hung Nguyen commented on GERONIMO-3685:

I think by leaving all of the graph generation up to the admin to decide which
numbers (statistics) to graph, along with the ability to perform mathematical
operations (e.g. division) on them, it will give the admin enough freedom to
achieve what you have laid out here. I do not think the way the monitoring
client displays the TimeStatistics and BoundedRangeStatistics is necessarily
wrong, because the monitoring client does not dictate this. It is up to the
admin to create the graphs that he/she wishes to view.

But I may have missed your point. If so, can you please explain it to me again?

Thanks,
Viet

Monitoring Console should display TimeStatistics and BoundedRangeStatistics
correctly
-

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (GERONIMO-3554) monitoring plugin: client should use an ArrayList instead of a Vector


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Viet Hung Nguyen resolved GERONIMO-3554.


   Resolution: Fixed
Fix Version/s: 2.1

 monitoring plugin: client should use an ArrayList instead of a Vector
 -

 Key: GERONIMO-3554
 URL: https://issues.apache.org/jira/browse/GERONIMO-3554
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: monitoring
Affects Versions: 2.1
 Environment: windows
Reporter: Viet Hung Nguyen
Assignee: Viet Hung Nguyen
Priority: Trivial
 Fix For: 2.1

 Attachments: geronimo-3554.patch


 There are some places in the client code where Vectors are used. ArrayLists 
 would be a better type for this particular instance because of efficiency. 
 Vectors are used for synchronization purposes, which the client does not need 
 to do. ArrayLists would be faster and serve the same purpose in this case.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Tomcat webdav issue and Geronimo 2.1

2007-12-07 Thread Kevan Miller



On Dec 7, 2007, at 2:44 PM, Joe Bohn wrote:



I was just looking into updating Tomcat for the Geronimo 2.1 release  
with an eye toward getting a fix integrated for the Webdav servlet  
security issue.


There are 3 possible approaches:

1) Apply the Webdav patch to the 6.0.13 image with the annotation  
changes and one other minor change (basically our current  
6.0.13_G543818 build plus the WebDav fix).  Check this into our  
private repository in trunk.


2) Checkout 6.0.14, apply the Webdav patch and annotation changes.  
Check this into our private repository in trunk.


3) Checkout tomcat trunk (6.0.x) which already includes the Webdav  
patch but not the annotation changes.  Apply the annotation changes  
for our private build and check it into our repository in trunk.


I personally think #2 is probably best although it might expose some  
other issues in tomcat.  We could always fall back to #1 if  
necessary. There was an attempt made at a tomcat 6.0.15 a few weeks  
back but it failed due to some context and tck issues ... hence my  
reservations with 6.0.x since it probably has those same issues.


OK. Good, I think, to upgrade to 6.0.14. So, I like your plan # 2.

--kevan

[jira] Commented: (GERONIMO-3605) GShell-ize deployer commands