[BUILD] 2.0: Failed for Revision: 605104

2007-12-18 Thread prasad
Geronimo Revision: 605104 built with tests included
 
See the full build-0200.log file at 
http://people.apache.org/~prasad/binaries/2.0/20071218/build-0200.log
 
Download the binaries from 
http://people.apache.org/~prasad/binaries/2.0/20071218
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 24 minutes 27 seconds
[INFO] Finished at: Tue Dec 18 02:30:16 EST 2007
[INFO] Final Memory: 230M/1006M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/~prasad/testsuite/ResultsSummary.html
 
Assembly: tomcat
=
See the full test.log file at 
http://people.apache.org/~prasad/binaries/2.0/20071218/logs-0200-tomcat/test.log
 
 
Assembly: jetty
=
See the full test.log file at 
http://people.apache.org/~prasad/binaries/2.0/20071218/logs-0200-jetty/test.log
 
[INFO] Running console-testsuite.basic-console
[INFO] Tests run: 38, Failures: 33, Errors: 0, Skipped: 0, Time elapsed: 
3,634.463 sec  FAILURE!


[jira] Resolved: (GERONIMO-3711) NPE if connection fails and callback is not provided

2007-12-18 Thread Rick McGuire (JIRA)

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

Rick McGuire resolved GERONIMO-3711.


Resolution: Fixed

Committed revision 605170.

Thanks Sangjin

 NPE if connection fails and callback is not provided
 

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


 Callbacks are now optional as it is no longer the only way to handle the 
 result from asynchronous requests.  In the implementation, the callbacks are 
 now included as part of completing the ResponseFuture.  Thus, as the 
 operations complete, the callbacks should be invoked (if set) inside 
 ResponseFuture.
 If connection fails, the connect future object gets invoked, but the current 
 connect future (AsyncHttpClient.FutureListener) contains direct calls to 
 AsyncHttpClientCallback.onException().  There are two problems with this: (1) 
 callbacks may be null, so this may result in NPE, and (2) future will not be 
 completed if connection fails.
 The solution is to properly set the exception on the ResponseFuture, and that 
 will take care of the callback invocation as well.

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



[jira] Commented: (GERONIMO-3706) support for proxy

2007-12-18 Thread Rick McGuire (JIRA)

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

Rick McGuire commented on GERONIMO-3706:


Should the proxy configuration be specified on the HttpRequestMessage or on the 
AsyncHttpClient?  There's going to need to be some attribute set on the message 
that allows the request encoder to know if the request needs to be a proxy 
request or a normal direct request.  This could be something that's turned on 
by the AsyncHttpClient  or the request could directly carry the proxy 
information and the AsyncHttpClient could use the information from the request 
to determine how to make the connection.  This is somewhat similar to how the 
SSLContext information is handled. 

 support for proxy
 -

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

 Proxy support is a critical feature for HTTP clients.  I'd like to have 
 AsyncHttpClient support proxy.  The following would be considered as the 
 basic features:
 - Enabling connecting through proxies for http and https targets
 - Exclusion (domains that should not go through proxies)
 - Allowing proxy related configuration on AsyncHttpClient
 - Support for proxy authentication, at least for Basic authentication (and 
 perhaps Digest too?)
 There are things like SOCKS support, etc., but the above will be a good 
 start.  Thoughts?

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



[jira] Created: (GERONIMO-3712) Remove redundent statisitcs from JettyConnectorStats and JettyWebConnectorStats

2007-12-18 Thread Anita Kulshreshtha (JIRA)
Remove redundent statisitcs from JettyConnectorStats and JettyWebConnectorStats
---

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


Jetty WebConnector has a ConnectionsCount statistics which should be included 
in TimeStatistics named ConnectionsDuration.
JettyWebContainer has a RequestCount statistics which should be included in 
TimeStatistics named RequestDuration.
   Currently the average value is stored in TimeStatistics.count. which is 
incorrect.

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



