[jira] Commented: (GERONIMO-3069) Rework AJAX style console screens to work on Safari
[ https://issues.apache.org/jira/browse/GERONIMO-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559399#action_12559399 ] Joseph Leong commented on GERONIMO-3069: Hey there Jay, Just confirming as well, everything seems to look/work fine on OSX 10.5.1 : Safari 3.0.4 (5523.10) for the trunk -Joseph Leong Rework AJAX style console screens to work on Safari --- Key: GERONIMO-3069 URL: https://issues.apache.org/jira/browse/GERONIMO-3069 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: console Affects Versions: 2.0-M7 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Attachments: geronimo-3069-jmx-1.patch Some of the newer console screens do not work properly in Safari. Try to rewrite the javascript code so that it works on safari. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3752) JACC principal-role mapping installation is too tied to our policy implementation.
JACC principal-role mapping installation is too tied to our policy implementation. -- Key: GERONIMO-3752 URL: https://issues.apache.org/jira/browse/GERONIMO-3752 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: security Affects Versions: 2.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1 We need a couple interfaces to avoid tying the installation of principal-role mapping to our specific jacc implementation. Someone else might want to use it with their jacc implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3752) JACC principal-role mapping installation is too tied to our policy implementation.
[ https://issues.apache.org/jira/browse/GERONIMO-3752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated GERONIMO-3752: --- Attachment: GERONIMO-3752.patch I think this patch should work fine but I'll have to try it out tomorrow. JACC principal-role mapping installation is too tied to our policy implementation. -- Key: GERONIMO-3752 URL: https://issues.apache.org/jira/browse/GERONIMO-3752 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1 Attachments: GERONIMO-3752.patch We need a couple interfaces to avoid tying the installation of principal-role mapping to our specific jacc implementation. Someone else might want to use it with their jacc implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [AsyncHttpClient] order of Future completion and callback invocation
Sangjin Lee wrote: Currently the callback methods from AsyncHttpClientCallback get called *after* the response future object is completed. I think this causes a subtle bug that may prevent the callback methods from being completed if one uses both the callback and the future. For example, consider the following case: ResponseFuture future = client.invoke(..., callback); // callback is not null HttpResponseMessage response = future.get(); // this blocks until future is complete Since the future is completed before the callback is invoked, the caller thread in this case gets unblocked before the callback is called. If the caller thread goes away, then there is possibility that the callback may not be completed or may not even be called, depending on the timing. This strikes me as a bug... I propose we invoke the callback first and then complete the future so the callbacks are guaranteed to be completed even if future is used. What do you think? I'll open a JIRA issue if you guys agree this is a bug. Yes, I agree. If the callback is used, then we should ensure that it gets called appropriately. Thanks, Sangjin
Re: [YOKO]
I'm +1 for 1.0 release too. I've reviewed japitool results for ORB area of Harmony and I have not find any differences which are result of 1.4 compatibility of Yoko. So it looks like there is no difference for Harmony in this case. But yes, Harmony is 1.5 (however it has 1.6 branch :) and any 1.5 compatible code is acceptable for it. 2008/1/15, Lars Kühne [EMAIL PROTECTED]: On Jan 14, 2008 8:05 PM, Alan D. Cabrera wrote: On Jan 14, 2008, at 4:35 AM, Rick McGuire wrote: What cleanup steps need to be taken with the yoko code now that it's been made a subproject in Geronimo? The first obvious one would be to remove the non-core components from the trunk. The second would be to remove the incubating from the version names. Agreed +1 Is JDK 1.4 still a given or has geronimo upgraded it's JDK dependency to 1.5 since yoko entered the incubator? We shouldn't change the required JDK in a point release, so this seems like a good time to revisit this decision. The current code was never made into an official Yoko release. Should we attempt to get this out as an official v1 release as soon as the basic cleanup is completed? I think that some people had some concerns about a release but I think that they were more focused on proper documentation and releasing a well rounded product. That was me. My concern wasn't so much about user docs but developer level documentation, see the Answer this question... yoko issues in jira. Those questions mostly about being able to attract new developers. It's my opinion that it's ok to release so long as the code is good enough. With that said, I would like to make a 1.0 release. Yes, the code could use some cleanup but it does pass certification and we can always improve things later, in another release. This of course assumes that we don't have to pay too much attention to backward compatibility. Does each follow-up version have to be a drop-in replacement of the first 1.0 release? Or is it OK to change ORB properties and such, as long as the changes are documented in the release notes (which is what I hope, but I don't know the requirements of Geronimo and Harmony)? It's OK from Harmony point of view. SY, Alexey
[jira] Commented: (GERONIMO-2015) Let's replace JKS to PKCS12 key store type
[ https://issues.apache.org/jira/browse/GERONIMO-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559433#action_12559433 ] Alexey Petrenko commented on GERONIMO-2015: --- If we afraid of possible incompatibilities and not full support of JKS or PKCS12 why not to let user choose? We can specify keystore in configs or choose type from available on current VM. 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 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] Resolved: (GERONIMO-3749) Global session cache can cause multiple client instances to reuse incorrectly configured connections.
[ https://issues.apache.org/jira/browse/GERONIMO-3749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire resolved GERONIMO-3749. Resolution: Fixed Committed revision 612419. Global session cache can cause multiple client instances to reuse incorrectly configured connections. - Key: GERONIMO-3749 URL: https://issues.apache.org/jira/browse/GERONIMO-3749 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Reporter: Rick McGuire Priority: Minor Attachments: 3749.patch The current connection reuse mechanism relies on a single global session class per process (or really, per class loader that loads the ahc code) to store all of the i/o sessions indexed by host/port. Since the selection is made based totally on host and port, it is possible that one ahc client could end up reusing a connection created by a client with a completely different connection configuration. Caching should be implemented using a instance-based cache rather than a single global session cache. -- 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?
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] Resolved: (GERONIMO-3751) callbacks may not be completed when caller uses future.get() too to complete request handling
[ https://issues.apache.org/jira/browse/GERONIMO-3751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire resolved GERONIMO-3751. Resolution: Fixed Committed revision 612422. Thanks Sangjin! callbacks may not be completed when caller uses future.get() too to complete request handling - Key: GERONIMO-3751 URL: https://issues.apache.org/jira/browse/GERONIMO-3751 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Priority: Minor Attachments: GERONIMO-3751.patch Currently the callback methods from AsyncHttpClientCallback get called *after* the response future object is completed. I think this causes a subtle bug that may prevent the callback methods from being completed if one uses both the callback and the future. For example, consider the following case: ResponseFuture future = client.invoke(..., callback); // callback is not null HttpResponseMessage response = future.get(); // this blocks until future is complete Since the future is completed before the callback is invoked, the caller thread in this case gets unblocked before the callback is called. If the caller thread goes away, then there is possibility that the callback may not be completed or may not even be called, depending on the timing. This strikes me as a bug... I propose we invoke the callback first and then complete the future so the callbacks are guaranteed to be completed even if future is used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3618) when redirected via status code 30x, the original query is incorrectly appended to the location
[ https://issues.apache.org/jira/browse/GERONIMO-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-3618. -- when redirected via status code 30x, the original query is incorrectly appended to the location --- Key: GERONIMO-3618 URL: https://issues.apache.org/jira/browse/GERONIMO-3618 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Assignee: Rick McGuire Attachments: HttpIoHandler.patch, patch.zip If you're redirected via status code 30x (302, 301, ...), the code that handles following redirects (HttpIoHandler.messageRecieved()) tries to append the original query from the first request to the URL obtained from the Location header of the response. This is incorrect per HTTP specification. The spec says the value of the Location header is an absoluteURI which is a full URL that includes the proper query if any: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30. The query from the original request should not be part of the second URL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3617) AsyncHttpClient should support retries on connection failures
[ https://issues.apache.org/jira/browse/GERONIMO-3617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-3617. -- 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] Closed: (GERONIMO-3703) should allow custom SSL context for AsyncHttpClient
[ https://issues.apache.org/jira/browse/GERONIMO-3703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-3703. -- should allow custom SSL context for AsyncHttpClient --- Key: GERONIMO-3703 URL: https://issues.apache.org/jira/browse/GERONIMO-3703 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Priority: Critical Attachments: 3703.patch, test.patch Currently the SSLContext that's used to do https cannot be configured or customized. One needs to be able to create and pass in custom SSLContext to be able to use its own cert directory, keystore file, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3638) should allow URL encoding with custom encoding charset other than the default
[ https://issues.apache.org/jira/browse/GERONIMO-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-3638. -- should allow URL encoding with custom encoding charset other than the default - Key: GERONIMO-3638 URL: https://issues.apache.org/jira/browse/GERONIMO-3638 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Assignee: Rick McGuire Attachments: 3638.patch Currently AsyncHttpClient uses Chartset.defaultCharset() when it encodes the query string. However, applications may want to use a different encoding than the machine default charset; e.g. UTF-8. It needs to provide a way to specify an encoding that AHC should use to encode the query string. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3689) should provide additional thread pool to isolate running of the callback event notification
[ https://issues.apache.org/jira/browse/GERONIMO-3689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-3689. -- should provide additional thread pool to isolate running of the callback event notification - Key: GERONIMO-3689 URL: https://issues.apache.org/jira/browse/GERONIMO-3689 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Attachments: 3689.patch The mina 1.1 documentation recommends disabling the default ThreadModel, as well as additionally providing an ExecutorFilter to isolate code that runs when events are notified (IoHandler) and thus in our case callback code. The default ThreadModel should be disabled by SocketConnectorConfig.setThreadModel(ThreadModel.MANUAL), and there should be an option of supplying a thread pool at the end of the filter chain. Please see http://mina.apache.org/configuring-thread-model.html for more discussion... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3686) AsyncHttpClient does not reuse connection even if connections are persistent
[ https://issues.apache.org/jira/browse/GERONIMO-3686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-3686. -- AsyncHttpClient does not reuse connection even if connections are persistent Key: GERONIMO-3686 URL: https://issues.apache.org/jira/browse/GERONIMO-3686 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Assignee: Rick McGuire Attachments: 3686.patch Each time AsyncHttpClient.sendRequest() is called, a new TCP connection is opened, even though connections may be kept alive per HTTP spec. If connections are kept open, they should be reused for more requests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3711) NPE if connection fails and callback is not provided
[ https://issues.apache.org/jira/browse/GERONIMO-3711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-3711. -- 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] Closed: (GERONIMO-3706) support for proxy
[ https://issues.apache.org/jira/browse/GERONIMO-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-3706. -- 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 Attachments: proxy_poc.patch 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] Closed: (GERONIMO-3717) Queries provided through the URL argument to HttpRequestMessage get lost
[ https://issues.apache.org/jira/browse/GERONIMO-3717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-3717. -- Queries provided through the URL argument to HttpRequestMessage get lost Key: GERONIMO-3717 URL: https://issues.apache.org/jira/browse/GERONIMO-3717 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Assignee: Rick McGuire Attachments: 3717.patch There are two different ways of providing a query parameter to HttpRequestMessage, and both ways should be supported. One way is through the URL argument in the HttpRequestMessage constructor, and the other is via HttpRequestMessage.setParameter(). However, if you supply a query parameter via the former, it gets lost, and is not sent. For example, suppose you want to make a request to http://some_host/path?foo=bar;. One way to construct the request object is HttpRequestMessage msg = new HttpRequestMessage(new URL(http://some_host/path?foo=bar;, cb); The other way is HttpRequestMessage msg = new HttpRequestMessage(new URL(http://some_host/path;), cb); msg.setParameter(foo, bar); However, the encoder (HttpRequestEncoder) uses only URL.getPath() (which returns only /path in this example) to form the request line. The correct method it should have used is URL.getFile() (which returns /path?foo=bar in this example). It is apparent that AHC expects to support both usages, as there is code that tries to add any parameter in addition to any existing queries already in the URL, except it's not done quite right. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3707) use Executor rather than ExecutorService for thread pools that are passed into AsyncHttpClient
[ https://issues.apache.org/jira/browse/GERONIMO-3707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-3707. -- 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] Closed: (GERONIMO-2614) LDAP Viewer portlet should warn you is the LDAP support plugin is not installed and/or started
[ https://issues.apache.org/jira/browse/GERONIMO-2614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hernan Cunico closed GERONIMO-2614. --- Resolution: Fixed Fix Version/s: 2.1 There was an error first time you accessed the portlet, it seemed it was looking for a local LDAP by default. This is fixed in 2.1 trunk. Closing this issue. LDAP Viewer portlet should warn you is the LDAP support plugin is not installed and/or started -- Key: GERONIMO-2614 URL: https://issues.apache.org/jira/browse/GERONIMO-2614 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.2 Environment: this is for revision r480769 Reporter: Hernan Cunico Fix For: 2.1 LDAP support is available only via plugins now. The LDAP Viewer portlet shown an error pop-up window stating there is a connection error. The portlet should either know the plugin is not installed or the portlet itself should be provided as part of the LDAP support plugin. -- 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
[
https://issues.apache.org/jira/browse/GERONIMO-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559487#action_12559487
]
Anita Kulshreshtha commented on GERONIMO-1775:
--
could you have used the i18N facilities defined by PLT.6.2 Portlet Resource
Bundle and PLT.21.10 Resource Bundles in the JSR 168 Specification?
e.g. somehing like this in portlet.xml:
{code:xml}
portlet
...
portlet-info
titleStock Quote Portlet/title
short-titleStock/short-title
keywordsfinance,stock market/keywords
resource-bundlecom.foo.myApp.QuotePortlet/resource-bundle
/portlet-info
...
/portlet
{code}
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] Updated: (GERONIMO-2712) LDAP editing capability from Admin Console
[ https://issues.apache.org/jira/browse/GERONIMO-2712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hernan Cunico updated GERONIMO-2712: Affects Version/s: (was: 2.0-M5) (was: 2.0-M2) (was: 2.0-M4) (was: 1.2) (was: 2.0-M3) (was: 2.0-M1) Wish List Moved to wish list. The idea was not to duplicate other projects functionality but to expand some basic capabilities, just for practical purposes. If a Geronimo LDAP plugin is available and Geronimo also provides a way to browse the LDAP server then it would be great to have the ability to perform some very basic functions directly from the Geronimo Administration Console (like importing an ldif). LDAP editing capability from Admin Console -- Key: GERONIMO-2712 URL: https://issues.apache.org/jira/browse/GERONIMO-2712 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: Wish List Reporter: Hernan Cunico Fix For: Wish List Currently from the console we are able to just view the content of the LDAP server but rely on external applications to actually import data to this DB. As a new feature and as an improvement from the usability perspective it would be great if we can provide a method to load the *.ldif* files directly form the console. -- 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-1775) Internationalization of the Admin Console
[
https://issues.apache.org/jira/browse/GERONIMO-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559487#action_12559487
]
akulshre edited comment on GERONIMO-1775 at 1/16/08 6:02 AM:
---
could you have used the i18N facilities defined by PLT.6.2 Portlet Resource
Bundle and PLT.21.10 Resource Bundles in the JSR 168 Specification?
e.g. somehing like the following in portlet.xml and use standard keywords
javax.portlet.title, javax.portlet.short-title, and
javax.portlet.keywords.
{code:xml}
portlet
...
supported-localezh/supported-locale
resource-bundlecom.foo.myApp.QuotePortlet/resource-bundle
portlet-info
titleStock Quote Portlet/title
short-titleStock/short-title
keywordsfinance,stock market/keywords
/portlet-info
...
/portlet
{code}
was (Author: akulshre):
could you have used the i18N facilities defined by PLT.6.2 Portlet
Resource Bundle and PLT.21.10 Resource Bundles in the JSR 168 Specification?
e.g. somehing like this in portlet.xml:
{code:xml}
portlet
...
portlet-info
titleStock Quote Portlet/title
short-titleStock/short-title
keywordsfinance,stock market/keywords
resource-bundlecom.foo.myApp.QuotePortlet/resource-bundle
/portlet-info
...
/portlet
{code}
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.
Re: Geronimo v2.1 documentation
On Jan 10, 2008, at 5:14 PM, Hernan Cunico wrote: Hi All, some time ago I started to put together some topics for Geronimo v2.1 documentation. I tried to focus on the biggest new things we are offering now, topics we didn't have before and now we need to start from scratch. The Geronimo v2.1 documentation space is already available here http://cwiki.apache.org/GMOxDOC21/documentation.html The initial TOC includes: * Configuration changes * Deployment ** Deployment plan creator * Geronimo Administration Console enhancements * GShell * Monitoring * Pluggable console * Plugin infrastructure enhancements * RELEASE-NOTES-2.1.TXT * Sample applications * Security * Tooling * What's new? Each of these pages already contain a few lines with some initial thoughts. Need your input for adding topics to this list as well as developing them. There might be things we already had in 2.0x but we didn't cover it in the doc, pls need your comments on that as well. I think I'm finish covering *Deployment plan creator*, will do a refresh later on as new code gets in. I also created this place holder http://cwiki.apache.org/GMOxPMGT/geronimo-v21-list-of-functions-status.html under *Apache Geronimo Project Management* on the wiki so we can keep track there the features we have ready for prime time and those that are not so ready ;-) I could definitively use that info to build up a new set of docs, would also help users to see where we are at. Hernan, Thanks for this. Time to start pulling these docs together to prepare for release. It can't all be generated by Hernan. We'll need to chip in... --kevan
Re: svn commit: r612439 [1/2] - in /geronimo/server/trunk: assemblies/geronimo-jetty6-javaee5/ assemblies/geronimo-tomcat6-javaee5/ plugins/clustering/ plugins/clustering/clustering/ plugins/clusterin
On Jan 16, 2008, at 7:48 AM, [EMAIL PROTECTED] wrote: Author: gdamour Date: Wed Jan 16 04:48:37 2008 New Revision: 612439 URL: http://svn.apache.org/viewvc?rev=612439view=rev Log: Move farm related classes to new sub-project geronimo-farm. Add a new configuration farming and move farming related GBeans from the clustering config. to this new one. Also, by default this configuration is not started. Cool. Gianny, can you give us a bit of status about where you are with this? Looks like you're laying some groundwork for OpenEJB dependencies... Enhanced clustering support is really great to have. Want to understand what additional dependencies this is going to require. I think we're overdue for a 2.1 release. We have polish and a number of usability issues to work out in current trunk, prior to this. However, worried about also pushing in a bunch of new function is going to make this difficult... --kevan
[jira] Resolved: (GERONIMO-3069) Rework AJAX style console screens to work on Safari
[ https://issues.apache.org/jira/browse/GERONIMO-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh resolved GERONIMO-3069. - Resolution: Fixed Fix Version/s: 2.0.2 2.1 Either Dojo or Safari (or both) made changes that resolved the display problems. Rework AJAX style console screens to work on Safari --- Key: GERONIMO-3069 URL: https://issues.apache.org/jira/browse/GERONIMO-3069 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: console Affects Versions: 2.0-M7 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Fix For: 2.1, 2.0.2 Attachments: geronimo-3069-jmx-1.patch Some of the newer console screens do not work properly in Safari. Try to rewrite the javascript code so that it works on safari. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3069) Rework AJAX style console screens to work on Safari
[ https://issues.apache.org/jira/browse/GERONIMO-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh closed GERONIMO-3069. --- Rework AJAX style console screens to work on Safari --- Key: GERONIMO-3069 URL: https://issues.apache.org/jira/browse/GERONIMO-3069 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: console Affects Versions: 2.0-M7 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Fix For: 2.0.2, 2.1 Attachments: geronimo-3069-jmx-1.patch Some of the newer console screens do not work properly in Safari. Try to rewrite the javascript code so that it works on safari. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
2.1 Release -- Banging the drum
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
[jira] Assigned: (GERONIMO-3694) gsh script in javaee5 server assemblies is not marked executable
[ https://issues.apache.org/jira/browse/GERONIMO-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reassigned GERONIMO-3694: - Assignee: Jarek Gawor (was: Jason Dillon) gsh script in javaee5 server assemblies is not marked executable - Key: GERONIMO-3694 URL: https://issues.apache.org/jira/browse/GERONIMO-3694 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1 Reporter: Kevan Miller Assignee: Jarek Gawor Fix For: 2.1 'gsh' is not marked as executable. there seem to be different mechanisms for the different assemblies. looks like gsh is executable in framework/minimal assemblies (in fact all files are executable in the bin directory of these assemblies). Better if only shell scripts were marked executable... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3694) gsh script in javaee5 server assemblies is not marked executable
[ https://issues.apache.org/jira/browse/GERONIMO-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-3694. --- Resolution: Fixed Committed a fix to trunk (revision 612494). All files in the bin/ directory will now be marked as executable except the .bat files. gsh script in javaee5 server assemblies is not marked executable - Key: GERONIMO-3694 URL: https://issues.apache.org/jira/browse/GERONIMO-3694 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1 Reporter: Kevan Miller Assignee: Jarek Gawor Fix For: 2.1 'gsh' is not marked as executable. there seem to be different mechanisms for the different assemblies. looks like gsh is executable in framework/minimal assemblies (in fact all files are executable in the bin directory of these assemblies). Better if only shell scripts were marked executable... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3753) monitoring portlet is not up to date with dojo 1.0
monitoring portlet is not up to date with dojo 1.0 -- Key: GERONIMO-3753 URL: https://issues.apache.org/jira/browse/GERONIMO-3753 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Priority: Trivial I noticed that when a user clicks on a Graph's name, the graph does not render correctly. I'm pretty sure it has something to do with the new version of dojo. So we need to update monitoringPopUpGraph.jsp to reflect the new version of dojo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2946) Add StAX specs into Geronimo Specs project
[ https://issues.apache.org/jira/browse/GERONIMO-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor closed GERONIMO-2946. - Resolution: Fixed Closing as this work was done by Matt a while ago. Add StAX specs into Geronimo Specs project -- Key: GERONIMO-2946 URL: https://issues.apache.org/jira/browse/GERONIMO-2946 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: specs Affects Versions: 2.0-M4 Environment: All Reporter: Matt Hogstrom Assignee: Matt Hogstrom The StAX API 1.0.1 at Codehaus has introduced a fix for a problem on javax.xml.stream.XMLOutputFactory. The fix in the API is not compatible with the RI and was introduced in an attempt to fix this problem as outlined in JSR 173 MR1. This MR was rejected by Sun and as such the recently released API is no longer compatible with the Java EE 5 RI. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3605) GShell-ize deployer commands
[ https://issues.apache.org/jira/browse/GERONIMO-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-3605. --- Resolution: Fixed All the standard deployer commands are now ported to/accessible via GShell. However, I'm not sure about removing the standard command line tools just yet as GShell still seems to be evolving. GShell-ize deployer commands Key: GERONIMO-3605 URL: https://issues.apache.org/jira/browse/GERONIMO-3605 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 2.1 Reporter: David Jencks Assignee: Jarek Gawor Fix For: 2.1 make the cli deployer commands such as list-plugins accessible through gshell (and then remove the standalone deployer) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GSHELL-54) Allow relative (../ and ./) as well as absolute paths (/foo/bar) to resolve as expected in the layout manager
[ https://issues.apache.org/jira/browse/GSHELL-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner reassigned GSHELL-54: -- Assignee: Jason Warner (was: Jason Dillon) Allow relative (../ and ./) as well as absolute paths (/foo/bar) to resolve as expected in the layout manager - Key: GSHELL-54 URL: https://issues.apache.org/jira/browse/GSHELL-54 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Components: Core Affects Versions: 1.0-alpha-1 Reporter: Jason Dillon Assignee: Jason Warner 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] Assigned: (GSHELL-58) Layout command aliases should be allowed to reference relative command paths for targets
[
https://issues.apache.org/jira/browse/GSHELL-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner reassigned GSHELL-58:
--
Assignee: Jason Warner (was: Jason Dillon)
Layout command aliases should be allowed to reference relative command paths
for targets
Key: GSHELL-58
URL: https://issues.apache.org/jira/browse/GSHELL-58
Project: GShell
Issue Type: Improvement
Security Level: public(Regular issues)
Components: Core
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
Assignee: Jason Warner
Fix For: 1.0-alpha-2
For example:
{code}
...
group
nameremote/name
nodes
command
namersh/name
idgshell-remote:rsh/id
/command
command
namersh-server/name
idgshell-remote:rsh-server/id
/command
alias
namershd/name
commandrsh-server/command
/alias
/nodes
/group
/nodes
/layout
{code}
In this example, the {{remote/rshd}} command alias really wants to point to
{{remote/rsh-server}} but current alias target resolve works from the layout
root.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-206) Error while deploying EAR to running server Geronimo 2.0.1
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559577#action_12559577 ] gennadibereshnoi commented on GERONIMODEVTOOLS-206: --- same by using geronimo-maven-plugin @WIN@mvn -e geronimo:deploy [INFO] [geronimo:deploy] [INFO] Using artifact based module archive(s)... [INFO] Distributing module artifact: ... log4j:WARN No appenders could be found for logger (org.apache.geronimo.deployment.plugin.factories.BaseDep log4j:WARN Please initialize the log4j system properly. Deployer operation failed: Cound not open module file: c:\TMP\GERONIMO.###\2001\geronimo-deployer4332.tmpd org.apache.geronimo.common.DeploymentException: Cound not open module file: c:\TMP\GERONIMO.###\2001\geron at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:223) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:126) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:865) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:865) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:168) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(Unknown Source) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(Unknown Source) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown Source) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.access$100(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.init(Unknown Source) at java.util.jar.JarFile.init(Unknown Source) at java.util.jar.JarFile.init(Unknown Source) at org.apache.geronimo.deployment.util.DeploymentUtil.createJarFile(DeploymentUtil.java:201) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:221) ... 36 more [WARNING] Ignoring failure ! [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 minute 14 seconds [INFO] Finished at: Wed Jan 16 16:25:47 CET 2008 [INFO] Final Memory: 9M/17M [INFO] [EMAIL PROTECTED] mvn -e geronimo:deploy [INFO] [geronimo:deploy] [INFO] Using artifact based module archive(s)... [INFO] Distributing module artifact: /home/maven/.m2/repository/com/oxseed/saas/oxseed.orderstorage.app/1.0.6/oxseed.orderstorage.app-1.0.6.ear with plan
[jira] Updated: (GERONIMODEVTOOLS-206) Error while deploying EAR to running server Geronimo 2.0.1
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gennadibereshnoi updated GERONIMODEVTOOLS-206: -- Priority: Critical (was: Major) Error while deploying EAR to running server Geronimo 2.0.1 -- Key: GERONIMODEVTOOLS-206 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-206 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0.0 Environment: Geronimo 2.0.1 WTP 2.0 + GEP 2.0 Reporter: Tomasz Mazan Assignee: Tim McConnell Priority: Critical Fix For: 2.1.0 Exception on deploy Distribution of configuration failed. See log for details. java.io.FileNotFoundException: C:\DEV\IDE\eclipse-wtp-2.0\workspace\.metadata\.plugins\org.apache.geronimo.st.core\server_13.09.07_14_454\FonBsaCore.zip (File not found) org.apache.geronimo.common.DeploymentException: java.io.FileNotFoundException: C:\DEV\IDE\eclipse-wtp-2.0\workspace\.metadata\.plugins\org.apache.geronimo.st.core\server_13.09.07_14_454\FonBsaCore.zip (File not found) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:121) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:865) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:865) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:168) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1408) at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:81) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1245) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1348) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:782) at sun.reflect.GeneratedMethodAccessor223.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) at java.lang.Thread.run(Thread.java:595) Caused by: java.io.FileNotFoundException: C:\DEV\IDE\eclipse-wtp-2.0\workspace\.metadata\.plugins\org.apache.geronimo.st.core\server_13.09.07_14_454\FonBsaCore.zip (File not found) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:106) at org.apache.geronimo.deployment.util.DeploymentUtil.copyFile(DeploymentUtil.java:92) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:118) ... 34 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
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
---
[YOKO] Heads up
I'm going to remove the WS that went to CXF tonight. Regards, Alan
[jira] Updated: (GERONIMO-3725) The progress bar shown during Geronimo start up needs to be updated
[ https://issues.apache.org/jira/browse/GERONIMO-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-3725: -- Attachment: GERONIMO-3725.patch Attached a patch with a new progress bar. The progress bar shown during Geronimo start up needs to be updated --- Key: GERONIMO-3725 URL: https://issues.apache.org/jira/browse/GERONIMO-3725 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1 Reporter: Jarek Gawor Attachments: GERONIMO-3725.patch The progress bar shown during Geronimo start up (when executing 'geronimo run') needs to be updated. Currently, the size of the bar depends on the number of modules installed. That is, if N number of modules are installed the bar is of size N. So if lots of modules are installed, the bar might wrap around the screen. I think we should replace this bar with a bar based on the percentage of total Geronimo startup (what is currently displayed just as a number). The new bar would not display the detailed information as the existing bar (i.e. which modules successfully started up or failed) but would not suffer from the problem explained above. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMODEVTOOLS-257) Errors when publishing to the Geronimo 2.1 server using the 2.1 version of the GEP
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell closed GERONIMODEVTOOLS-257. -- Resolution: Fixed Fix provided in revision 611355 and verified by Tomasz. Errors when publishing to the Geronimo 2.1 server using the 2.1 version of the GEP -- Key: GERONIMODEVTOOLS-257 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-257 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.0 Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.1.0 As reported by Tomasz Manaz, the following error occurs when publishing to the Geronimo 2.1 server using the 2.1 version of the GEP http://www.nabble.com/file/p14730930/gep-deploy-error.jpg -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3725) The progress bar shown during Geronimo start up needs to be updated
[ https://issues.apache.org/jira/browse/GERONIMO-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559624#action_12559624 ] Jarek Gawor commented on GERONIMO-3725: --- To clarify, the existing bar can visually indicate (by displaying different characters) if a given module is starting, started or failed as the server starts up. But the new bar (in the patch) is just displays the percentage of the total server startup (no per-module info). The progress bar shown during Geronimo start up needs to be updated --- Key: GERONIMO-3725 URL: https://issues.apache.org/jira/browse/GERONIMO-3725 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1 Reporter: Jarek Gawor Attachments: GERONIMO-3725.patch The progress bar shown during Geronimo start up (when executing 'geronimo run') needs to be updated. Currently, the size of the bar depends on the number of modules installed. That is, if N number of modules are installed the bar is of size N. So if lots of modules are installed, the bar might wrap around the screen. I think we should replace this bar with a bar based on the percentage of total Geronimo startup (what is currently displayed just as a number). The new bar would not display the detailed information as the existing bar (i.e. which modules successfully started up or failed) but would not suffer from the problem explained above. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
progress bar at Geronimo startup
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] Assigned: (GERONIMO-3725) The progress bar shown during Geronimo start up needs to be updated
[ https://issues.apache.org/jira/browse/GERONIMO-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reassigned GERONIMO-3725: - Assignee: Jarek Gawor The progress bar shown during Geronimo start up needs to be updated --- Key: GERONIMO-3725 URL: https://issues.apache.org/jira/browse/GERONIMO-3725 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1 Reporter: Jarek Gawor Assignee: Jarek Gawor Attachments: GERONIMO-3725.patch The progress bar shown during Geronimo start up (when executing 'geronimo run') needs to be updated. Currently, the size of the bar depends on the number of modules installed. That is, if N number of modules are installed the bar is of size N. So if lots of modules are installed, the bar might wrap around the screen. I think we should replace this bar with a bar based on the percentage of total Geronimo startup (what is currently displayed just as a number). The new bar would not display the detailed information as the existing bar (i.e. which modules successfully started up or failed) but would not suffer from the problem explained above. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: MailGBean/JNDI problem on Harmony
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] Closed: (GERONIMODEVTOOLS-258) GEP by default can no longer deploy to all targets returned from the deployment manager
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell closed GERONIMODEVTOOLS-258. -- Resolution: Fixed Fixed in revision 612208 and verified by Tomasz GEP by default can no longer deploy to all targets returned from the deployment manager --- Key: GERONIMODEVTOOLS-258 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-258 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.0 Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.1.0 Now that the Geronimo 2.1 server supports clustering multiple targets will likely be returned from any getTargets() method invoked on the deployment manager. The GEP should use only the first target, which is the default configuration store and which is explicitly configured by users. Otherwise, the artifacts will get deployed to the master-repository, the cluster-repository, and the local repository which is obviously incorrect and will result in deployment errors. Thanks to Gianny for this very useful bit of information -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [SECURITY] Potential vulnerability in Jetty servlet container
I've updated this notice with a better location from which to obtain the jetty-6.1.7.jar (see below). Joe Bohn wrote: The Geronimo project has learned of a security vulnerability in the Jetty servlet container (6.1.5) included in Geronimo. If you use a Jetty configuration of Geronimo you may be affected by the vulnerability. This vulnerability impacts Jetty configurations of Geronimo 2.0.1 and 2.0.2. For specific information regarding the Jetty vulnerability, see http://www.kb.cert.org/vuls/id/553235 The problem is related to the processing of URLs which contain multiple consecutive forward slash (/) characters that are handled incorrectly (for example . http://foo//../bar). If your system is susceptible to attacks using such URLs we recommend that you filter these URLs using an application firewall or reverse proxy server. Alternatively, you can upgrade your Geronimo Jetty server image to utilize the corrected Jetty 6.1.7 jar: - Obtain a jetty-6.1.7.jar from http://repo1.maven.org/maven2/org/mortbay/jetty/jetty/6.1.7/jetty-6.1.7.jar - Stop your Geronimo Jetty server image - copy jetty-6.1.7.jar to geronimo-root/repository/org/mortbay/jetty/jetty/6.1.7/jetty-6.1.7.jar - remove the jetty 6.1.5 jar: geronimo-root/repository/org/mortbay/jetty/jetty/6.1.5/jetty-6.1.5.jar - start the Geronimo Jetty server. The server will now be using the 6.1.7 Jetty jar. This vulnerability will be fixed in the next release of Geronimo (2.0.3 and/or 2.1) which will include Jetty 6.1.7 correcting the vulnerability.
[jira] Commented: (GERONIMO-3581) Default security relam name in ContextManager
[ https://issues.apache.org/jira/browse/GERONIMO-3581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559648#action_12559648 ] Jarek Gawor commented on GERONIMO-3581: --- There are two (related) issues here. 1) Forgetting about OpenEJB for a moment, ContextManager.login() creates LoginContext. And LoginContext will throw NPE if the security realm is null. So we could either add a null check to ContextManager.login() or pass a default security realm name. 2) With OpenEJB, OpenEJB uses GeronimoSecurityService to login. That class has two login functions. First, the one without security realm parameter passes OpenEJB as a security realm. That security realm is not configured anywhere (as far as I can tell) and therefore if that method is called the authentication will always fail. The second GeronimoSecurityService.login() function just calls ContextManager.login(). And it also does not perform null check of the security realm. I guess we could add the default security realm there but it won't address 1) if there is another path to ContextManager.login(). Default security relam name in ContextManager - Key: GERONIMO-3581 URL: https://issues.apache.org/jira/browse/GERONIMO-3581 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Jarek Gawor ContextManager.login() should use a default security realm name if user did not pass a security realm. Null security realm will cause an exception in LoginContext. Right now becuase of this issue, a standalone ejb client must set a custom property (openejb.authentication.realmName) in order for authentication to succeed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[ANNOUNCE] Kevan Miller has been approved as the new PMC Chair for Apache Geronimo
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
Re: svn commit: r612439 [1/2] - in /geronimo/server/trunk: assemblies/geronimo-jetty6-javaee5/ assemblies/geronimo-tomcat6-javaee5/ plugins/clustering/ plugins/clustering/clustering/ plugins/clusterin
On 17/01/2008, at 1:30 AM, Kevan Miller wrote: On Jan 16, 2008, at 7:48 AM, [EMAIL PROTECTED] wrote: Author: gdamour Date: Wed Jan 16 04:48:37 2008 New Revision: 612439 URL: http://svn.apache.org/viewvc?rev=612439view=rev Log: Move farm related classes to new sub-project geronimo-farm. Add a new configuration farming and move farming related GBeans from the clustering config. to this new one. Also, by default this configuration is not started. Cool. Gianny, can you give us a bit of status about where you are with this? Looks like you're laying some groundwork for OpenEJB dependencies... Hi, David J. proposed a while back two clustering code/module rearrangements he was keen to have implemented before 2.1. With this commit, both of these rearrangements are now in. I am now integration testing the OpenEJB clustering support and it appears I will need to do some minor adjustments. As part of the change, four sub-projects/dependencies are added: geronimo-openejb- clustering-wadi, geronimo-openejb-clustering-builder-wadi, openejb- clustering-wadi and openejb-clustering-builder-wadi. This structure mirrors the Jetty and Tomcat ones. I also think 2.1 is belated and should be cut as soon as possible. I will hold-on the OpenEJB commit till the creation of a 2.1 branch. Thanks, Gianny Enhanced clustering support is really great to have. Want to understand what additional dependencies this is going to require. I think we're overdue for a 2.1 release. We have polish and a number of usability issues to work out in current trunk, prior to this. However, worried about also pushing in a bunch of new function is going to make this difficult... --kevan
Re: [ANNOUNCE] Kevan Miller has been approved as the new PMC Chair for Apache Geronimo
On Jan 16, 2008, at 3:10 PM, Matt Hogstrom 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, You're leaving some big shoes to fill. You've done a great job the past 14 months. Thanks! Now about those performance numbers... ;-) --kevan
[jira] Created: (GERONIMO-3754) Username/password is ignored in PluginInstallerGBean
Username/password is ignored in PluginInstallerGBean Key: GERONIMO-3754 URL: https://issues.apache.org/jira/browse/GERONIMO-3754 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: general Affects Versions: 2.1 Reporter: Jarek Gawor The username/password is ignored in PluginInstallerGBean in listPlugins() function. That means, for example, that with plugin installer portlet I'm unable to see the plugins from http://localhost:8080/plugin/maven-repo/ repo as it requires basic authentication. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3754) Username/password is ignored in PluginInstallerGBean
[ https://issues.apache.org/jira/browse/GERONIMO-3754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-3754: -- Attachment: GERONIMO-3754.patch Proposed patch for this issue. Username/password is ignored in PluginInstallerGBean Key: GERONIMO-3754 URL: https://issues.apache.org/jira/browse/GERONIMO-3754 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: general Affects Versions: 2.1 Reporter: Jarek Gawor Attachments: GERONIMO-3754.patch The username/password is ignored in PluginInstallerGBean in listPlugins() function. That means, for example, that with plugin installer portlet I'm unable to see the plugins from http://localhost:8080/plugin/maven-repo/ repo as it requires basic authentication. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3753) monitoring portlet is not up to date with dojo 1.0
[ https://issues.apache.org/jira/browse/GERONIMO-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3753: --- Attachment: geronimo-3753.patch monitoring portlet is not up to date with dojo 1.0 -- Key: GERONIMO-3753 URL: https://issues.apache.org/jira/browse/GERONIMO-3753 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Priority: Trivial Attachments: geronimo-3753.patch I noticed that when a user clicks on a Graph's name, the graph does not render correctly. I'm pretty sure it has something to do with the new version of dojo. So we need to update monitoringPopUpGraph.jsp to reflect the new version of dojo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3753) monitoring portlet is not up to date with dojo 1.0
[ https://issues.apache.org/jira/browse/GERONIMO-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3753: --- Patch Info: [Patch Available] monitoring portlet is not up to date with dojo 1.0 -- Key: GERONIMO-3753 URL: https://issues.apache.org/jira/browse/GERONIMO-3753 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Priority: Trivial Attachments: geronimo-3753.patch I noticed that when a user clicks on a Graph's name, the graph does not render correctly. I'm pretty sure it has something to do with the new version of dojo. So we need to update monitoringPopUpGraph.jsp to reflect the new version of dojo. -- 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
Thanks for your terrific service in this position Matt! Congratulations and thank you for stepping up to the plate Kevan! Joe Matt Hogstrom 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
Re: [ANNOUNCE] Kevan Miller has been approved as the new PMC Chair for Apache Geronimo
On Jan 16, 2008, at 12:10 PM, Matt Hogstrom 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. Thanks Matt for all the great work. Congrats Kevan! I know that you're going to make a great chair! Regards, Alan
Re: [ANNOUNCE] Kevan Miller has been approved as the new PMC Chair for Apache Geronimo
Congratulations Kevan. :) Sangjin On 1/16/08, Kevan Miller [EMAIL PROTECTED] wrote: On Jan 16, 2008, at 3:10 PM, Matt Hogstrom 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, You're leaving some big shoes to fill. You've done a great job the past 14 months. Thanks! Now about those performance numbers... ;-) --kevan
Re: [ANNOUNCE] Kevan Miller has been approved as the new PMC Chair for Apache Geronimo
Matt, Thanks for the great work you've done as the PMC Chair! Kevan, Congratulations on the new assignment! Cheers! Hernan Matt Hogstrom 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
Re: [ANNOUNCE] Kevan Miller has been approved as the new PMC Chair for Apache Geronimo
Thanx Matt. Congrats Kevan ! (the band is now playing *Hail to the Chief* ) Cheers Prasad On Jan 16, 2008 3:10 PM, 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
[jira] Closed: (GERONIMO-3752) JACC principal-role mapping installation is too tied to our policy implementation.
[ https://issues.apache.org/jira/browse/GERONIMO-3752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3752. -- Resolution: Fixed The patch needed some tweaks, a better version committed in rev 612602. JACC principal-role mapping installation is too tied to our policy implementation. -- Key: GERONIMO-3752 URL: https://issues.apache.org/jira/browse/GERONIMO-3752 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1 Attachments: GERONIMO-3752.patch We need a couple interfaces to avoid tying the installation of principal-role mapping to our specific jacc implementation. Someone else might want to use it with their jacc implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3754) Username/password is ignored in PluginInstallerGBean
[ https://issues.apache.org/jira/browse/GERONIMO-3754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-3754: -- Attachment: (was: GERONIMO-3754.patch) Username/password is ignored in PluginInstallerGBean Key: GERONIMO-3754 URL: https://issues.apache.org/jira/browse/GERONIMO-3754 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: general Affects Versions: 2.1 Reporter: Jarek Gawor Attachments: GERONIMO-3754.patch The username/password is ignored in PluginInstallerGBean in listPlugins() function. That means, for example, that with plugin installer portlet I'm unable to see the plugins from http://localhost:8080/plugin/maven-repo/ repo as it requires basic authentication. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3754) Username/password is ignored in PluginInstallerGBean
[ https://issues.apache.org/jira/browse/GERONIMO-3754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-3754: -- Attachment: GERONIMO-3754.patch Updated patch with a fix to validatePlugin() code that checks if a plugin is already installed. Before, the validatePlugin() was checking if a plugin was running and therefore, plugins that were not running but installed were considered installable. Username/password is ignored in PluginInstallerGBean Key: GERONIMO-3754 URL: https://issues.apache.org/jira/browse/GERONIMO-3754 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: general Affects Versions: 2.1 Reporter: Jarek Gawor Attachments: GERONIMO-3754.patch The username/password is ignored in PluginInstallerGBean in listPlugins() function. That means, for example, that with plugin installer portlet I'm unable to see the plugins from http://localhost:8080/plugin/maven-repo/ repo as it requires basic authentication. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r612439 [1/2] - in /geronimo/server/trunk: assemblies/geronimo-jetty6-javaee5/ assemblies/geronimo-tomcat6-javaee5/ plugins/clustering/ plugins/clustering/clustering/ plugins/clusterin
Thanks Gianny. More below... On Jan 16, 2008, at 3:42 PM, Gianny Damour wrote: On 17/01/2008, at 1:30 AM, Kevan Miller wrote: On Jan 16, 2008, at 7:48 AM, [EMAIL PROTECTED] wrote: Author: gdamour Date: Wed Jan 16 04:48:37 2008 New Revision: 612439 URL: http://svn.apache.org/viewvc?rev=612439view=rev Log: Move farm related classes to new sub-project geronimo-farm. Add a new configuration farming and move farming related GBeans from the clustering config. to this new one. Also, by default this configuration is not started. Cool. Gianny, can you give us a bit of status about where you are with this? Looks like you're laying some groundwork for OpenEJB dependencies... Hi, David J. proposed a while back two clustering code/module rearrangements he was keen to have implemented before 2.1. With this commit, both of these rearrangements are now in. Right. Although I haven't looked at the specifics, I think this split is a really good one. I am now integration testing the OpenEJB clustering support and it appears I will need to do some minor adjustments. As part of the change, four sub-projects/dependencies are added: geronimo-openejb- clustering-wadi, geronimo-openejb-clustering-builder-wadi, openejb- clustering-wadi and openejb-clustering-builder-wadi. This structure mirrors the Jetty and Tomcat ones. I also think 2.1 is belated and should be cut as soon as possible. I will hold-on the OpenEJB commit till the creation of a 2.1 branch. Cool. If this branch isn't for another week or two, is that going to ok for you? I think we want to avoid creating branches/2.1 and then merging a bunch of fit-and-finish fixes between the branch and trunk... --kevan Thanks, Gianny Enhanced clustering support is really great to have. Want to understand what additional dependencies this is going to require. I think we're overdue for a 2.1 release. We have polish and a number of usability issues to work out in current trunk, prior to this. However, worried about also pushing in a bunch of new function is going to make this difficult... --kevan
[YOKO] Yoko web site
I want to start creating the new Yoko website and wiki. How do I do this? Regards, Alan
[YOKO] KEYS
I have removed all the keys but Rick's from the KEYS file since I do not recognize who they belong to. Yoko committers, please feel free to add your keys to this file. Regards, Alan
Re: [YOKO] Yoko web site
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
[AsyncHttpClient] data collection instrumentation
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? 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. Thoughts? Suggestions? Thanks, Sangjin
[jira] Resolved: (GERONIMO-3753) monitoring portlet is not up to date with dojo 1.0
[ https://issues.apache.org/jira/browse/GERONIMO-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik B. Craig resolved GERONIMO-3753. - Resolution: Fixed Patch Committed revision 612698. Great joerb viet. monitoring portlet is not up to date with dojo 1.0 -- Key: GERONIMO-3753 URL: https://issues.apache.org/jira/browse/GERONIMO-3753 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Priority: Trivial Attachments: geronimo-3753.patch I noticed that when a user clicks on a Graph's name, the graph does not render correctly. I'm pretty sure it has something to do with the new version of dojo. So we need to update monitoringPopUpGraph.jsp to reflect the new version of dojo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (GERONIMO-3753) monitoring portlet is not up to date with dojo 1.0
[ https://issues.apache.org/jira/browse/GERONIMO-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik B. Craig reopened GERONIMO-3753: - monitoring portlet is not up to date with dojo 1.0 -- Key: GERONIMO-3753 URL: https://issues.apache.org/jira/browse/GERONIMO-3753 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Priority: Trivial Attachments: geronimo-3753.patch I noticed that when a user clicks on a Graph's name, the graph does not render correctly. I'm pretty sure it has something to do with the new version of dojo. So we need to update monitoringPopUpGraph.jsp to reflect the new version of dojo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3753) monitoring portlet is not up to date with dojo 1.0
[ https://issues.apache.org/jira/browse/GERONIMO-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen resolved GERONIMO-3753. Resolution: Fixed monitoring portlet is not up to date with dojo 1.0 -- Key: GERONIMO-3753 URL: https://issues.apache.org/jira/browse/GERONIMO-3753 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Priority: Trivial Attachments: geronimo-3753.patch I noticed that when a user clicks on a Graph's name, the graph does not render correctly. I'm pretty sure it has something to do with the new version of dojo. So we need to update monitoringPopUpGraph.jsp to reflect the new version of dojo. -- 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
Congrats Kevan Thanks Matt. On Jan 17, 2008 1:40 AM, 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 -- Thanks, Shiva
Re: [ANNOUNCE] Kevan Miller has been approved as the new PMC Chair for Apache Geronimo
Thanks Matt. And congratulations Kevan. ++Vamsi On Jan 17, 2008 1:40 AM, 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
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
[jira] Created: (GERONIMO-3755) application-1.2 schema does not exist
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: Start failed, Cannot load property editor [org.apache.xbean.propertyeditor.ArrayListEditor]
I got the similar error using the latest trunk build on Windows XP. I searched the org.apache.geronimo.configs/j2ee-system/2.1-SNAPSHOT/car ,org.apache.geronimo.configs/jee-specs/2.1-SNAPSHOT/car and org.apache.geronimo.configs/rmi-naming/2.1-SNAPSHOT/car configurations ( they are the parents of org.apache.geronimo.configs/plugin/2.1-SNAPSHOT/car), but didn't find they loaded org.apache.xbean/xbean-reflect/3.3-SNAPSHOT/jar which includes the class org.apache.xbean.propertyeditor.LinkedListEditor. Now I added org.apache.xbean/xbean-reflect/3.3-SNAPSHOT/jar to org.apache.geronimo.configs/j2ee-system/2.1-SNAPSHOT/car, the server can start up correctly. But I don't know if I'm missing anything, if not, I'll open a jira for this. Thanks a lot. -- Yun Feng Peter Petersson wrote: Yes thank you Jarek! As mentioned by Jarek the second attribute below is the offending one. It is added to the config by adding a repository. The question is where is my org.apache.xbean.propertyeditor.LinkedListEditor :) maybe it is fixed in newer builds I haven't got around checking it yet. thanks Peter P config.xml : module name=org.apache.geronimo.configs/plugin/2.1-SNAPSHOT/car gbean name=DownloadedPluginRepos attribute name=repositoryListhttp://geronimo.apache.org/plugins/plugin-repository-list-2.1.txt/attribute attribute propertyEditor=org.apache.xbean.propertyeditor.LinkedListEditor name=userRepositories[~/.m2/repository,file:/home/ppe/.m2/repository/]/attribute /gbean /module Jarek Gawor wrote: Peter, I also see the same problem on XP on second start up. But I was able to work around it by removing 'propertyEditor=org.apache.xbean.propertyeditor.LinkedListEditor' attribute from attribute/ element of DownloadedPluginRepos gbean. Hope this helps, Jarek On Jan 14, 2008 7:21 PM, Peter Petersson [EMAIL PROTECTED] wrote: In the men time I resorted to the assembly I pulled together yesterday and just doing a ./startup.sh; ./shutdown.sh; ../startup.sh fails on the second startup with the error indicated bellow. Its getting late here so I will look in to this again tomorrow hopefully with a fresh build. regards Peter Petersson Peter Petersson wrote: Things seems to be in a flux right now as I get a parse exception on 'geronimo-plugin-list' so I guess I have to wait with testing out plugins on a fresh build. I get back to you when this is out of the way. regards Peter P 23:44:02,710 INFO [PluginInstallerGBean] Attempting to download file:/home/ppe/.m2/repository/geronimo-plugins.xml 23:44:02,860 ERROR [PluginInstallerGBean] Unable to load repository configuration data org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'geronimo-plugin-list'. at org.apache.geronimo.system.plugin.PluginInstallerGBean$3.error(PluginInstallerGBean.java:1440) at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) Peter Petersson wrote: David Jencks wrote: I finally got around to applying your roller plugin patch but I can't reproduce this either on jetty or tomcat. I'm on osx I wonder if its due to the different os Nice :) hmmm well I am on Linux and Hernan got this on a Windows XP box and maybe osx is spared but there is clearly something wrong with my environment or else the server is getting into a faulty state due to the plugin modules I install (roller-tomcat, roller-themes) although I doubt the later is the case ;), I will try investigate this a bit more, will post my findings (if any) here but If you or anyone else have some suggestions or hints on what may cause this let me know. I will do a svn update; mvn clean install; and go make some coffee and try out the new build with different setups. regards Peter P thanks david jencks On Jan 14, 2008, at 2:28 AM, Peter Petersson wrote: Anyone still getting this? On the first startup the server starts fine but every following startup after a shutdown (or even reboot of comp) fails. I have had this problem for some time now (2 weeks I think) and to get around it I keep reinstalling the server but that's getting a bit boring :). This is happening for me on new builds of 2.1. The only thing I have done in between is installing the roller plugin. I have also tried startup with load=false in config.xml on the roller modules before startup (just in case the plugin would be causing the startup problem) but it dose not help. Any clues on what may causing this ? thanks Peter P 09:05:33,865 INFO [Log4jService] -- 09:05:33,865 INFO [Log4jService] Started Logging Service 09:05:33,865 INFO
Re: [YOKO] Yoko web site
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/ If you're looking to build something pretty big I've heard Confluence and Media Wiki work pretty well. The Media Wiki was the original package written for Wikipedia, so it's pretty robust. Smaller, simpler and cleaner solutions would be the Doku Wiki and PmWiki. Hopes this helps. the best, Joseph Leong On Jan 17, 2008 12:39 AM, Alan D. Cabrera [EMAIL PROTECTED] wrote: :) 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
[jira] Commented: (GERONIMO-3754) Username/password is ignored in PluginInstallerGBean
[ https://issues.apache.org/jira/browse/GERONIMO-3754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559818#action_12559818 ] David Jencks commented on GERONIMO-3754: the change to validatePlugin causes problems in assembly if a plugin is mentioned in an assembly but is already in whatever was unpacked (e.g. framework). I'm thinking about how to fix this, leaning towards ignoring requests to install plugins that are already installed. Username/password is ignored in PluginInstallerGBean Key: GERONIMO-3754 URL: https://issues.apache.org/jira/browse/GERONIMO-3754 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: general Affects Versions: 2.1 Reporter: Jarek Gawor Attachments: GERONIMO-3754.patch The username/password is ignored in PluginInstallerGBean in listPlugins() function. That means, for example, that with plugin installer portlet I'm unable to see the plugins from http://localhost:8080/plugin/maven-repo/ repo as it requires basic authentication. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3754) Username/password is ignored in PluginInstallerGBean
[ https://issues.apache.org/jira/browse/GERONIMO-3754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559824#action_12559824 ] Jarek Gawor commented on GERONIMO-3754: --- Ok, but except that change, the patch looks good to you (wasn't sure about the api changes)? Also, I just committed a basic console test that should check the plugin portlet for listing the plugins (revision 612725). Username/password is ignored in PluginInstallerGBean Key: GERONIMO-3754 URL: https://issues.apache.org/jira/browse/GERONIMO-3754 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: general Affects Versions: 2.1 Reporter: Jarek Gawor Attachments: GERONIMO-3754.patch The username/password is ignored in PluginInstallerGBean in listPlugins() function. That means, for example, that with plugin installer portlet I'm unable to see the plugins from http://localhost:8080/plugin/maven-repo/ repo as it requires basic authentication. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [YOKO] Yoko web site
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: svn commit: r612439 [1/2] - in /geronimo/server/trunk: assemblies/geronimo-jetty6-javaee5/ assemblies/geronimo-tomcat6-javaee5/ plugins/clustering/ plugins/clustering/clustering/ plugins/clusterin
On 17/01/2008, at 9:01 AM, Kevan Miller wrote: I am now integration testing the OpenEJB clustering support and it appears I will need to do some minor adjustments. As part of the change, four sub-projects/dependencies are added: geronimo-openejb- clustering-wadi, geronimo-openejb-clustering-builder-wadi, openejb- clustering-wadi and openejb-clustering-builder-wadi. This structure mirrors the Jetty and Tomcat ones. I also think 2.1 is belated and should be cut as soon as possible. I will hold-on the OpenEJB commit till the creation of a 2.1 branch. Cool. If this branch isn't for another week or two, is that going to ok for you? I think we want to avoid creating branches/2.1 and then merging a bunch of fit-and-finish fixes between the branch and trunk... No worries. Also I agree it is quite a pain to port change sets from branches to trunk. Thanks, Gianny
[YOKO] premature tools deletion?
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] Closed: (GERONIMO-3754) Username/password is ignored in PluginInstallerGBean
[ https://issues.apache.org/jira/browse/GERONIMO-3754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3754. -- Resolution: Fixed Fix Version/s: 2.1 Assignee: David Jencks I applied the patch in rev 612745 after fixing up the problems with trying to install already-present plugins. The downloadPoller now shows info about plugins that weren't installed: we should show it in the gshell output at least. Username/password is ignored in PluginInstallerGBean Key: GERONIMO-3754 URL: https://issues.apache.org/jira/browse/GERONIMO-3754 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: general Affects Versions: 2.1 Reporter: Jarek Gawor Assignee: David Jencks Fix For: 2.1 Attachments: GERONIMO-3754.patch The username/password is ignored in PluginInstallerGBean in listPlugins() function. That means, for example, that with plugin installer portlet I'm unable to see the plugins from http://localhost:8080/plugin/maven-repo/ repo as it requires basic authentication. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
