date:20080117

+1 for keeping tools.

2008/1/17, Alan D. Cabrera [EMAIL PROTECTED]:
 I was wondering if we prematurely deleted tools.  It would be nice to
 have our own IDL compiler.  I was thinking that we could move tools to
 a dir in the sandbox for someone to pick up.  Thoughts?


 Regards,
 Alan

Re: [YOKO] Yoko web site

2008/1/17, Joseph Leong [EMAIL PROTECTED]:
 Hi there Alan,

 In terms of starting a Wiki, there are several options out there... just to
 name a few popular ones:

 Confluence
 http://www.atlassian.com/software/confluence/

 Media Wiki
 http://www.mediawiki.org/wiki/MediaWiki

 Doku Wiki
 http://wiki.splitbrain.org/wiki:dokuwiki

 PmWiki
 http://www.pmwiki.org/
And Apach JSPWiki :)
http://incubator.apache.org/jspwiki/

Is it possible to run Tomcat for wiki?

SY, Alexey

Re: MailGBean/JNDI problem on Harmony

Nice. But it starts with patched key store as far as I understand... right?

SY, Alexey

https://issues.apache.org/jira/browse/GERONIMO-2015

2008/1/16, Zakharov, Vasily M [EMAIL PROTECTED]:

 Sorry for disturbing, I've just found out the cause for this issue - I
 had one extra property in config.xml. If namingFactoryInitial
 specification is removed, and namingFactoryUrlPkgs specification is
 retained, the problem is resolved, and Geronimo starts fine on Harmony.

 Vasily


 -Original Message-
 From: Zakharov, Vasily M [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, January 16, 2008 8:53 PM
 To: dev@geronimo.apache.org
 Subject: MailGBean/JNDI problem on Harmony

 Hi, all,

 I'm found a problem with MailGBean on Harmony due to of JNDI
 configuration, and I'm asking for help to understand how to deal with
 that problem. The problem would occur on any JDK lacking Sun
 implementation of JNDI RMI Registry provider
 (com.sun.jndi.rmi.registry.RegistryContext). The problem occurs at
 startup and looks as follows:

 java.lang.IllegalArgumentException: Cannot bind to RMI Registry object
 that is neither Remote nor Reference nor Referenceable
 at
 org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.getStateTo
 Bind(RegistryContext.java:618)
 at
 org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.bind(Regis
 tryContext.java:266)
 at
 org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.bind(Regis
 tryContext.java:280)
 at javax.naming.InitialContext.bind(InitialContext.java:411)
 at
 org.apache.geronimo.mail.MailGBean.doStart(MailGBean.java:385)

 The investigation shows the following difference of MailGBean code
 operation on Sun and Harmony:

 On Sun, the InitialContext.getEnvironment() is empty, and
 InitialContext.lookup() returns
 org.apache.geronimo.gjndi.GlobalContextGBean, and
 InitialContext.getNameParser() returns
 org.apache.xbean.naming.context.ContextUtil$SimpleNameParser.

 On Harmony, this works much differently -
 InitialContext.getEnvironment() contains the JNDI properties specified
 in config.xml, and InitialContext.lookup() returns
 org.apache.harmony.jndi.provider.rmi.registry.RegistryContext, and
 InitialContext.getNameParser() returns
 org.apache.harmony.jndi.provider.rmi.registry.AtomicNameParser.
 This causes the error above.

 I had to specify the respective JNDI properties in config.xml for
 JMXConnector to start normally, as follows:

 module name=org.apache.geronimo.configs/rmi-naming/2.0.2/car
 gbean name=NamingProperties
 attribute
 name=namingFactoryInitialorg.apache.harmony.jndi.provider.rmi.registr
 y.RegistryContextFactory/attribute
 attribute
 name=namingFactoryUrlPkgsorg.apache.harmony.jndi.provider/attribute
 attribute name=namingProviderUrlrmi://${ServerHostname}:${NamingPort
 + PortOffset}/attribute
 /gbean

 Probably this is wrong to configure JNDI this way, as it overrides
 Geronimo internal naming mechanisms?

 Maybe org.apache.geronimo.gjndi.GlobalContextGBean needs to be tweaked
 to find the proper JNDI RMI Registry provider by other means than
 standard JNDI properties?

 I'd be happy to hear any ideas, considerations or suggestions on this
 issue.

 Thank you very much!

 Vasily Zakharov
 Intel ESSD



 ---

[BUILD] 2.1: Failed for Revision: 612749

2008-01-17 Thread prasad

OpenEJB trunk at 61
Geronimo Revision: 612749 built with tests included
 
See the full build-0300.log file at 
http://people.apache.org/~prasad/binaries/trunk/20080117/build-0300.log
 
 
See the unit test reports at 
http://people.apache.org/~prasad/binaries/trunk/20080117/unit-test-reports
 
[INFO] snapshot 
org.apache.geronimo.applications:geronimo-uddi-server:2.1-SNAPSHOT: checking 
for updates from apache.snapshots
[INFO] snapshot org.apache.geronimo.applications:geronimo-uddi-db:2.1-SNAPSHOT: 
checking for updates from apache-snapshots
[INFO] snapshot org.apache.geronimo.applications:geronimo-uddi-db:2.1-SNAPSHOT: 
checking for updates from codehaus-snapshots
[INFO] snapshot org.apache.geronimo.applications:geronimo-uddi-db:2.1-SNAPSHOT: 
checking for updates from apache.snapshots
[INFO] Building jar: 
/home/prasad/geronimo/trunk/applications/uddi-server/uddi-jetty6/target/uddi-jetty6-2.1-SNAPSHOT.car
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: uddi-jetty6-2.1-SNAPSHOT.car
[INFO] [install:install]
[INFO] Installing 
/home/prasad/geronimo/trunk/applications/uddi-server/uddi-jetty6/target/uddi-jetty6-2.1-SNAPSHOT.car
 to 
/home/prasad/.m2/repository/org/apache/geronimo/configs/uddi-jetty6/2.1-SNAPSHOT/uddi-jetty6-2.1-SNAPSHOT.car
[INFO] [car:update-pluginlist]
[INFO] 

[INFO] Building Geronimo Configs :: UDDI Tomcat
[INFO]task-segment: [install]
[INFO] 