[jira] Updated: (GERONIMO-3712) Remove redundent statisitcs from JettyConnectorStats and JettyWebConnectorStats

2007-12-18 Thread Anita Kulshreshtha (JIRA)

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

Anita Kulshreshtha updated GERONIMO-3712:
-

Component/s: Jetty
 console

 Remove redundent statisitcs from JettyConnectorStats and 
 JettyWebConnectorStats
 ---

 Key: GERONIMO-3712
 URL: https://issues.apache.org/jira/browse/GERONIMO-3712
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: console, Jetty, management
 Environment: All
Reporter: Anita Kulshreshtha
Assignee: Anita Kulshreshtha
 Fix For: 2.1


 Jetty WebConnector has a ConnectionsCount statistics which should be included 
 in TimeStatistics named ConnectionsDuration.
 JettyWebContainer has a RequestCount statistics which should be included in 
 TimeStatistics named RequestDuration.
Currently the average value is stored in TimeStatistics.count. which is 
 incorrect.

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



[jira] Commented: (GERONIMO-3707) use Executor rather than ExecutorService for thread pools that are passed into AsyncHttpClient

2007-12-18 Thread Rick McGuire (JIRA)

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

Rick McGuire commented on GERONIMO-3707:


Currently AsyncHttpClient takes an ExecutorService as an argument for the 
thread pool that gets passed into the SocketConnector constructor. Also, it 
uses ExecutorService as the type for the event thread pool which is passed to 
the ExecutorFilter.

In both cases, Mina APIs actually take simply Executor. Therefore, it is 
possible to simply pass in Executor rather than ExecutorService. This is very 
helpful because the caller may need to retrofit existing thread pool 
implementations. Implementing Executor is considerably easier than 
ExecutorService.

One implication of this change is that AsyncHttpClient will no longer own and 
manage the thread pool that gets passed in. I believe that is also OK as the 
caller can (and perhaps should) handle the lifecycle of a thread pool that it 
created.

 Description
   Currently AsyncHttpClient takes an ExecutorService as an argument for the 
thread pool that gets passed into the SocketConnector constructor. Also, it 
uses ExecutorService as the type for the event thread pool which is passed to 
the ExecutorFilter. In both cases, Mina APIs actually take simply Executor. 
Therefore, it is possible to simply pass in Executor rather than 
ExecutorService. This is very helpful because the caller may need to retrofit 
existing thread pool implementations. Implementing Executor is considerably 
easier than ExecutorService. One implication of this change is that 
AsyncHttpClient will no longer own and manage the thread pool that gets 
passed in. I believe that is also OK as the caller can (and perhaps should) 
handle the lifecycle of a thread pool that it created.
Show »


 use Executor rather than ExecutorService for thread pools that are passed 
 into AsyncHttpClient
 --

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

 Currently AsyncHttpClient takes an ExecutorService as an argument for the 
 thread pool that gets passed into the SocketConnector constructor.  Also, it 
 uses ExecutorService as the type for the event thread pool which is passed to 
 the ExecutorFilter.
 In both cases, Mina APIs actually take simply Executor.  Therefore, it is 
 possible to simply pass in Executor rather than ExecutorService.  This is 
 very helpful because the caller may need to retrofit existing thread pool 
 implementations.  Implementing Executor is considerably easier than 
 ExecutorService.
 One implication of this change is that AsyncHttpClient will no longer own 
 and manage the thread pool that gets passed in.  I believe that is also OK as 
 the caller can (and perhaps should) handle the lifecycle of a thread pool 
 that it created.

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



Re: Greetings from Japan Apache Geronimo User Group

2007-12-18 Thread Hernan Cunico
What about adding a section on the web site for user groups!?

Cheers!
Hernan

Kevan Miller wrote:
 I think it would be a good idea to some pointers to groups like this on 
 our web site. What do others think?
 
 Any other user groups/translation sights that are out there?
 
 --kevan
 
 On Nov 26, 2007, at 7:57 PM, 石田 剛 wrote:
 
 Hello, everyone.

 This is the Greetings from Japan Apache Geronimo User Group.
 http://geronimo-jp.sourceforge.jp/

 We, Japan Apache Geronimo User Group , are virtual community of the 
 Geronimo-lovers. We have more than 50 members as of today, and the 
 communiy is managed on a volunteer basis. We really appreciate and 
 thank you for your great work, and efforts.

 Just to let you know, some of the members in our group would like to 
 start translating the Geronimo Tech Docs into Japanese. We're in a 
 preparation phase, and it may take some time, but our goal is 
 publishing the translated docs to Geronimo Wiki. ( Another goal is , 
 of cource, having fun ! as we're all volunteers and having fun in the 
 community )

 You can reach us at
 [EMAIL PROTECTED] 
 mailto:[EMAIL PROTECTED](to all members)
 or
 [EMAIL PROTECTED] 
 mailto:[EMAIL PROTECTED]   (to translation 
 members)

 I just wanted to say hello and thank you , and make a formal greetings.
 Lastly, please keep on the good works like it has been !

 Regards.
  

 
 New Design Yahoo! JAPAN 2008/01/01 http://pr.mail.yahoo.co.jp/newdesign/
 


[jira] Resolved: (GERONIMO-3617) AsyncHttpClient should support retries on connection failures

2007-12-18 Thread Rick McGuire (JIRA)

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

Rick McGuire resolved GERONIMO-3617.


Resolution: Fixed
  Assignee: Rick McGuire

Committed revision 605288. 

 AsyncHttpClient should support retries on connection failures
 -

 Key: GERONIMO-3617
 URL: https://issues.apache.org/jira/browse/GERONIMO-3617
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: AsyncHttpClient
Affects Versions: 1.x
Reporter: Sangjin Lee
Assignee: Rick McGuire
 Attachments: 3617.patch


 AsyncHttpClient should provide a way to support retries if initial connection 
 attempts fail.  There should be a configuration where connection retries are 
 enabled and also the maximum number of attempts is specified.  If these are 
 set, connection attempts should be retried.

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



[jira] Resolved: (GERONIMO-3707) use Executor rather than ExecutorService for thread pools that are passed into AsyncHttpClient

2007-12-18 Thread Rick McGuire (JIRA)

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

Rick McGuire resolved GERONIMO-3707.


Resolution: Fixed
  Assignee: Rick McGuire

Committed revision 605292.

This change makes sense for reasons beyond those in the original description.  

 use Executor rather than ExecutorService for thread pools that are passed 
 into AsyncHttpClient
 --

 Key: GERONIMO-3707
 URL: https://issues.apache.org/jira/browse/GERONIMO-3707
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: AsyncHttpClient
Affects Versions: 1.x
Reporter: Sangjin Lee
Assignee: Rick McGuire
Priority: Minor

 Currently AsyncHttpClient takes an ExecutorService as an argument for the 
 thread pool that gets passed into the SocketConnector constructor.  Also, it 
 uses ExecutorService as the type for the event thread pool which is passed to 
 the ExecutorFilter.
 In both cases, Mina APIs actually take simply Executor.  Therefore, it is 
 possible to simply pass in Executor rather than ExecutorService.  This is 
 very helpful because the caller may need to retrofit existing thread pool 
 implementations.  Implementing Executor is considerably easier than 
 ExecutorService.
 One implication of this change is that AsyncHttpClient will no longer own 
 and manage the thread pool that gets passed in.  I believe that is also OK as 
 the caller can (and perhaps should) handle the lifecycle of a thread pool 
 that it created.

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



[jira] Commented: (GERONIMO-3706) support for proxy

2007-12-18 Thread Sangjin Lee (JIRA)

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

Sangjin Lee commented on GERONIMO-3706:
---

This is the only semi-official spec I could find on HTTP CONNECT for 
tunneling.