[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir: 
/home/prasad/geronimo/trunk/applications/uddi-server/uddi-tomcat/target/classes/META-INF
[INFO] Copying 2 files to 
/home/prasad/geronimo/trunk/applications/uddi-server/uddi-tomcat/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated: 
/home/prasad/geronimo/trunk/applications/uddi-server/uddi-tomcat/target/resources/META-INF/plan.xml
[INFO] [car:prepare-metadata]
[INFO] [car:package]
[INFO] Packaging module configuration: 
/home/prasad/geronimo/trunk/applications/uddi-server/uddi-tomcat/target/resources/META-INF/plan.xml
[INFO] Building jar: 
/home/prasad/geronimo/trunk/applications/uddi-server/uddi-tomcat/target/uddi-tomcat-2.1-SNAPSHOT.car
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: uddi-tomcat-2.1-SNAPSHOT.car
[INFO] [install:install]
[INFO] Installing 
/home/prasad/geronimo/trunk/applications/uddi-server/uddi-tomcat/target/uddi-tomcat-2.1-SNAPSHOT.car
 to 
/home/prasad/.m2/repository/org/apache/geronimo/configs/uddi-tomcat/2.1-SNAPSHOT/uddi-tomcat-2.1-SNAPSHOT.car
[INFO] [car:update-pluginlist]
[INFO] 

[INFO] Building Geronimo Plugins :: uddi-server
[INFO]task-segment: [install]
[INFO] 

[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [site:attach-descriptor]
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] [install:install]
[INFO] Installing /home/prasad/geronimo/trunk/applications/uddi-server/pom.xml 
to 
/home/prasad/.m2/repository/org/apache/geronimo/plugins/uddi-server/2.1-SNAPSHOT/uddi-server-2.1-SNAPSHOT.pom
[INFO] 

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

[WARNING] Component returned which is not the same manager. Ignored. [EMAIL 
PROTECTED]
[WARNING] Component returned which is not the same manager. Ignored. [EMAIL 
PROTECTED]
[WARNING] Component returned which is not the same manager. Ignored. [EMAIL 
PROTECTED]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir: 
/home/prasad/geronimo/trunk/applications/welcome/geronimo-welcome/target/classes/META-INF
[INFO] Copying 2 files to 
/home/prasad/geronimo/trunk/applications/welcome/geronimo-welcome/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 1 source file to 
/home/prasad/geronimo/trunk/applications/welcome/geronimo-welcome/target/classes
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

/home/prasad/geronimo/trunk/applications/welcome/geronimo-welcome/src/main/java/org

RE: MailGBean/JNDI problem on Harmony


Yes, sure. I had to replace the keystore, patch the geronimo-security
sources
and make other adjustments. See [1] for the details.

And anyway Geronimo doesn't work very good for now, still many problems
are visible (e .g., the console almost doesn't work) and need to be
investigated and fixed.

Vasily

[1] http://cwiki.apache.org/confluence/display/GMOxDOC20/Apache+Harmony


-Original Message-
From: Alexey Petrenko [mailto:[EMAIL PROTECTED] 
Sent: Thursday, January 17, 2008 11:24 AM
To: dev@geronimo.apache.org
Subject: Re: MailGBean/JNDI problem on Harmony

Nice. But it starts with patched key store as far as I understand...
right?

SY, Alexey

https://issues.apache.org/jira/browse/GERONIMO-2015

2008/1/16, Zakharov, Vasily M [EMAIL PROTECTED]:

 Sorry for disturbing, I've just found out the cause for this issue - I
 had one extra property in config.xml. If namingFactoryInitial
 specification is removed, and namingFactoryUrlPkgs specification is
 retained, the problem is resolved, and Geronimo starts fine on
Harmony.

 Vasily


 -Original Message-
 From: Zakharov, Vasily M [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, January 16, 2008 8:53 PM
 To: dev@geronimo.apache.org
 Subject: MailGBean/JNDI problem on Harmony

 Hi, all,

 I'm found a problem with MailGBean on Harmony due to of JNDI
 configuration, and I'm asking for help to understand how to deal with
 that problem. The problem would occur on any JDK lacking Sun
 implementation of JNDI RMI Registry provider
 (com.sun.jndi.rmi.registry.RegistryContext). The problem occurs at
 startup and looks as follows:

 java.lang.IllegalArgumentException: Cannot bind to RMI Registry object
 that is neither Remote nor Reference nor Referenceable
 at

org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.getStateTo
 Bind(RegistryContext.java:618)
 at

org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.bind(Regis
 tryContext.java:266)
 at

org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.bind(Regis
 tryContext.java:280)
 at javax.naming.InitialContext.bind(InitialContext.java:411)
 at
 org.apache.geronimo.mail.MailGBean.doStart(MailGBean.java:385)

 The investigation shows the following difference of MailGBean code
 operation on Sun and Harmony:

 On Sun, the InitialContext.getEnvironment() is empty, and
 InitialContext.lookup() returns
 org.apache.geronimo.gjndi.GlobalContextGBean, and
 InitialContext.getNameParser() returns
 org.apache.xbean.naming.context.ContextUtil$SimpleNameParser.

 On Harmony, this works much differently -
 InitialContext.getEnvironment() contains the JNDI properties specified
 in config.xml, and InitialContext.lookup() returns
 org.apache.harmony.jndi.provider.rmi.registry.RegistryContext, and
 InitialContext.getNameParser() returns
 org.apache.harmony.jndi.provider.rmi.registry.AtomicNameParser.
 This causes the error above.

 I had to specify the respective JNDI properties in config.xml for
 JMXConnector to start normally, as follows:

 module name=org.apache.geronimo.configs/rmi-naming/2.0.2/car
 gbean name=NamingProperties
 attribute

name=namingFactoryInitialorg.apache.harmony.jndi.provider.rmi.registr
 y.RegistryContextFactory/attribute
 attribute

name=namingFactoryUrlPkgsorg.apache.harmony.jndi.provider/attribute
 attribute
name=namingProviderUrlrmi://${ServerHostname}:${NamingPort
 + PortOffset}/attribute
 /gbean

 Probably this is wrong to configure JNDI this way, as it overrides
 Geronimo internal naming mechanisms?

 Maybe org.apache.geronimo.gjndi.GlobalContextGBean needs to be tweaked
 to find the proper JNDI RMI Registry provider by other means than
 standard JNDI properties?

 I'd be happy to hear any ideas, considerations or suggestions on this
 issue.

 Thank you very much!

 Vasily Zakharov
 Intel ESSD



 ---

[jira] Created: (GERONIMO-3756) Blank screen in Security Realms portlet if wrong file path is specified

2008-01-17 Thread Manu T George (JIRA)

Blank screen in Security Realms portlet if wrong file path is specified
---

 Key: GERONIMO-3756
 URL: https://issues.apache.org/jira/browse/GERONIMO-3756
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: console
Affects Versions: 2.0.2
 Environment: All
Reporter: Manu T George
 Fix For: 2.0.x


When I try to create a property file realm from the security realms portlet and 
I give a wrong file path for the user and group files, I get a blank screen on 
clicking next.

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

Re: progress bar at Geronimo startup

Hi, Jarek.

Just few comments about the patch...
As far as understand each module appears only once in modules array.
And the objects there are the same with coming to moduleLoading,
moduleLoaded, moduleStarting and moduleStarted methods.

If I'm correct here then I suggest to change the following statements
a little...
=== original ===
for (int i = 0; i  modules.length; i++) {
if (modules[i].equals(module)) {
moduleStatus[i] = STATUS_LOADED;
}
}
=== original ===

=== suggested ===
for (int i = 0; i  modules.length; i++) {
if (modules[i] == module) {
moduleStatus[i] = STATUS_LOADED;
break;
}
}
=== suggested ===

Not very significant change but will boost startup performance a
little (probably very little :) for big list of modules.

SY, Alexey

2008/1/16, Jarek Gawor [EMAIL PROTECTED]:
 Folks,

 A few times before I've ran into some problems with the progress bar
 displayed at Geronimo startup as I had a lot of modules installed. I
 described the problem in
 https://issues.apache.org/jira/browse/GERONIMO-3725.  I also just
 attached to the bug report a patch with a new and simpler progress bar
 hat does not suffer from the same problem as the existing bar but at
 the same time it does not it display the same detail info as the
 existing bar. I tired to explain this difference in the bug report.

 So, any thoughts/objections on replacing the existing progress bar
 with the one I attached to the bug report?

 Thanks,
 Jarek

[jira] Commented: (GERONIMO-3756) Blank screen in Security Realms portlet if wrong file path is specified

2008-01-17 Thread Vamsavardhana Reddy (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-3756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559879#action_12559879
 ] 

Vamsavardhana Reddy commented on GERONIMO-3756:
---

The problem occurs when there is a '\' in the string value used with 
ActionResponse.setRenderParameter().  In this case, the error message has a '\' 
in the filename on Windows.  Does any one know if there are any guidelines on 
passing parameters containing special characters between portlet pages?

 Blank screen in Security Realms portlet if wrong file path is specified
 ---

 Key: GERONIMO-3756
 URL: https://issues.apache.org/jira/browse/GERONIMO-3756
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: console
Affects Versions: 2.0.2
 Environment: All
Reporter: Manu T George
 Fix For: 2.0.x


 When I try to create a property file realm from the security realms portlet 
 and I give a wrong file path for the user and group files, I get a blank 
 screen on clicking next.

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

[jira] Commented: (GERONIMO-1775) Internationalization of the Admin Console

2008-01-17 Thread YunFeng Ma (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559893#action_12559893
 ] 

YunFeng Ma commented on GERONIMO-1775:
--

Thanks for pointing me this, Anita. I'll have a look at JSR 168.

 Internationalization of the Admin Console
 -

 Key: GERONIMO-1775
 URL: https://issues.apache.org/jira/browse/GERONIMO-1775
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: console
Reporter: Yeray Cabrera Santana
Assignee: Donald Woods
Priority: Minor
 Fix For: 2.1

 Attachments: chinese_console.JPG, GERONIMO-1775-1.patch, 
 GERONIMO-1775-2.patch, GERONIMO-1775.patch, screen1.GIF


 Provide the internationalization of the administration console so it can be 
 translated to different languages. This is a feature I would like to 
 contribute with.

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

[jira] Commented: (GERONIMO-3746) Plugin Progress Bar Not Updating

2008-01-17 Thread Joseph Leong (JIRA)

[
https://issues.apache.org/jira/browse/GERONIMO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559883#action_12559883
]

Joseph Leong commented on GERONIMO-3746:

Update: So it may appear that part of the UI process is interfering with
properly allowing the installation of a second plugin or following plugins.
The first plugin attempt installs.. (although not properly updating the UI with
the progress bar). In that process something causes
request.isRequestedSessionIdValid() or request.isRequestedSessionIdFromCookie()
to invalidate. The side of effect of this is [BATCH] in the DWR files stopping
the installation of any plugins in that 'session' because it believes its a
CSRF attack.

Current direction i'm heading, resolving why the sessions are getting
invalidated or consolidate our ajax implementations and move from DWR to DOJO.
Still need to research a bit on DOJO and DWR to make sure this effort is
possible.

Thoughts?

Thanks,
Joseph Leong

Plugin Progress Bar Not Updating

Key: GERONIMO-3746
URL: https://issues.apache.org/jira/browse/GERONIMO-3746
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: console
Affects Versions: 2.1
Reporter: Joseph Leong
Assignee: Joseph Leong

When installing any plugin from the repository, the progress bar fails to
update correctly.

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

[jira] Issue Comment Edited: (GERONIMO-3746) Plugin Progress Bar Not Updating

2008-01-17 Thread Joseph Leong (JIRA)

[
https://issues.apache.org/jira/browse/GERONIMO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559883#action_12559883
]

jleong edited comment on GERONIMO-3746 at 1/17/08 2:08 AM:
-

Update: So it may appear that part of the UI process is interfering with
properly allowing the installation of a second plugin or following plugins
(from the console side). The first plugin attempt installs.. (although not
properly updating the UI with the progress bar). In that process something
causes request.isRequestedSessionIdValid() or
request.isRequestedSessionIdFromCookie() to invalidate. The side of effect of
this is [BATCH] in the DWR files stopping the installation of any plugins in
that 'session' because it believes its a CSRF attack.

Thoughts?

Thanks,
Joseph Leong

was (Author: jleong):
Update: So it may appear that part of the UI process is interfering with
properly allowing the installation of a second plugin or following plugins.
The first plugin attempt installs.. (although not properly updating the UI with
the progress bar). In that process something causes
request.isRequestedSessionIdValid() or request.isRequestedSessionIdFromCookie()
to invalidate. The side of effect of this is [BATCH] in the DWR files stopping
the installation of any plugins in that 'session' because it believes its a
CSRF attack.

Thoughts?

Thanks,
Joseph Leong

Plugin Progress Bar Not Updating

When installing any plugin from the repository, the progress bar fails to
update correctly.

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

Re: [VOTE] Release XBean 3.3

2008-01-17 Thread James Strachan

+1

On 17/01/2008, Dain Sundstrom [EMAIL PROTECTED] wrote:
 +1

 -dain

 On Jan 16, 2008, at 7:27 PM, Kevan Miller wrote:

 
  On Jan 15, 2008, at 2:28 AM, Alan D. Cabrera wrote:
 
  Fixed:
 
  Binaries:
 
  http://people.apache.org/~adc/stage-xbean/org/apache/xbean/
 
  SVN Tag:
 
  http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.3/
 
  +1
 
  --kevan




-- 
James
---
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com

[jira] Assigned: (GERONIMO-2015) Let's replace JKS to PKCS12 key store type

2008-01-17 Thread Alexey Petrenko (JIRA)


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

Alexey Petrenko reassigned GERONIMO-2015:
-

Assignee: Alexey Petrenko

 Let's replace JKS to PKCS12 key store type
 --

 Key: GERONIMO-2015
 URL: https://issues.apache.org/jira/browse/GERONIMO-2015
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: security
Reporter: Nikolay Chugunov
Assignee: Alexey Petrenko
 Fix For: Wish List

 Attachments: jksToPKCS12-1.1.1.patch, JKSToPKCS12.java, 
 jksToPKCS12.patch, keystore


 Hello
 Let's replace JKS to PKCS12 key store type; because PKCS12 is widely used key 
 store and Geronimo may not work on non-Sun VMs.
 To fix this problem I have created the patch for Geronimo sources.
 In brief the patch (attached) replaces JKS to PKCS12 key store type in 
 configurations files. 
 PKCS12 format of key store file is not java-specific and can be created and 
 read by other programs, e.g. Internet Explorer. In addition PKCS12 exists in 
 Bouncy Castle (http://www.bouncycastle.org) security provider, while JKS is 
 Sun specific key store and does not exist in Bouncy Castle.
 Also it is needed to replace JKS to PKCS12 keystore file (attached) to 
 assemblies/j2ee-tomcat-server/src/var/security, 
 assemblies/j2ee-installer/src/var/security, 
 assemblies/j2ee-jetty-server/src/var/security directories. Key store file was 
 generating using JKSToPKCS12 class (attached). This class transfers key and 
 certificate of Geronimo from JKS to PKCS12.
 After I apply this patch to Geronimo 1.0 sources and build Geronimo I can 
 login to Geronimo console over https.

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

Re: [AsyncHttpClient] data collection instrumentation

2008-01-17 Thread Rick McGuire

Thunderbird is playing very strange games with me this morning, somehow 
deleting the original post.   Anyway, here are my comments on this.


I'd like to propose changes to enable some basic stat collection 
and/or instrumentation to have visibility into performance of AHC. 
 For a given *AsyncHttpClient*, one might want to know metrics like


- total request count
- total success count
- total exception count
- total timeout count
- connection attempt count
- connection failure count
- connect time average
- connection close count
- average response time (as measured from the invocation time to 
having the response ready)

- and others?
Collection of metric information would, I think, be a good thing.  
However, I think we should separate the consolidation of the information 
from the collection.  That is, the client should just have different 
types of events for data collection, and the event listener would be 
responsible for presenting the information appropriately. 

For example, to create the list above, I'd see the following set of 
events needed:


- request made
- request completed
- request failed
- request timeout
- connection attempt started
- connection failed
- connection closed

All events would be timestamped, which would allow metrics like average 
request time to be calculated.  This set of events would mean the 
client would not need to maintain any metric accumulators, and if the 
event information is done correctly, would even allow more fine grained 
monitoring (e.g., average connection time for requests to domain 
foo.bar.com).





Collecting these metrics should have little effect on the overall 
performance.  There would be an API to access these stats.


I was initially thinking of an IoFilter to consolidate these hooks, 
but I realize some of these metrics are not readily available to an 
IoFilter (e.g. connect-related numbers).  It might be unavoidable to 
spread the instrumentation in a couple of places (IoHandler, 
ConnectFutureListener, etc.).


Taking this one step further, one might think of callbacks or 
listeners for various key events such as connect complete, request 
sent, etc., so callers can provide instrumenting/logging code via 
event notification.  However, I think this should be used judiciously 
as such injected code may cause havoc.
I think listeners would be the way to go.  This would allow multiple 
monitoring types to be attached to the pipe to gather data as needed.  
Perhaps the approached used with the javamail API might be of use here.  
The javamail Store APIs have a number of listener events that are 
broadcast (new mail arrived, message delete, folder created, etc.).  
Because there are similar concerns of havoc, the events get posted to a 
queue, and are dispatched on to a separate thread.  The queue is only 
created (and the associated thread) are only created when there are 
listeners available to handle the events.  This allows the events to 
very low overhead when there are no interested parties and prevents the 
listeners from interfering with normal javamail operations by being 
processed on a different thread.





Thoughts?  Suggestions?

[jira] Commented: (GERONIMO-3755) application-1.2 schema does not exist

2008-01-17 Thread Anita Kulshreshtha (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559972#action_12559972
 ] 

Anita Kulshreshtha commented on GERONIMO-3755:
--

The schemas for geronimo 2.0+ are described here:
http://geronimo.apache.org/apache-geronimo-v20-xml-schemas.html
i.e. you need http://geronimo.apache.org/xml/ns/j2ee/application-2.0. 
   Please feel free to update the information in the samples :)

 application-1.2 schema does not exist
 -

 Key: GERONIMO-3755
 URL: https://issues.apache.org/jira/browse/GERONIMO-3755
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
Affects Versions: 2.0.2
 Environment: Mac OS X Tiger, Java 1.5 
Reporter: Aurimas Valionis
Priority: Blocker

 I want to create a plan for ear application and I follow the samples, there 
 should be application-1.2 schema available on 
 http://geronimo.apache.org/xml/ns/j2ee/application-1.2; but it is not there. 
 Would you upload the schema?

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

Re: [ANNOUNCE] Kevan Miller has been approved as the new PMC Chair for Apache Geronimo

2008-01-17 Thread Anita Kulshreshtha

Matt, thanks for the great work you've done as the PMC Chair. I have
enjoyed working on Geronimo under your leadership and always felt
welcome as an integral part of the team. I wish you the very best in
your new endeavors. 

Kevan, Congratulations on your new role! 

Anita

--- Matt Hogstrom [EMAIL PROTECTED] wrote:

 Recently I have had several things change personally and I have found
  
 it increasingly difficult to keep up with the Geronimo mailing lists 
 
 on a daily basis.  As a result, I did some soul searching and decided
  
 that my intentions to stay on top of Geronimo were good but my follow
  
 through wasn't   This was specifically in regard to being able to  
 respond to people on issues that I needed to do as PMC chair.
 
 I tendered my resignation to the Board earlier this week.  There was 
 
 some discussion on the PMC list about a replacement and the PMC  
 unanimously approved Kevan Miller as my successor.  The board just  
 approved this request so Kevan now has the mantle for Geronimo as the
  
 PMC chair.
 
 It is with great pleasure that I announce that Kevan has accepted
 this  
 responsibility of PMC chair.  The beauty is that Kevan has already  
 been doing most of the work of the PMC chair anyway and is the right 
 
 person going forward.  Please give it up for Kevan Miller, VP, Apache
  
 Geronimo!
 
 I'm still noodling with some performance work as time allows so I'm  
 not gone.  I'll prolly continue to nag in my own unique way.
 
 Matt
 



  

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

Re: [YOKO] Yoko web site

2008-01-17 Thread Hernan Cunico


This might help a little bit for the big picture .

http://cwiki.apache.org/CWIKI/

Cheers!
Hernan

Jason Dillon wrote:
They use confluence and auto-export. 


--jason


-Original Message-
From: Alan D. Cabrera [EMAIL PROTECTED]

Date: Wed, 16 Jan 2008 21:39:43 
To:dev@geronimo.apache.org

Subject: Re: [YOKO] Yoko web site


:)


What does XBean and GShell do?


Regards,
Alan

On Jan 16, 2008, at 5:18 PM, Jason Dillon wrote:

Well there is this thing called HTML and you use it to make things  
called pages and then put them on a web server...


:-P

What do you want... Something backed up by confluence?  Or static  
via svn?


--jason


-Original Message-
From: Alan D. Cabrera [EMAIL PROTECTED]

Date: Wed, 16 Jan 2008 16:41:30
To:Developers Geronimo dev@geronimo.apache.org
Subject: [YOKO] Yoko web site


I want to start creating the new Yoko website and wiki.  How do I do
this?


Regards,
Alan

Re: [YOKO] Yoko web site

2008-01-17 Thread Jason Dillon

Did you get this sorted... or on your way to sorted?  Ping me if you  
need any help... especially if its the kinda help where I don't really  
have to do anything :-P


--jason


On Jan 16, 2008, at 4:41 PM, Alan D. Cabrera wrote:

I want to start creating the new Yoko website and wiki.  How do I do  
this?



Regards,
Alan

[jira] Commented: (GSHELL-98) NotFoundException when trying to use non-builtin commands in full assembly


[ 
https://issues.apache.org/jira/browse/GSHELL-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560011#action_12560011
 ] 

Jason Dillon commented on GSHELL-98:


I'm about to apply this, though I don't really understand how it was broken 
before... not that I think it was not broken before.

Can you give me an example of a command execution which fails w/o the patch and 
runs as expected with the patch?

 NotFoundException when trying to use non-builtin commands in full assembly
 --

 Key: GSHELL-98
 URL: https://issues.apache.org/jira/browse/GSHELL-98
 Project: GShell
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: Core
Affects Versions: 1.0-alpha-2
Reporter: Jason Warner
Assignee: Jason Dillon
 Fix For: 1.0-alpha-2

 Attachments: GShell-98.patch


 The full assembly of gshell includes all the available commands by default.  
 When trying to use one of the commands included outside of builtins, a 
 NotFoundException is received.  This seems to be caused by the groupings in 
 the layout.xml file.  When the groupings were removed, all the commands could 
 be used successfully.  Ideally, we'd like to be able to keep the groupings, 
 though.

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

Re: [AsyncHttpClient] data collection instrumentation

2008-01-17 Thread Sangjin Lee

I like your idea of using the event listener as the main way of doing this.
 Basically no or multiple listeners would be invoked on a different thread
when events occur.
The event listener APIs would define those key methods which would contain
all the necessary information about the events in an immutable fashion.

We could provide a simple adapter that is no op so people can override
necessary methods easily.  Also, we could provide one implementation which
is a counting listener that does the basic metrics collection.

What do you think?

Thanks,
Sangjin

On Jan 17, 2008 2:58 AM, Rick McGuire [EMAIL PROTECTED] wrote:

 Thunderbird is playing very strange games with me this morning, somehow
 deleting the original post.   Anyway, here are my comments on this.

  I'd like to propose changes to enable some basic stat collection
  and/or instrumentation to have visibility into performance of AHC.
   For a given *AsyncHttpClient*, one might want to know metrics like
 
  - total request count
  - total success count
  - total exception count
  - total timeout count
  - connection attempt count
  - connection failure count
  - connect time average
  - connection close count
  - average response time (as measured from the invocation time to
  having the response ready)
  - and others?
 Collection of metric information would, I think, be a good thing.
 However, I think we should separate the consolidation of the information
 from the collection.  That is, the client should just have different
 types of events for data collection, and the event listener would be
 responsible for presenting the information appropriately.

 For example, to create the list above, I'd see the following set of
 events needed:

 - request made
 - request completed
 - request failed
 - request timeout
 - connection attempt started
 - connection failed
 - connection closed

 All events would be timestamped, which would allow metrics like average
 request time to be calculated.  This set of events would mean the
 client would not need to maintain any metric accumulators, and if the
 event information is done correctly, would even allow more fine grained
 monitoring (e.g., average connection time for requests to domain
 foo.bar.com).


 
  Collecting these metrics should have little effect on the overall
  performance.  There would be an API to access these stats.
 
  I was initially thinking of an IoFilter to consolidate these hooks,
  but I realize some of these metrics are not readily available to an
  IoFilter (e.g. connect-related numbers).  It might be unavoidable to
  spread the instrumentation in a couple of places (IoHandler,
  ConnectFutureListener, etc.).
 
  Taking this one step further, one might think of callbacks or
  listeners for various key events such as connect complete, request
  sent, etc., so callers can provide instrumenting/logging code via
  event notification.  However, I think this should be used judiciously
  as such injected code may cause havoc.
 I think listeners would be the way to go.  This would allow multiple
 monitoring types to be attached to the pipe to gather data as needed.
 Perhaps the approached used with the javamail API might be of use here.
 The javamail Store APIs have a number of listener events that are
 broadcast (new mail arrived, message delete, folder created, etc.).
 Because there are similar concerns of havoc, the events get posted to a
 queue, and are dispatched on to a separate thread.  The queue is only
 created (and the associated thread) are only created when there are
 listeners available to handle the events.  This allows the events to
 very low overhead when there are no interested parties and prevents the
 listeners from interfering with normal javamail operations by being
 processed on a different thread.


 
  Thoughts?  Suggestions?

[jira] Assigned: (GSHELL-48) Add file/URL support to the script command


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

Jason Dillon reassigned GSHELL-48:
--

Assignee: Jason Dillon  (was: Jason Warner)

 Add file/URL support to the script command
 --

 Key: GSHELL-48
 URL: https://issues.apache.org/jira/browse/GSHELL-48
 Project: GShell
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: Commands - BSF
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
Assignee: Jason Dillon
Priority: Minor
 Fix For: 1.0-alpha-2

 Attachments: GShell-48.patch


 Should be able to give the BSF {{script}} command a file or URL to execute.

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

[jira] Assigned: (GSHELL-70) Boolean options should be able to take an optional argument to negate, ie. --foo=false


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

Jason Dillon reassigned GSHELL-70:
--

Assignee: Jason Dillon  (was: Jason Warner)

 Boolean options should be able to take an optional argument to negate, ie. 
 --foo=false
 --

 Key: GSHELL-70
 URL: https://issues.apache.org/jira/browse/GSHELL-70
 Project: GShell
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: Support - CLP
Reporter: Jason Dillon
Assignee: Jason Dillon
 Fix For: 1.0-alpha-2

 Attachments: GShell-70.patch


 Boolean options, like:
 {code:java}
 @Option(name=-f, aliases={--foo})
 private boolean foo;
 {code}
 Should support negation with:
 {noformat}
 --foo=false
 {noformat}
 or:
 {noformat}
 -f=false
 {noformat}

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

[jira] Updated: (GSHELL-76) Full and minimal assemblies require different layout.xml


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

Jason Dillon updated GSHELL-76:
---

Fix Version/s: (was: 1.0-alpha-1)
   1.0-alpha-2

 Full and minimal assemblies require different layout.xml
 

 Key: GSHELL-76
 URL: https://issues.apache.org/jira/browse/GSHELL-76
 Project: GShell
  Issue Type: Sub-task
  Security Level: public(Regular issues) 
  Components: Build
Reporter: Jason Dillon
Assignee: Jason Dillon
 Fix For: 1.0-alpha-2




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

[jira] Updated: (GSHELL-73) {redirec} does not work with exported content


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

Jason Dillon updated GSHELL-73:
---

Fix Version/s: (was: 1.0-alpha-1)
   1.0-alpha-2

 {redirec} does not work with exported content
 -

 Key: GSHELL-73
 URL: https://issues.apache.org/jira/browse/GSHELL-73
 Project: GShell
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: Website
Reporter: Jason Dillon
Assignee: Jason Dillon
 Fix For: 1.0-alpha-2


 Pages like this have redirects:
   * http://cwiki.apache.org/GSHELL/issue-tracking.html
 But they don't work on the exported pages,

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

[jira] Closed: (GSHELL-48) Add file/URL support to the script command


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

Jason Dillon closed GSHELL-48.
--

Resolution: Fixed

Applied thx

 Add file/URL support to the script command
 --

 Key: GSHELL-48
 URL: https://issues.apache.org/jira/browse/GSHELL-48
 Project: GShell
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: Commands - BSF
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
Assignee: Jason Dillon
Priority: Minor
 Fix For: 1.0-alpha-2

 Attachments: GShell-48.patch


 Should be able to give the BSF {{script}} command a file or URL to execute.

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

[jira] Assigned: (GSHELL-49) When --language is not given and we have a file/URL try and figure out the lang to use


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

Jason Dillon reassigned GSHELL-49:
--

Assignee: Jason Dillon  (was: Jason Warner)

 When --language is not given and we have a file/URL try and figure out the 
 lang to use
 --

 Key: GSHELL-49
 URL: https://issues.apache.org/jira/browse/GSHELL-49
 Project: GShell
  Issue Type: Sub-task
  Security Level: public(Regular issues) 
  Components: Commands - BSF
Reporter: Jason Dillon
Assignee: Jason Dillon
Priority: Trivial
 Fix For: 1.0-alpha-2




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

[jira] Closed: (GSHELL-49) When --language is not given and we have a file/URL try and figure out the lang to use


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

Jason Dillon closed GSHELL-49.
--

Resolution: Fixed

Applied thx

 When --language is not given and we have a file/URL try and figure out the 
 lang to use
 --

 Key: GSHELL-49
 URL: https://issues.apache.org/jira/browse/GSHELL-49
 Project: GShell
  Issue Type: Sub-task
  Security Level: public(Regular issues) 
  Components: Commands - BSF
Reporter: Jason Dillon
Assignee: Jason Dillon
Priority: Trivial
 Fix For: 1.0-alpha-2




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

[jira] Closed: (GSHELL-70) Boolean options should be able to take an optional argument to negate, ie. --foo=false


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

Jason Dillon closed GSHELL-70.
--

Resolution: Fixed

Applied, thx.  In the future can we get tests for new features to make sure 
things keep working.

 Boolean options should be able to take an optional argument to negate, ie. 
 --foo=false
 --

 Key: GSHELL-70
 URL: https://issues.apache.org/jira/browse/GSHELL-70
 Project: GShell
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: Support - CLP
Reporter: Jason Dillon
Assignee: Jason Dillon
 Fix For: 1.0-alpha-2

 Attachments: GShell-70.patch


 Boolean options, like:
 {code:java}
 @Option(name=-f, aliases={--foo})
 private boolean foo;
 {code}
 Should support negation with:
 {noformat}
 --foo=false
 {noformat}
 or:
 {noformat}
 -f=false
 {noformat}

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

Re: 2.1 Release -- Banging the drum

2008-01-17 Thread Jason Dillon

I think we need to fix the pom parentage post reorganization before we  
can branch for a 2.1 release.  IMO the reorg is only half done... and  
really needs to be finished.


--jason


On Jan 16, 2008, at 7:27 AM, Kevan Miller wrote:


All,
This note is a bit overdue (it's been a distracting start to the New  
Year for me). Time, IMO, for us to get focused on our 2.1 release.


As David Jencks has pointed out. We need to start cleaning out the  
2.1 Jiras. It looks like I've got several open that have been fixed,  
either by additional development activities or redundant jira's.  
First step is to take a look at Jira's that you've created and make  
sure they are still valid and if you think it's important that they  
be fixed for 2.1.


We also need to be taking a close look at our current functionality.  
Make sure things are working the way we want them to... Especially  
need to cast a critical eye on our the usability aspects of the new  
2.1. Along the way, will be great if we can start pulling docs  
together.


I started running tests last night. Right away, I'm noticing little  
things like warning messages being sent to STDOUT, etc. I'll start  
registering problem areas that I'm seeing.


I'd like to set a target of 2 weeks for reviewing and fixing  
problems. After that would start the branching, final tck, and  
packaging work. If we feel this might negatively impact post-2.1  
development activities. We can consider creating a 2.1 branch  
sooner...


Thoughts?

--kevan

Re: [YOKO] premature tools deletion?

2008-01-17 Thread Matt Hogstrom


Keep 'em around, we can always whack them later.

On Jan 17, 2008, at 1:51 AM, Alan D. Cabrera wrote:

I was wondering if we prematurely deleted tools.  It would be nice  
to have our own IDL compiler.  I was thinking that we could move  
tools to a dir in the sandbox for someone to pick up.  Thoughts?



Regards,
Alan

[jira] Created: (GERONIMO-3757) KeyStore type can't be changed

2008-01-17 Thread Vasily Zakharov (JIRA)

KeyStore type can't be changed
--

 Key: GERONIMO-3757
 URL: https://issues.apache.org/jira/browse/GERONIMO-3757
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: security
Affects Versions: 2.0.2, 2.0.x, 2.1
Reporter: Vasily Zakharov


For now (r612905), Geronimo is hardcoded to use JKS keystore type, which 
prevents Geronimo from running on Harmony or other JDKs that have no JKS 
implementation:

org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635:
KeyStore tempKeystore = KeyStore.getInstance(JKS);

org.apache.geronimo.security.keystore.FileKeystoreManager, line 364:
KeyStore keystore = KeyStore.getInstance(FileKeystoreInstance.JKS);

To workaround this issue, one can change JKS to KeyStore.getDefaultType() (this 
returns BKS for Harmony) or particular other keystore type, but this requires 
source recompilation. Replacing var/security/keystores/geronimo-default with 
the proper keystore type file is not a problem.

A proper solution seems to apply the fix above to use the JDK-default keystore 
type, and provide FileKeystoreInstance with an additional configuration option, 
keystoreType, that would allow to change the keystore type through config.xml 
without recompilation, like this:

module name=org.apache.geronimo.configs/server-security-config/2.0.2/car
  gbean name=geronimo-default
attribute name=keystoreTypePKCS12/attribute
attribute 
name=keystorePathvar/security/keystores/geronimo-pkcs12/attribute
  /gbean
/module

This issue if a follow up to GERONIMO-2015.


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

RE: How to change KeyStore type?


Yes, sure, I fully agree.

I've filed GERONIMO-3757 for this issue and now thinking of the patch to
the trunk that would provide the necessary customization - unless any
objections arise.

As of GERONIMO-2015, I think we may close it, as there're objective
reasons (stated there by Vamsavardhana Reddy) to not move from JKS on
Sun.

Vasily


-Original Message-
From: Alexey Petrenko [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, January 16, 2008 1:37 PM
To: dev@geronimo.apache.org
Subject: Re: How to change KeyStore type?

I think we should add PKCS12 to Geronimo.
If we afraid of possible incompatibilities and not full support of JKS
or PKCS12 why not to let user choose what keystore to use?
We can specify keystore in configs or choose type from available on
current VM.

SY, Alexey

2008/1/15, Zakharov, Vasily M [EMAIL PROTECTED]:
 Hi, all,

 Is there a way to change the geronimo-default keystore
 from JKS to, say, PKCS12 without patching the
 org.apache.geronimo.security.keystore.FileKeystore* classes?

 That way of patching sources is suggested at GERONIMO-2015,
 and it works, but it's probably not the best idea.

 I see the reasons of not making PKCS12 a default keystore type,
 but what about making it possible to change keystore type
 using config.xml, without source recompilation?

 I've browsed through the configuration options of geronimo-security
 gbean, a found no way for that. Should I provide a patch for
 that to be possible, would that be appropriate?

 Thank you!

 Vasily Zakharov
 Intel ESSD



 ---

[jira] Commented: (GERONIMO-2015) Let's replace JKS to PKCS12 key store type

2008-01-17 Thread Vasily Zakharov (JIRA)

[
https://issues.apache.org/jira/browse/GERONIMO-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560060#action_12560060
]

Vasily Zakharov commented on GERONIMO-2015:
---

As it seems unpractical to change default keystore type from JKS to something
else, I think this issue may be resolved (as Won't Fix or Invalid), and closed.

The question of having a chance to customize the keystore type in configuration
file is in fact a separate issue, so I filed GERONIMO-3757 for that.

Let's replace JKS to PKCS12 key store type
--

Key: GERONIMO-2015
URL: https://issues.apache.org/jira/browse/GERONIMO-2015
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: security
Reporter: Nikolay Chugunov
Assignee: Alexey Petrenko
Fix For: Wish List

Attachments: jksToPKCS12-1.1.1.patch, JKSToPKCS12.java,
jksToPKCS12.patch, keystore

Hello
Let's replace JKS to PKCS12 key store type; because PKCS12 is widely used key
store and Geronimo may not work on non-Sun VMs.
To fix this problem I have created the patch for Geronimo sources.
In brief the patch (attached) replaces JKS to PKCS12 key store type in
configurations files.
PKCS12 format of key store file is not java-specific and can be created and
read by other programs, e.g. Internet Explorer. In addition PKCS12 exists in
Bouncy Castle (http://www.bouncycastle.org) security provider, while JKS is
Sun specific key store and does not exist in Bouncy Castle.
Also it is needed to replace JKS to PKCS12 keystore file (attached) to
assemblies/j2ee-tomcat-server/src/var/security,
assemblies/j2ee-installer/src/var/security,
assemblies/j2ee-jetty-server/src/var/security directories. Key store file was
generating using JKSToPKCS12 class (attached). This class transfers key and
certificate of Geronimo from JKS to PKCS12.
After I apply this patch to Geronimo 1.0 sources and build Geronimo I can
login to Geronimo console over https.

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

[jira] Commented: (GERONIMO-3451) Restricted listeners property file not found error logged during Tomcat server startup

2008-01-17 Thread David Jencks (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560079#action_12560079
 ] 

David Jencks commented on GERONIMO-3451:


I opened http://issues.apache.org/bugzilla/show_bug.cgi?id=44261 with a fix for 
tomcat trunk.

 Restricted listeners property file not found error logged during Tomcat 
 server startup
 

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


 During Tomcat server startup, the following log error is displayed on the 
 console:
 12:57:32,559 ERROR [[/]] Restricted listeners property file not found
 Althgough the log message can be ignored, users assume that something is 
 broken...

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

Re: [ANNOUNCE] Kevan Miller has been approved as the new PMC Chair for Apache Geronimo

2008-01-17 Thread Jacek Laskowski

On Jan 16, 2008 9:10 PM, Matt Hogstrom [EMAIL PROTECTED] wrote:

 I tendered my resignation to the Board earlier this week.  There was
 some discussion on the PMC list about a replacement and the PMC
 unanimously approved Kevan Miller as my successor.  The board just
 approved this request so Kevan now has the mantle for Geronimo as the
 PMC chair.

Great people step down and other great people step up - nothing's
really changed ;-) Seriously, it's been a pleasure to work with you
Matt as a PMC chair.

Now, since Matt left out, let's welcome our new PMC chair - Viva Kevan!

Jacek

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

Geronimo 2.0.2 starts on Harmony!

Hi, all,

Well, finally I can say Geronimo 2.0.2 starts and works on Apache
Harmony!
Some steps yet need to be taken for that to happen - see [1] for
details.

Some issues were overcome, some workarounded, and some just hotfixed and
wait for their proper resolution, like GERONIMO-3757.

Three important problems that still need investigation are:
- HTTP interface works badly (HTTPS works fine).
- The application takes up all the CPU resources on both cores I have
available so the machine is 100% busy.
- The application takes up all the memory specified in -Xms option.

Otherwise, I was able to browse the console freely and even deploy
SPECjAppServer2004.
No serious load was tested however.

Vasily Zakharov
Intel ESSD

[1] http://cwiki.apache.org/confluence/display/GMOxDOC20/Apache+Harmony

Re: Geronimo 2.0.2 starts on Harmony!

2008-01-17 Thread Kevan Miller



On Jan 17, 2008, at 6:15 PM, Zakharov, Vasily M wrote:


Hi, all,

Well, finally I can say Geronimo 2.0.2 starts and works on Apache
Harmony!
Some steps yet need to be taken for that to happen - see [1] for
details.

Some issues were overcome, some workarounded, and some just hotfixed  
and

wait for their proper resolution, like GERONIMO-3757.

Three important problems that still need investigation are:
- HTTP interface works badly (HTTPS works fine).
- The application takes up all the CPU resources on both cores I have
available so the machine is 100% busy.
- The application takes up all the memory specified in -Xms option.

Otherwise, I was able to browse the console freely and even deploy
SPECjAppServer2004.
No serious load was tested however.


Nice. Congrats Vasily.

Sounds like we have a little ways to go... Let us know what you find  
about memory and CPU consumption...


Strange about the behavior under HTTP...

--kevan

RE: Geronimo 2.0.2 starts on Harmony!


 Strange about the behavior under HTTP...

I'm amazed too. I thought it was critical problem until I tried HTTPS to
make sure SSL is working - and bingo, it was fine that way. Some stupid
problem in Harmony, I suppose.

Vasily


-Original Message-
From: Kevan Miller [mailto:[EMAIL PROTECTED] 
Sent: Friday, January 18, 2008 2:26 AM
To: dev@geronimo.apache.org
Subject: Re: Geronimo 2.0.2 starts on Harmony!


On Jan 17, 2008, at 6:15 PM, Zakharov, Vasily M wrote:

 Hi, all,

 Well, finally I can say Geronimo 2.0.2 starts and works on Apache
 Harmony!
 Some steps yet need to be taken for that to happen - see [1] for
 details.

 Some issues were overcome, some workarounded, and some just hotfixed  
 and
 wait for their proper resolution, like GERONIMO-3757.

 Three important problems that still need investigation are:
 - HTTP interface works badly (HTTPS works fine).
 - The application takes up all the CPU resources on both cores I have
 available so the machine is 100% busy.
 - The application takes up all the memory specified in -Xms option.

 Otherwise, I was able to browse the console freely and even deploy
 SPECjAppServer2004.
 No serious load was tested however.

Nice. Congrats Vasily.

Sounds like we have a little ways to go... Let us know what you find  
about memory and CPU consumption...

Strange about the behavior under HTTP...

--kevan

Re: Geronimo 2.0.2 starts on Harmony!

2008-01-17 Thread Jarek Gawor

Cool!

Is this with latest Harmony snapshot? Also, if you rename or remove
the bin/jpa.jar you should be able to use the Geronimo scripts to
start up the server.

Jarek

On Jan 17, 2008 6:15 PM, Zakharov, Vasily M [EMAIL PROTECTED] wrote:
 Hi, all,

 Well, finally I can say Geronimo 2.0.2 starts and works on Apache
 Harmony!
 Some steps yet need to be taken for that to happen - see [1] for
 details.

 Some issues were overcome, some workarounded, and some just hotfixed and
 wait for their proper resolution, like GERONIMO-3757.

 Three important problems that still need investigation are:
 - HTTP interface works badly (HTTPS works fine).
 - The application takes up all the CPU resources on both cores I have
 available so the machine is 100% busy.
 - The application takes up all the memory specified in -Xms option.

 Otherwise, I was able to browse the console freely and even deploy
 SPECjAppServer2004.
 No serious load was tested however.

 Vasily Zakharov
 Intel ESSD

 [1] http://cwiki.apache.org/confluence/display/GMOxDOC20/Apache+Harmony

Re: Geronimo 2.0.2 starts on Harmony!