http://www.web-cache.com/Writings/Internet-Drafts/draft-luotonen-web-proxy-tunneling-01.txt



 support for proxy
 -

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

 Proxy support is a critical feature for HTTP clients.  I'd like to have 
 AsyncHttpClient support proxy.  The following would be considered as the 
 basic features:
 - Enabling connecting through proxies for http and https targets
 - Exclusion (domains that should not go through proxies)
 - Allowing proxy related configuration on AsyncHttpClient
 - Support for proxy authentication, at least for Basic authentication (and 
 perhaps Digest too?)
 There are things like SOCKS support, etc., but the above will be a good 
 start.  Thoughts?

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



[jira] Commented: (GERONIMO-3706) support for proxy

2007-12-18 Thread Sangjin Lee (JIRA)

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

Sangjin Lee commented on GERONIMO-3706:
---

More on the SSL tunneling.  The sequence of events that needs to happen is

- open a socket and connect to the proxy
- send a HTTP CONNECT request to the proxy
- receive an OK response from the proxy
- layer the socket with the SSL socket

then the socket is ready to use, and will act just like an ordinary SSL socket 
from the client perspective.

In pseudo-code (in a blocking form), this might be what needs to happen.  If 
your intended target is https://issues.apache.org,

Socket socket = new Socket(proxyHost, proxyPort);

// using the socket, send the following request
CONNECT issues.apache.org:443 HTTP/1.0
(one may add headers like Via, Host, and User-Agent, but I think they're not 
critical in making the request...)
(Proxy-Authorization header needs to be added if the proxy requires 
authentication)

// receive the response from the socket; if successful, one should see a 
response of the form
HTTP/1.0 200 Connection established
Proxy-agent: some proxy server

// once that request-response has been established, wrap it as an SSL socket
SSLSocket sslSock = (SSLSocket)sslSocketFactory.createSocket(socket, 
issues.apache.org, 443, true);



 support for proxy
 -

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

 Proxy support is a critical feature for HTTP clients.  I'd like to have 
 AsyncHttpClient support proxy.  The following would be considered as the 
 basic features:
 - Enabling connecting through proxies for http and https targets
 - Exclusion (domains that should not go through proxies)
 - Allowing proxy related configuration on AsyncHttpClient
 - Support for proxy authentication, at least for Basic authentication (and 
 perhaps Digest too?)
 There are things like SOCKS support, etc., but the above will be a good 
 start.  Thoughts?

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



[jira] Commented: (GERONIMO-3706) support for proxy

2007-12-18 Thread Sangjin Lee (JIRA)

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

Sangjin Lee commented on GERONIMO-3706:
---

Actually RFC 2817 does mention this: http://www.ietf.org/rfc/rfc2817.txt.  See 
section 5.2 and 5.3...


 support for proxy
 -

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

 Proxy support is a critical feature for HTTP clients.  I'd like to have 
 AsyncHttpClient support proxy.  The following would be considered as the 
 basic features:
 - Enabling connecting through proxies for http and https targets
 - Exclusion (domains that should not go through proxies)
 - Allowing proxy related configuration on AsyncHttpClient
 - Support for proxy authentication, at least for Basic authentication (and 
 perhaps Digest too?)
 There are things like SOCKS support, etc., but the above will be a good 
 start.  Thoughts?

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



[jira] Commented: (GERONIMO-3300) Upgrade Dojo to 1.0

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

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

Erik B. Craig commented on GERONIMO-3300:
-

Jay,
Are you still toying with this? I can take it over and get this rolling if 
you'd like... I need to get it in for some local changes I have for the 
monitoring console.

 Upgrade Dojo to 1.0
 ---

 Key: GERONIMO-3300
 URL: https://issues.apache.org/jira/browse/GERONIMO-3300
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: console
Affects Versions: 2.1
Reporter: Jay D. McHugh
Assignee: Jay D. McHugh

 Dojo 1.0 is now available.
 But, to upgrade we will either need to rewrite all of the plugins that use 
 Dojo widgets to use the new (backward incompatible) versions -or- include 
 both the 0.4.3 and 1.0.0 versions of Dojo.
 Having both versions would make it possible to transition over to the newer 
 version of Dojo in a more leisurely fashion but would introduce a fairly 
 significant amount of bloat.
 I would prefer that we would just replace the old version and rewrite 
 whatever needs to be rewritten but that would depend on how soon we are 
 trying to get G2.1 out the door.

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



Unable to render portlet SecurityRealmPortlet

2007-12-18 Thread Hernan Cunico

Hi folks,
I remember reading about a Security Realm issue but can't find it now, either 
way I think it was a NPE.

Is there anybody else getting this error? I get this by just clicking on the 
Security Realms link from the console.


16:49:41,687 ERROR [SecurityRealmPortlet] Unable to render portlet
java.lang.ClassCastException: 
org.apache.geronimo.security.realm.GenericSecurityRealm
   at 
org.apache.geronimo.console.securitymanager.realm.SecurityRealmPortlet.renderList(SecurityRealmPortlet.java:565)
   at 
org.apache.geronimo.console.securitymanager.realm.SecurityRealmPortlet.doView(SecurityRealmPortlet.java:256)
   ...


Cheers!
Hernan


extract a server status

2007-12-18 Thread David Jencks
I have the feature whereby you can specify a set of plugins in a  
geronimo server and extract a server containing only those plugins  
and their dependencies working from gshell.  There are some rough  
edges some of which I'm not entirely sure how to fix.  It would be  
great to get some testing and feedback on this before 2.1 goes out.


1. You have to include the boilerplate configuration explicitly in  
your list of desired plugins.  If you don't, the bin/ stuff and  
suchlike won't be there.  This plugin sets up quite a bit of the  
basic file structure of the server.  I'm currently thinking of trying  
to split this up into support for the basic server, client, gshell,  
and corba specs and having dependencies from various other modules on  
them.  I'm not sure how this will work but it might also help shrink  
the framework server.


2. you have to specify the plugins you want all at once using numbers  
from a list presented to you.  This is pretty limiting.  We could  
have a separate package command and let you run the add plugins to  
assembly part multiple times before packaging the result.  Also it  
would be good for scripting to be able to supply the list of plugins  
by artifactId rather than a fairly meaningless number.


3. if you don't supply the required info about the artifactID of the  
assembled server you should be prompted for it.


4. We might want to support assembling a server using any collection  
of plugin repositories, not just the current server.


5. there's no admin console page for this function.  I'd like to try  
to write one but since my web development skills are somewhere near 0  
I might need some help.


6. Right now the assembled server is left sitting in var/temp.  It  
might be worth trying to deploy to the local maven repo.


7. The plugin functionality is a nontrivial amount of code, so its  
probably a good idea to put it in a separate jar from geronimo-system  
and give it its own configuration so you can have a server without it.


Comments on these ideas and the functionality itself would be  
appreciated.


BTW the gshell command looks like this:

 deploy/assemble -g org.foo -a test-server -v 1.0-SNAPSHOT

where -g is the groupId (currently not used)
-a is the artifact id
-v is the version
-f is the format (zip or tar.gz)
-t is the assembly location (default var/temp/assembly)

thanks
david jencks


[jira] Commented: (GERONIMO-3300) Upgrade Dojo to 1.0

2007-12-18 Thread Jay D. McHugh (JIRA)

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

Jay D. McHugh commented on GERONIMO-3300:
-

Erik,

If you can get it working that would be great.  I am in the middle of 
rebuilding my computer and right now I can't build anything.

Jay

 Upgrade Dojo to 1.0
 ---

 Key: GERONIMO-3300
 URL: https://issues.apache.org/jira/browse/GERONIMO-3300
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: console
Affects Versions: 2.1
Reporter: Jay D. McHugh
Assignee: Jay D. McHugh

 Dojo 1.0 is now available.
 But, to upgrade we will either need to rewrite all of the plugins that use 
 Dojo widgets to use the new (backward incompatible) versions -or- include 
 both the 0.4.3 and 1.0.0 versions of Dojo.
 Having both versions would make it possible to transition over to the newer 
 version of Dojo in a more leisurely fashion but would introduce a fairly 
 significant amount of bloat.
 I would prefer that we would just replace the old version and rewrite 
 whatever needs to be rewritten but that would depend on how soon we are 
 trying to get G2.1 out the door.

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



[jira] Commented: (GERONIMO-3300) Upgrade Dojo to 1.0

2007-12-18 Thread Jay D. McHugh (JIRA)

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

Jay D. McHugh commented on GERONIMO-3300:
-

By the way Erik,

Dojo 1.0.2 just came out Sunday - So 1.0.1 is already out of date.

If it would be easier for you - you could just nuke what I had out there.

Jay

 Upgrade Dojo to 1.0
 ---

 Key: GERONIMO-3300
 URL: https://issues.apache.org/jira/browse/GERONIMO-3300
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: console
Affects Versions: 2.1
Reporter: Jay D. McHugh
Assignee: Jay D. McHugh

 Dojo 1.0 is now available.
 But, to upgrade we will either need to rewrite all of the plugins that use 
 Dojo widgets to use the new (backward incompatible) versions -or- include 
 both the 0.4.3 and 1.0.0 versions of Dojo.
 Having both versions would make it possible to transition over to the newer 
 version of Dojo in a more leisurely fashion but would introduce a fairly 
 significant amount of bloat.
 I would prefer that we would just replace the old version and rewrite 
 whatever needs to be rewritten but that would depend on how soon we are 
 trying to get G2.1 out the door.

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



[jira] Commented: (GERONIMO-3706) support for proxy

2007-12-18 Thread Sangjin Lee (JIRA)

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

Sangjin Lee commented on GERONIMO-3706:
---

I have a suggestion that I suspect will work for the SSL tunneling.  The notion 
of mina IoFilters is exactly for this type of operations.  Once inserted in the 
chain, IoFilters can intercept events and messages in either direction, and 
take its own action and/or forward it to the next filter.

My idea revolves around creating a *one-time* IoFilter that does the HTTP 
CONNECT transaction once the socket is connected.  Once it receives a 
successful response from the proxy as a result of the CONNECT request, then it 
can *remove itself from the chain* (as it's fulfilled its purpose) and add the 
SSL filter to the chain to create the layering.

It may sound sneaky, but it might be a natural solution given the mina 
architecture.

I'll see if I can work out a proof of concept...

 support for proxy
 -

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

 Proxy support is a critical feature for HTTP clients.  I'd like to have 
 AsyncHttpClient support proxy.  The following would be considered as the 
 basic features:
 - Enabling connecting through proxies for http and https targets
 - Exclusion (domains that should not go through proxies)
 - Allowing proxy related configuration on AsyncHttpClient
 - Support for proxy authentication, at least for Basic authentication (and 
 perhaps Digest too?)
 There are things like SOCKS support, etc., but the above will be a good 
 start.  Thoughts?

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



[BUILD] 2.1: Failed for Revision: 605384

2007-12-18 Thread prasad
OpenEJB trunk at 605377
Geronimo Revision: 605384 built with tests included
 
See the full build-2100.log file at 
http://people.apache.org/~prasad/binaries/trunk/20071218/build-2100.log
 
[INFO] Copying 2 files to 
/home/prasad/geronimo/trunk/applications/mejb/geronimo-mejb/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/mejb/geronimo-mejb/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [jar:jar]
[INFO] Building jar: 
/home/prasad/geronimo/trunk/applications/mejb/geronimo-mejb/target/geronimo-mejb-2.1-SNAPSHOT.jar
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-mejb-2.1-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing 
/home/prasad/geronimo/trunk/applications/mejb/geronimo-mejb/target/geronimo-mejb-2.1-SNAPSHOT.jar
 to 
/home/prasad/.m2/repository/org/apache/geronimo/applications/geronimo-mejb/2.1-SNAPSHOT/geronimo-mejb-2.1-SNAPSHOT.jar
[INFO] 

[INFO] Building Geronimo Configs :: Management EJB (MEJB)
[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/mejb/mejb/target/classes/META-INF
[INFO] Copying 2 files to 
/home/prasad/geronimo/trunk/applications/mejb/mejb/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/mejb/mejb/target/resources/META-INF/plan.xml
[INFO] [car:prepare-metadata]
[INFO] [car:package]
Downloading: http://download.java.net/maven/1//jaxen/jars/jaxen-1.1-beta-9.jar
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//jaxen/jaxen/1.1-beta-9/jaxen-1.1-beta-9.jar
Downloading: 
http://repo1.maven.org/maven2/jaxen/jaxen/1.1-beta-9/jaxen-1.1-beta-9.jar
226K downloaded
[INFO] snapshot org.apache.geronimo.applications:geronimo-mejb:2.1-SNAPSHOT: 
checking for updates from apache-snapshots
[INFO] snapshot org.apache.geronimo.applications:geronimo-mejb:2.1-SNAPSHOT: 
checking for updates from codehaus-snapshots
[INFO] snapshot org.apache.geronimo.applications:geronimo-mejb:2.1-SNAPSHOT: 
checking for updates from apache.snapshots
[INFO] Packaging module configuration: 
/home/prasad/geronimo/trunk/applications/mejb/mejb/target/resources/META-INF/plan.xml
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] java.lang.NullPointerException

[INFO] 
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: 
java.lang.NullPointerException
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: 
java.lang.NullPointerException

[jira] Commented: (GERONIMO-3712) Remove redundent statisitcs from JettyConnectorStats and JettyWebConnectorStats

2007-12-18 Thread Anita Kulshreshtha (JIRA)

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

Anita Kulshreshtha commented on GERONIMO-3712:
--

Committed in rev. 605403

 Remove redundent statisitcs from JettyConnectorStats and 
 JettyWebConnectorStats
 ---

 Key: GERONIMO-3712
 URL: https://issues.apache.org/jira/browse/GERONIMO-3712
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: console, Jetty, management
 Environment: All
Reporter: Anita Kulshreshtha
Assignee: Anita Kulshreshtha
 Fix For: 2.1


 Jetty WebConnector has a ConnectionsCount statistics which should be included 
 in TimeStatistics named ConnectionsDuration.
 JettyWebContainer has a RequestCount statistics which should be included in 
 TimeStatistics named RequestDuration.
Currently the average value is stored in TimeStatistics.count. which is 
 incorrect.

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



[jira] Assigned: (GERONIMO-3645) Monitoring plugins build fails

2007-12-18 Thread Anita Kulshreshtha (JIRA)

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

Anita Kulshreshtha reassigned GERONIMO-3645:


Assignee: Anita Kulshreshtha  (was: Erik B. Craig)

- Fixed the build, see GERONIMO-3697
- Rev 605407 : moved to server/trunk/applications.

 Monitoring plugins build fails
 --

 Key: GERONIMO-3645
 URL: https://issues.apache.org/jira/browse/GERONIMO-3645
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: monitoring
Reporter: Erik B. Craig
Assignee: Anita Kulshreshtha

 Monitoring plugins build fails when there is a clean (empty) local maven 
 repository due to lack of the artifacts
 org.apache.geronimo.modules:modules and
 org.apache.geronimo.configs:configs
 Need to sift through poms and clean up to prevent this

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



[jira] Commented: (GERONIMO-3697) Monitoring Console fix ups

2007-12-18 Thread Anita Kulshreshtha (JIRA)

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

Anita Kulshreshtha commented on GERONIMO-3697:
--

Committed Rev 603737, 604183, 604186, 604644, 605063, 605082, 605406, 605407, 
and 605412
- Removed unnecessary dependencies from poms, Fix poms, 
-  Removed unnecessary jars from wars. TODO - Remove the remaining 2 jars.

 Monitoring Console fix ups 
 ---

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

 This issue is for minor fixes to monitoring console and monitoring agent.

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