[BUILD] 2.0: Failed for Revision: 603843
Geronimo Revision: 603843 built with tests included See the full build-0200.log file at http://people.apache.org/~prasad/binaries/2.0/20071213/build-0200.log Download the binaries from http://people.apache.org/~prasad/binaries/2.0/20071213 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 29 minutes 34 seconds [INFO] Finished at: Thu Dec 13 02:38:56 EST 2007 [INFO] Final Memory: 267M/852M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/~prasad/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/~prasad/binaries/2.0/20071213/logs-0200-tomcat/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 160.751 sec FAILURE! Assembly: jetty = See the full test.log file at http://people.apache.org/~prasad/binaries/2.0/20071213/logs-0200-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 155.742 sec FAILURE!
[jira] Commented: (GERONIMO-3703) should allow custom SSL context for AsyncHttpClient
[ https://issues.apache.org/jira/browse/GERONIMO-3703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551451 ] Rick McGuire commented on GERONIMO-3703: I think using a default context is probably a good idea. Most people don't know how to set up a default SSLContext, and I suspect for many uses, the current default would work just fine. I suspect you're correct though, that attaching it to the HttpRequestMessage makes a lot of sense. 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 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.
[BUILD] 2.1: Failed for Revision: 603850
OpenEJB trunk at 603843 Geronimo Revision: 603850 built with tests included See the full build-0300.log file at http://people.apache.org/~prasad/binaries/trunk/20071213/build-0300.log Download the binaries from http://people.apache.org/~prasad/binaries/trunk/20071213 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 30 minutes 55 seconds [INFO] Finished at: Thu Dec 13 03:38:01 EST 2007 [INFO] Final Memory: 296M/577M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/~prasad/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/~prasad/binaries/trunk/20071213/logs-0300-tomcat/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 54.365 sec FAILURE! Assembly: jetty = See the full test.log file at http://people.apache.org/~prasad/binaries/trunk/20071213/logs-0300-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 57.495 sec FAILURE!
[jira] Commented: (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:comment-tabpanel#action_12551464 ] Rick McGuire commented on GERONIMO-3638: I'm not sure I understand the rationale for using US-ASCII as the default. If I'm interpreting the snippet for RFC 3986 correctly, UTF-8 should be the only encoding used for transforming the textual data into a URL encoding. This is essentially a 2-stage process. 1) encode the characters in bytes using UTF-8 as the target encoding. 2) Interpret those bytes as if they were an 8-bit ASCII encoding and perform the URL encoding on that. Since every character in the US-ASCII character set would encode exactly the same way using UTF-8 as the converson target, that encoding is contained within the new standard. I guess the only reason for allowing the charset to be specified would if the target of the message is known not to support RFC 3986. But in that case, it wouldn't make sense to try to send those characters in the first place, since they wouldn't encode correctly. So changing the encoding at best provide a safety measure to ensure incorrect encoding are not sent. The provided patch does a very nice job of implementing the proposed behavior. I'm not yet convinced the proposed behavior is the correct one. 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 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] Resolved: (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 resolved GERONIMO-3703. Resolution: Fixed Committed revision 603885. I've committed this patch, but there's something going on here with the connection reuse that's nagging at me a little, but I can't convince myself there's a real problem. SSL context is provided by the request, and if there is no SSLFilter on the connection, one is added. At first glance, it seems like there is an exposure to either A) reusing a connection that is filtering with an incorrect SSLContext from a previous request or B) reusing a connection with an SSLFilter in place for a non-http connection. I don't think either of these could ever happen, given the realities of how SSL connections are used. I think the only thing that raised the issue was the test for whether the connection already had an SSLFilter in place or not. At that point, it seemed things could go astray, but I guess if the connection is getting reused, then the characteristics are fixed anyway. 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 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.
Re: structure of GShell commands
If GShell would be targeted at more servers than G then I think these commands should be under geronimo. If not, then I think a flat structure makes sense. On Dec 11, 2007, at 10:04 AM, Kevan Miller wrote: We currently have the following structure for Geronimo GShell commands: geronimo/ start-server stop-server start-client deploy/ install-library disconnect deploy ... This doesn't make much sense to me. Let's either assume GShell is used for Geronimo server or assume that GShell can be used for multiple target environments, but not both... I think the current deploy/ commands should be under the geronimo tree. What do others think? I think applying a bit more structure, now, will minimize entropy over time... Anybody want to have a shot at proposing a command structure? --kevan
Monitoring console deadlock
I was running monitoring console on G(portoffset=10) and the agent
on default G instance. I saw this trace on the screen at a later time.
So I can not describe what exactly I was doing.. This can probably be
fixed by ordering the sql operations correctly.
Thanks
Anita
14:48:27,968 ERROR [SnapshotDBHelper] A lock could not be obtained due
to a dead
lock, cycle of locks and waiters is:
Lock : ROW, SYSCOLUMNS, (4,17)
Waiting XID : {691, S} , MONITOR, INSERT INTO Statistics
(snapshot_time, stats
ValueList, mbeanId) VALUES
(119747609,'23209078,30091640,34628360,32094576',
5)
Granted XID : {693, X}
Lock : ROW, STATISTICS, (4,7)
Waiting XID : {693, S} , MONITOR, SELECT DISTINCT snapshot_time FROM
Statistic
s WHERE snapshot_time 1194896887609
Granted XID : {691, X}
. The selected victim is XID : 691.
ERROR 40001: A lock could not be obtained due to a deadlock, cycle of
locks and
waiters is:
Lock : ROW, SYSCOLUMNS, (4,17)
Waiting XID : {691, S} , MONITOR, INSERT INTO Statistics
(snapshot_time, stats
ValueList, mbeanId) VALUES
(119747609,'23209078,30091640,34628360,32094576',
5)
Granted XID : {693, X}
Lock : ROW, STATISTICS, (4,7)
Waiting XID : {693, S} , MONITOR, SELECT DISTINCT snapshot_time FROM
Statistic
s WHERE snapshot_time 1194896887609
Granted XID : {691, X}
. The selected victim is XID : 691.
at
org.apache.derby.iapi.error.StandardException.newException(Unknown So
urce)
at
org.apache.derby.impl.services.locks.Deadlock.buildException(Unknown
Source)
at
org.apache.derby.impl.services.locks.LockSet.lockObject(Unknown Sourc
e)
at
org.apache.derby.impl.services.locks.SinglePool.lockAnObject(Unknown
Source)
at
org.apache.derby.impl.services.locks.SinglePool.lockObject(Unknown So
urce)
at
org.apache.derby.impl.store.raw.xact.RowLocking3.lockRecordForRead(Un
known Source)
at
org.apache.derby.impl.store.access.heap.HeapController.lockRow(Unknow
n Source)
at
org.apache.derby.impl.store.access.heap.HeapController.lockRow(Unknow
n Source)
at
org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.lockRow
OnPage(Unknown Source)
at
org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockSc
anRow(Unknown Source)
at
org.apache.derby.impl.store.access.btree.index.B2IRowLockingRR.lockSc
anRow(Unknown Source)
at
org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(U
nknown Source)
at
org.apache.derby.impl.store.access.btree.BTreeScan.fetchNext(Unknown
Source)
at
org.apache.derby.impl.sql.catalog.TabInfoImpl.getRowInternal(Unknown
Source)
at
org.apache.derby.impl.sql.catalog.TabInfoImpl.getRowLocation(Unknown
Source)
at
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.computeRowLocati
on(Unknown Source)
at
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.computeAutoincRo
wLocations(Unknown Source)
at org.apache.derby.impl.sql.compile.InsertNode.bind(Unknown
Source)
at
org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown
Source)
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepa
reInternalStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown
Source)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(Unknown Sourc
e)
at
org.tranql.connector.jdbc.StatementHandle.executeUpdate(StatementHand
le.java:166)
at
org.apache.geronimo.monitor.snapshot.SnapshotDBHelper.addSnapshotToDB
(SnapshotDBHelper.java:229)
at
org.apache.geronimo.monitor.snapshot.SnapshotProcessor.takeSnapshot(S
napshotProcessor.java:79)
at
org.apache.geronimo.monitor.MasterRemoteControl.handleTimeout(MasterR
emoteControl.java:205)
at sun.reflect.GeneratedMethodAccessor385.invoke(Unknown
Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invoc
ation.invoke(ReflectionInvocationContext.java:146)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext.proce
ed(ReflectionInvocationContext.java:129)
at
org.apache.openejb.core.interceptor.InterceptorStack.invoke(Intercept
orStack.java:67)
at
org.apache.openejb.core.stateless.StatelessContainer._invoke(Stateles
sContainer.java:203)
at
org.apache.openejb.core.stateless.StatelessContainer.invoke(Stateless
Container.java:165)
at
org.apache.openejb.core.timer.EjbTimerServiceImpl.ejbTimeout(EjbTimer
ServiceImpl.java:284)
at
org.apache.openejb.core.timer.EjbTimerServiceImpl.access$100(EjbTimer
ServiceImpl.java:43)
at
org.apache.openejb.core.timer.EjbTimerServiceImpl$EjbTimeoutTimerTask
$1.run(EjbTimerServiceImpl.java:350)
at
[jira] Closed: (GERONIMO-3704) Convert the activation and javamail dependencies to non-snapshot versions.
[ https://issues.apache.org/jira/browse/GERONIMO-3704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-3704. -- Resolution: Fixed Committed revision 603928. Convert the activation and javamail dependencies to non-snapshot versions. -- Key: GERONIMO-3704 URL: https://issues.apache.org/jira/browse/GERONIMO-3704 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: mail Affects Versions: 2.1 Reporter: Rick McGuire Assignee: Rick McGuire Fix For: 2.1 There are new published released of the geronimo-activation spec and the javamail uber jar. The current snapshot dependencies should be upgraded to the released versions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3704) Convert the activation and javamail dependencies to non-snapshot versions.
Convert the activation and javamail dependencies to non-snapshot versions. -- Key: GERONIMO-3704 URL: https://issues.apache.org/jira/browse/GERONIMO-3704 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Components: mail Affects Versions: 2.1 Reporter: Rick McGuire Assignee: Rick McGuire Fix For: 2.1 There are new published released of the geronimo-activation spec and the javamail uber jar. The current snapshot dependencies should be upgraded to the released versions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] 2.0: Failed for Revision: 603911
Geronimo Revision: 603911 built with tests included See the full build-0800.log file at http://people.apache.org/~prasad/binaries/2.0/20071213/build-0800.log Download the binaries from http://people.apache.org/~prasad/binaries/2.0/20071213 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 26 minutes 53 seconds [INFO] Finished at: Thu Dec 13 08:40:42 EST 2007 [INFO] Final Memory: 266M/863M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/~prasad/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/~prasad/binaries/2.0/20071213/logs-0800-tomcat/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 160.314 sec FAILURE! Assembly: jetty = See the full test.log file at http://people.apache.org/~prasad/binaries/2.0/20071213/logs-0800-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 156.885 sec FAILURE!
[BUILD] 2.1: Failed for Revision: 603921
OpenEJB trunk at 603914 Geronimo Revision: 603921 built with tests included See the full build-0900.log file at http://people.apache.org/~prasad/binaries/trunk/20071213/build-0900.log Download the binaries from http://people.apache.org/~prasad/binaries/trunk/20071213 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 35 minutes 32 seconds [INFO] Finished at: Thu Dec 13 09:50:12 EST 2007 [INFO] Final Memory: 278M/1015M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/~prasad/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/~prasad/binaries/trunk/20071213/logs-0900-tomcat/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 56.188 sec FAILURE! Assembly: jetty = See the full test.log file at http://people.apache.org/~prasad/binaries/trunk/20071213/logs-0900-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 58.092 sec FAILURE!
Re: Do Plugins need Prerequisites?
On Dec 12, 2007 8:27 PM, David Jencks [EMAIL PROTECTED] wrote: I must be missing something... how does the prerequisite system work better than dependencies here? I'm not 100% sure of what currently happens when you try to install a plugin that has an unavailable dependency, but it certainly won't start even if its downloaded. Originally I think, the plugin would refuse to download and install. The idea was that if something was a dependency it was more or less guaranteed to be available, whereas a prerequisite pretty much always required manual intervention (except for Jetty/Tomcat, which I mention below). Dependencies and prerequisites could be combined, but my concern would be how to clearly convey the directions for what the user needs to do to get get plugin to work. Like, if a plugin has 20 dependencies, and one of them is something that the user has to manually deal with, how do you emphasize to the user that in order to install the plugin, they need to take that action? If it's just in the dependency description, it seems like it would be lost among the 20 dependencies... Unless we have some logic to detect which dependencies can't be installed and emphasize those somehow. I really want to avoid the case where you identify the perfect plugin, install it, and then confusingly, it's not running afterward. You go to start it, and it won't start, perhaps with a confusing error (Dependency foo wasn't installed? Why not? I thought this was supposed to be automatic? Crappy product!) Again, so long as the user experience is good, the plumbing doesn't matter so much. I guess the other usage was to ensure you didn't install both Jetty and Tomcat in the same environment. As in, you have the Tomcat stack, and you accidentally click a web app built against Jetty, we don't want it to automatically download and install Jetty (because, among other things, if the default ports conflict the server won't start, and web app deployments suddenly get a lot more confusing if the wrong engine handles it). Also, it would be really unexpected that you click a web app plugin link, and suddenly it's installing a new Web server. So I'm not sure we want Jetty or Tomcat to appear as normal dependencies of a web app. Strike that, I'm pretty sure we don't want it, unless web app deployments change to be web-container-neutral so it would only install a Web container if one wasn't already there. Thanks, Aaron On Dec 12, 2007 6:33 PM, David Jencks [EMAIL PROTECTED] wrote: Aaron included a prerequisite feature for plugin metadata which is supposed to prevent you from installing a plugin if some prerequisite plugin is missing. After some thought I can't think of a reason this would possibly be useful or more useful than a dependency, where the needed plugin is simply installed for you. I disabled this functionality but forgot to discuss this point, but now that Jarek has re-enabled it I think it's time for a discussion. I do think there is some use for some feature that e.g. prevents installing jetty if tomcat is present, but I don't think prerequisites implement that in any useful way. comments? thanks david jencks
Re: Do Plugins need Prerequisites?
Thanks Aaron for the thorough explanation. I agree that the prereq relationship provides useful information and functionality beyond what the dependency relationship provides. The plugins portlet in the admin console will currently inspect the prerequisites for the plugins listed in a remote catalog and will designate any plugins that have missing prerequisites as being not compatible with the server. (Incompatible server or JVM versions are handled the same way.) I think that designation is useful as it prompts the user to inspect the plugin's properties to get further details on what steps they might need to take to prepare or reconfigure their server -- e.g. manually create a db pool, replace a conflicting component, etc. I also think the prereq relationship is especially useful because webapp plugins are not compatible between tomcat and jetty assemblies, and like you say we don't want the plugin installer to automatically install a second web container into an assembly if the user picks the wrong plugin. Best wishes, Paul On Dec 13, 2007, at 1:21 PM, Aaron Mulder wrote: On Dec 12, 2007 8:27 PM, David Jencks [EMAIL PROTECTED] wrote: I must be missing something... how does the prerequisite system work better than dependencies here? I'm not 100% sure of what currently happens when you try to install a plugin that has an unavailable dependency, but it certainly won't start even if its downloaded. Originally I think, the plugin would refuse to download and install. The idea was that if something was a dependency it was more or less guaranteed to be available, whereas a prerequisite pretty much always required manual intervention (except for Jetty/Tomcat, which I mention below). Dependencies and prerequisites could be combined, but my concern would be how to clearly convey the directions for what the user needs to do to get get plugin to work. Like, if a plugin has 20 dependencies, and one of them is something that the user has to manually deal with, how do you emphasize to the user that in order to install the plugin, they need to take that action? If it's just in the dependency description, it seems like it would be lost among the 20 dependencies... Unless we have some logic to detect which dependencies can't be installed and emphasize those somehow. I really want to avoid the case where you identify the perfect plugin, install it, and then confusingly, it's not running afterward. You go to start it, and it won't start, perhaps with a confusing error (Dependency foo wasn't installed? Why not? I thought this was supposed to be automatic? Crappy product!) Again, so long as the user experience is good, the plumbing doesn't matter so much. I guess the other usage was to ensure you didn't install both Jetty and Tomcat in the same environment. As in, you have the Tomcat stack, and you accidentally click a web app built against Jetty, we don't want it to automatically download and install Jetty (because, among other things, if the default ports conflict the server won't start, and web app deployments suddenly get a lot more confusing if the wrong engine handles it). Also, it would be really unexpected that you click a web app plugin link, and suddenly it's installing a new Web server. So I'm not sure we want Jetty or Tomcat to appear as normal dependencies of a web app. Strike that, I'm pretty sure we don't want it, unless web app deployments change to be web-container-neutral so it would only install a Web container if one wasn't already there. Thanks, Aaron On Dec 12, 2007 6:33 PM, David Jencks [EMAIL PROTECTED] wrote: Aaron included a prerequisite feature for plugin metadata which is supposed to prevent you from installing a plugin if some prerequisite plugin is missing. After some thought I can't think of a reason this would possibly be useful or more useful than a dependency, where the needed plugin is simply installed for you. I disabled this functionality but forgot to discuss this point, but now that Jarek has re-enabled it I think it's time for a discussion. I do think there is some use for some feature that e.g. prevents installing jetty if tomcat is present, but I don't think prerequisites implement that in any useful way. comments? thanks david jencks
[jira] Commented: (GERONIMO-3703) should allow custom SSL context for AsyncHttpClient
[ https://issues.apache.org/jira/browse/GERONIMO-3703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551589 ] Sangjin Lee commented on GERONIMO-3703: --- It should be OK, because sessions are reused for the specific host and port. The only case where it might get interesting is TLS where the same socket can be used both for http and https. However, I think the SSL filter is then constructed with TLS and the underlying SSLSocketFactory and SSLEngine would be TLS aware. So I suspect it would be OK. We might need to develop unit tests around TLS to test it vigorously in general. 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 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] Updated: (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 ] Sangjin Lee updated GERONIMO-3703: -- Attachment: test.patch added a unit test that tests connection reuse with SSL sockets 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] Commented: (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:comment-tabpanel#action_12551592 ] Sangjin Lee commented on GERONIMO-3638: --- Yes, I agree the default for URL encoding should be UTF-8. I also agree the only case where anything other than UTF-8 could be used is to interact with a server that may not be handling it properly and thus the client *has* to use a different custom encoding. I am changing the default URL encoding value to UTF-8, but proposing keeping an option of setting the charset. I added an ample warning in the javadoc not to ... try this at home. :) I'll upload a revised patch shortly... 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 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] Updated: (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 ] Sangjin Lee updated GERONIMO-3638: -- Attachment: (was: 3638.patch) 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 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] Updated: (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 ] Sangjin Lee updated GERONIMO-3638: -- Attachment: 3638.patch a revised patch 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 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.
A few Questions
Hi, I am trying to add a few custom entries into the app specific JNDI space. Is it possible to get a handle to the componentContext during the deployment of a J2EE app so that it can be modified. It becomes immutable after the application starts as per the spec so i need to do it during deployment. A ModuleBuilderExtension looks like a good way but I will need to add new extensions to the existing J2EE builders. Can I do this programatically? Regards Manu
[jira] Commented: (GERONIMO-3703) should allow custom SSL context for AsyncHttpClient
[ https://issues.apache.org/jira/browse/GERONIMO-3703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551600 ] Rick McGuire commented on GERONIMO-3703: Good test to add. Thanks! Committed revision 604016. 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] Resolved: (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 resolved GERONIMO-3638. Resolution: Fixed Assignee: Rick McGuire Committed revision 604018. This last patch looks like it is the correct way to manage these encodings. Thanks for sticking with this one. 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.
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Joe Bohn wrote: It looks like the size of our images is increasing dramatically (nearly 2x). For example, the geronimo-jetty6-minimal snapshots have been growing like this (these image sizes are from the snapshot repo): 16604006 Jul 26 18:54 geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.tar.gz 17086729 Jul 26 18:53 geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.zip 22310769 Nov 1 03:19 geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.tar.gz 22744083 Nov 1 03:18 geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.zip 30812531 Nov 30 22:45 geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.tar.gz 31248864 Nov 30 22:43 geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.zip The javaee5 images have also grown significantly. 57099671 Jul 26 18:39 geronimo-jetty6-jee5-2.1-20070726.182538-1-bin.tar.gz 58685668 Jul 26 18:36 geronimo-jetty6-jee5-2.1-20070726.182538-1-bin.zip 55113050 Nov 1 03:28 geronimo-jetty6-javaee5-2.1-20071101.014839-1-bin.tar.gz 56827820 Nov 1 03:25 geronimo-jetty6-javaee5-2.1-20071101.014839-1-bin.zip 71313050 Nov 30 22:54 geronimo-jetty6-javaee5-2.1-20071130.211933-2-bin.tar.gz 73094816 Nov 30 22:50 geronimo-jetty6-javaee5-2.1-20071130.211933-2-bin.zip Here are the latest image sizes from a build this morning (12/13/07 svn rev. 603936). While it appears that things have slightly improved, there isn't a substantial difference from earlier (esp. in the minimal assemblies). 23492694 Dec 13 15:15 geronimo-framework-2.1-SNAPSHOT-bin.zip 23187538 Dec 13 15:15 geronimo-framework-2.1-SNAPSHOT-bin.tar.gz 29732445 Dec 13 15:15 geronimo-jetty6-minimal-2.1-SNAPSHOT-bin.tar.gz 30216770 Dec 13 15:15 geronimo-jetty6-minimal-2.1-SNAPSHOT-bin.zip 31206202 Dec 13 15:16 geronimo-tomcat6-minimal-2.1-SNAPSHOT-bin.tar.gz 31695270 Dec 13 15:16 geronimo-tomcat6-minimal-2.1-SNAPSHOT-bin.zip 68474964 Dec 13 15:15 geronimo-jetty6-javaee5-2.1-SNAPSHOT-bin.tar.gz 70303613 Dec 13 15:16 geronimo-jetty6-javaee5-2.1-SNAPSHOT-bin.zip 69713173 Dec 13 15:17 geronimo-tomcat6-javaee5-2.1-SNAPSHOT-bin.tar.gz 71559684 Dec 13 15:17 geronimo-tomcat6-javaee5-2.1-SNAPSHOT-bin.zip As you can see, the framework itself is now larger than the minimal assemblies used to be. Some of the growth in the framework assembly (I'm not intending to imply that these should or should not included in framework ... just pointing out the new additions to framework): - boilerplate minimal assembly (3.6M) - ant (1.2M) - G-Shell (1.5M) - yoko (1.8M) - groovy (2.4M) - plexus (.5M) - woodstox (.5M) - cglib (.33M) - xstream (.36M) - mina (.33M) That accounts for nearly all of the growth since 2.0.2. Joe
[jira] Assigned: (GSHELL-20) `set foo=bar` does not work as expected
[
https://issues.apache.org/jira/browse/GSHELL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Dillon reassigned GSHELL-20:
--
Assignee: Jason Dillon (was: Jason Warner)
`set foo=bar` does not work as expected
-
Key: GSHELL-20
URL: https://issues.apache.org/jira/browse/GSHELL-20
Project: GShell
Issue Type: Bug
Security Level: public(Regular issues)
Components: Commands, Core
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
Assignee: Jason Dillon
Priority: Critical
Fix For: 1.0-alpha-1
Attachments: GShell-20.patch, GShell-20SingleQuote.patch
Due to the way parsing happens, this line:
{noformat}
set foo=bar
{noformat}
Ends up calling the command with 2 arguments: foo= and bar, which is not
what the command expects, which is one argument of: foo=bar
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-20) `set foo=bar` does not work as expected
[
https://issues.apache.org/jira/browse/GSHELL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Dillon updated GSHELL-20:
---
Affects Version/s: (was: 0.0.1)
1.0-alpha-1
Fix Version/s: (was: 1.0-alpha-2)
1.0-alpha-1
I will put this bandaid on for this release :-)
`set foo=bar` does not work as expected
-
Key: GSHELL-20
URL: https://issues.apache.org/jira/browse/GSHELL-20
Project: GShell
Issue Type: Bug
Security Level: public(Regular issues)
Components: Commands, Core
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
Assignee: Jason Dillon
Priority: Critical
Fix For: 1.0-alpha-1
Attachments: GShell-20.patch, GShell-20SingleQuote.patch
Due to the way parsing happens, this line:
{noformat}
set foo=bar
{noformat}
Ends up calling the command with 2 arguments: foo= and bar, which is not
what the command expects, which is one argument of: foo=bar
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GSHELL-20) `set foo=bar` does not work as expected
[
https://issues.apache.org/jira/browse/GSHELL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Dillon closed GSHELL-20.
--
Resolution: Fixed
Thanks :-)
`set foo=bar` does not work as expected
-
Key: GSHELL-20
URL: https://issues.apache.org/jira/browse/GSHELL-20
Project: GShell
Issue Type: Bug
Security Level: public(Regular issues)
Components: Commands, Core
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
Assignee: Jason Dillon
Priority: Critical
Fix For: 1.0-alpha-1
Attachments: GShell-20.patch, GShell-20SingleQuote.patch
Due to the way parsing happens, this line:
{noformat}
set foo=bar
{noformat}
Ends up calling the command with 2 arguments: foo= and bar, which is not
what the command expects, which is one argument of: foo=bar
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Do Plugins need Prerequisites?
OK, so I agree the prereq feature is useful so I'll stop trying to remove it :-) However I ***really*** don't think it should be used for assuring the correct web server. I want to being install a plugin such as the web console and have it install the web server as a dependency. To me this is an obvious use of the dependency facility. I think we need some other kind of constraint such as only one plugin of type X to handle the wrong web server problem. I don't think its a big enough immediate problem that we need it for 2.1. thanks david jencks On Dec 13, 2007, at 11:38 AM, Paul McMahan wrote: Thanks Aaron for the thorough explanation. I agree that the prereq relationship provides useful information and functionality beyond what the dependency relationship provides. The plugins portlet in the admin console will currently inspect the prerequisites for the plugins listed in a remote catalog and will designate any plugins that have missing prerequisites as being not compatible with the server. (Incompatible server or JVM versions are handled the same way.) I think that designation is useful as it prompts the user to inspect the plugin's properties to get further details on what steps they might need to take to prepare or reconfigure their server -- e.g. manually create a db pool, replace a conflicting component, etc. I also think the prereq relationship is especially useful because webapp plugins are not compatible between tomcat and jetty assemblies, and like you say we don't want the plugin installer to automatically install a second web container into an assembly if the user picks the wrong plugin. Best wishes, Paul On Dec 13, 2007, at 1:21 PM, Aaron Mulder wrote: On Dec 12, 2007 8:27 PM, David Jencks [EMAIL PROTECTED] wrote: I must be missing something... how does the prerequisite system work better than dependencies here? I'm not 100% sure of what currently happens when you try to install a plugin that has an unavailable dependency, but it certainly won't start even if its downloaded. Originally I think, the plugin would refuse to download and install. The idea was that if something was a dependency it was more or less guaranteed to be available, whereas a prerequisite pretty much always required manual intervention (except for Jetty/Tomcat, which I mention below). Dependencies and prerequisites could be combined, but my concern would be how to clearly convey the directions for what the user needs to do to get get plugin to work. Like, if a plugin has 20 dependencies, and one of them is something that the user has to manually deal with, how do you emphasize to the user that in order to install the plugin, they need to take that action? If it's just in the dependency description, it seems like it would be lost among the 20 dependencies... Unless we have some logic to detect which dependencies can't be installed and emphasize those somehow. I really want to avoid the case where you identify the perfect plugin, install it, and then confusingly, it's not running afterward. You go to start it, and it won't start, perhaps with a confusing error (Dependency foo wasn't installed? Why not? I thought this was supposed to be automatic? Crappy product!) Again, so long as the user experience is good, the plumbing doesn't matter so much. I guess the other usage was to ensure you didn't install both Jetty and Tomcat in the same environment. As in, you have the Tomcat stack, and you accidentally click a web app built against Jetty, we don't want it to automatically download and install Jetty (because, among other things, if the default ports conflict the server won't start, and web app deployments suddenly get a lot more confusing if the wrong engine handles it). Also, it would be really unexpected that you click a web app plugin link, and suddenly it's installing a new Web server. So I'm not sure we want Jetty or Tomcat to appear as normal dependencies of a web app. Strike that, I'm pretty sure we don't want it, unless web app deployments change to be web-container-neutral so it would only install a Web container if one wasn't already there. Thanks, Aaron On Dec 12, 2007 6:33 PM, David Jencks [EMAIL PROTECTED] wrote: Aaron included a prerequisite feature for plugin metadata which is supposed to prevent you from installing a plugin if some prerequisite plugin is missing. After some thought I can't think of a reason this would possibly be useful or more useful than a dependency, where the needed plugin is simply installed for you. I disabled this functionality but forgot to discuss this point, but now that Jarek has re-enabled it I think it's time for a discussion. I do think there is some use for some feature that e.g. prevents installing jetty if tomcat is present, but I don't think prerequisites implement that in any useful way. comments? thanks david jencks
Fewer gbean proxies on the horizon
A really long time ago Dain made the server work without gbean proxies in gbean references, but we didn't enable this by default because it broke the admin console. While waiting for a build I had a look and think I've fixed the admin console it still seems to work. I expect to commit this in the next day or two. thanks david jencks
Re: Do Plugins need Prerequisites?
I will just conclude by saying it's not my feeling that we currently have the best possible solution -- I just want to make sure things don't move backward. It would be possible to provide special handling for Tomcat/Jetty at the level of JVM versions and take that issue out of the picture. It would be possible to have the logic that inspects plugin metadata draw out unavailable dependencies for particular attention. (Plugin X. Status: cannot be installed without first installing: 1) Configuration 'Oracle JDBC Driver' 2) Configuration 'DB Pool for Plugin X' Note: This may require manual installation and/or configuration.) Then maybe the prerequisites as such could go away. But for example, I'm not sure if the logic that currently lists plugin status will actually query the plugin repositories for dependencies when rendering the status -- it might make that operation slower and more annoying if it had to calculate what was available in order to tell you what the prerequisites were. That was supposed to be easier when the whole world switched over to Archiva with fancy indexing for the Maven repositories, but as far as I know that hasn't happened yet. :) Thanks, Aaron P.S. I believe you can currently arrange for a web server to be a regular dependency instead of a prerequisite if you really want to -- you just have to figure out what to do when a second one is to be installed by accident. On Dec 13, 2007 2:38 PM, Paul McMahan [EMAIL PROTECTED] wrote: Thanks Aaron for the thorough explanation. I agree that the prereq relationship provides useful information and functionality beyond what the dependency relationship provides. The plugins portlet in the admin console will currently inspect the prerequisites for the plugins listed in a remote catalog and will designate any plugins that have missing prerequisites as being not compatible with the server. (Incompatible server or JVM versions are handled the same way.) I think that designation is useful as it prompts the user to inspect the plugin's properties to get further details on what steps they might need to take to prepare or reconfigure their server -- e.g. manually create a db pool, replace a conflicting component, etc. I also think the prereq relationship is especially useful because webapp plugins are not compatible between tomcat and jetty assemblies, and like you say we don't want the plugin installer to automatically install a second web container into an assembly if the user picks the wrong plugin. Best wishes, Paul On Dec 13, 2007, at 1:21 PM, Aaron Mulder wrote: On Dec 12, 2007 8:27 PM, David Jencks [EMAIL PROTECTED] wrote: I must be missing something... how does the prerequisite system work better than dependencies here? I'm not 100% sure of what currently happens when you try to install a plugin that has an unavailable dependency, but it certainly won't start even if its downloaded. Originally I think, the plugin would refuse to download and install. The idea was that if something was a dependency it was more or less guaranteed to be available, whereas a prerequisite pretty much always required manual intervention (except for Jetty/Tomcat, which I mention below). Dependencies and prerequisites could be combined, but my concern would be how to clearly convey the directions for what the user needs to do to get get plugin to work. Like, if a plugin has 20 dependencies, and one of them is something that the user has to manually deal with, how do you emphasize to the user that in order to install the plugin, they need to take that action? If it's just in the dependency description, it seems like it would be lost among the 20 dependencies... Unless we have some logic to detect which dependencies can't be installed and emphasize those somehow. I really want to avoid the case where you identify the perfect plugin, install it, and then confusingly, it's not running afterward. You go to start it, and it won't start, perhaps with a confusing error (Dependency foo wasn't installed? Why not? I thought this was supposed to be automatic? Crappy product!) Again, so long as the user experience is good, the plumbing doesn't matter so much. I guess the other usage was to ensure you didn't install both Jetty and Tomcat in the same environment. As in, you have the Tomcat stack, and you accidentally click a web app built against Jetty, we don't want it to automatically download and install Jetty (because, among other things, if the default ports conflict the server won't start, and web app deployments suddenly get a lot more confusing if the wrong engine handles it). Also, it would be really unexpected that you click a web app plugin link, and suddenly it's installing a new Web server. So I'm not sure we want Jetty or Tomcat to appear as normal dependencies of a web app. Strike that, I'm pretty sure we don't want it, unless web app
Re: Fewer gbean proxies on the horizon
Wow! Either you're pretty sharp or you really need a faster machine! :) I think the main issue was that the console expected to be able to cast GBean references to some helper interface in order to start and stop individual GBeans and get a GBean's name and things like that. And the proxies provided implementations of that interface that the plain GBean references did not. I think we made wide use of that before realizing that it might be desirable to eliminate it. Was the workaround just to call kernel methods to get the GBean name and start and stop instead? Thanks, Aaron On Dec 13, 2007 6:15 PM, David Jencks [EMAIL PROTECTED] wrote: A really long time ago Dain made the server work without gbean proxies in gbean references, but we didn't enable this by default because it broke the admin console. While waiting for a build I had a look and think I've fixed the admin console it still seems to work. I expect to commit this in the next day or two. thanks david jencks
Re: Fewer gbean proxies on the horizon
On Dec 13, 2007, at 3:20 PM, Aaron Mulder wrote: Wow! Either you're pretty sharp or you really need a faster machine! :) or the solution was really simple :-) I think the main issue was that the console expected to be able to cast GBean references to some helper interface in order to start and stop individual GBeans and get a GBean's name and things like that. And the proxies provided implementations of that interface that the plain GBean references did not. I think we made wide use of that before realizing that it might be desirable to eliminate it. That's the only need for proxies I'm aware of. Was the workaround just to call kernel methods to get the GBean name and start and stop instead? What I did was in the KernelManagementHelper class get a proxy for anything we return, so the console could continue to use that proxy to use the geronimo management interface. If there are other ways of getting gbeans that need the management interface in the console I haven't fixed them and someone will find that something is broken. thanks david jencks Thanks, Aaron On Dec 13, 2007 6:15 PM, David Jencks [EMAIL PROTECTED] wrote: A really long time ago Dain made the server work without gbean proxies in gbean references, but we didn't enable this by default because it broke the admin console. While waiting for a build I had a look and think I've fixed the admin console it still seems to work. I expect to commit this in the next day or two. thanks david jencks
Re: [VOTE] Release Genesis 1.3
On Dec 11, 2007, at 4:58 AM, Jason Dillon wrote: Folks, a small change to Genesis was made to support a custom legal resource bundle for the GShell release. I'd like to get this out so we can get GShell out too. +1 -Release it +0 -Eh, whatever -1 -Um, no no no no no... +1 --kevan
Re: Fewer gbean proxies on the horizon
On Dec 13, 2007, at 6:15 PM, David Jencks wrote: A really long time ago Dain made the server work without gbean proxies in gbean references, but we didn't enable this by default because it broke the admin console. While waiting for a build I had a look and think I've fixed the admin console it still seems to work. I expect to commit this in the next day or two. Wahoo! That would be great. Would be good to get some TCK tests started with the NoProxy. This would give us a heads up on any looming problems... --kevan
Re: svn commit: r604053 - /geronimo/server/trunk/pom.xml
Jason, Can you give a reason for this change? I might have to update a few machines. Thanks, Jarek On Dec 13, 2007 5:41 PM, [EMAIL PROTECTED] wrote: Author: jdillon Date: Thu Dec 13 14:41:50 2007 New Revision: 604053 URL: http://svn.apache.org/viewvc?rev=604053view=rev Log: Require Maven 2.0.7 for now Modified: geronimo/server/trunk/pom.xml Modified: geronimo/server/trunk/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml?rev=604053r1=604052r2=604053view=diff == --- geronimo/server/trunk/pom.xml (original) +++ geronimo/server/trunk/pom.xml Thu Dec 13 14:41:50 2007 @@ -2095,9 +2095,9 @@ version[1.5,1.6)/version /requireJavaVersion -!-- Allow any Maven = 2.0.5 -- +!-- Require Maven 2.0.7 -- requireMavenVersion -version[2.0.5,)/version +version[2.0.7]/version /requireMavenVersion /rules /configuration
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
We can remove some of the gshell bloat by not using the gshell- embedable jar which contains xstream, jexl, log4j-diet, jline and some other bits which are already in the repository. Might drop things down by 1 or 2m. Also we can make a diet version of groovy and ant, containing on the bits which are needed. Might drop another meg or 2. The mina stuff... um, that might be because of the remote shell stuff? That probably shouldn't be included... --jason On Dec 13, 2007, at 1:03 PM, Joe Bohn wrote: Joe Bohn wrote: It looks like the size of our images is increasing dramatically (nearly 2x). For example, the geronimo-jetty6-minimal snapshots have been growing like this (these image sizes are from the snapshot repo): 16604006 Jul 26 18:54 geronimo-jetty6-minimal-2.1-20070726.182538-1- bin.tar.gz 17086729 Jul 26 18:53 geronimo-jetty6-minimal-2.1-20070726.182538-1- bin.zip 22310769 Nov 1 03:19 geronimo-jetty6-minimal-2.1-20071101.014839-2- bin.tar.gz 22744083 Nov 1 03:18 geronimo-jetty6-minimal-2.1-20071101.014839-2- bin.zip 30812531 Nov 30 22:45 geronimo-jetty6-minimal-2.1-20071130.211933-3- bin.tar.gz 31248864 Nov 30 22:43 geronimo-jetty6-minimal-2.1-20071130.211933-3- bin.zip The javaee5 images have also grown significantly. 57099671 Jul 26 18:39 geronimo-jetty6-jee5-2.1-20070726.182538-1- bin.tar.gz 58685668 Jul 26 18:36 geronimo-jetty6-jee5-2.1-20070726.182538-1- bin.zip 55113050 Nov 1 03:28 geronimo-jetty6-javaee5-2.1-20071101.014839-1- bin.tar.gz 56827820 Nov 1 03:25 geronimo-jetty6-javaee5-2.1-20071101.014839-1- bin.zip 71313050 Nov 30 22:54 geronimo-jetty6-javaee5-2.1-20071130.211933-2- bin.tar.gz 73094816 Nov 30 22:50 geronimo-jetty6-javaee5-2.1-20071130.211933-2- bin.zip Here are the latest image sizes from a build this morning (12/13/07 svn rev. 603936). While it appears that things have slightly improved, there isn't a substantial difference from earlier (esp. in the minimal assemblies). 23492694 Dec 13 15:15 geronimo-framework-2.1-SNAPSHOT-bin.zip 23187538 Dec 13 15:15 geronimo-framework-2.1-SNAPSHOT-bin.tar.gz 29732445 Dec 13 15:15 geronimo-jetty6-minimal-2.1-SNAPSHOT-bin.tar.gz 30216770 Dec 13 15:15 geronimo-jetty6-minimal-2.1-SNAPSHOT-bin.zip 31206202 Dec 13 15:16 geronimo-tomcat6-minimal-2.1-SNAPSHOT-bin.tar.gz 31695270 Dec 13 15:16 geronimo-tomcat6-minimal-2.1-SNAPSHOT-bin.zip 68474964 Dec 13 15:15 geronimo-jetty6-javaee5-2.1-SNAPSHOT-bin.tar.gz 70303613 Dec 13 15:16 geronimo-jetty6-javaee5-2.1-SNAPSHOT-bin.zip 69713173 Dec 13 15:17 geronimo-tomcat6-javaee5-2.1-SNAPSHOT-bin.tar.gz 71559684 Dec 13 15:17 geronimo-tomcat6-javaee5-2.1-SNAPSHOT-bin.zip As you can see, the framework itself is now larger than the minimal assemblies used to be. Some of the growth in the framework assembly (I'm not intending to imply that these should or should not included in framework ... just pointing out the new additions to framework): - boilerplate minimal assembly (3.6M) - ant (1.2M) - G-Shell (1.5M) - yoko (1.8M) - groovy (2.4M) - plexus (.5M) - woodstox (.5M) - cglib (.33M) - xstream (.36M) - mina (.33M) That accounts for nearly all of the growth since 2.0.2. Joe
Re: svn commit: r604053 - /geronimo/server/trunk/pom.xml
Aye. --jason On Dec 13, 2007, at 5:13 PM, Jay D. McHugh wrote: I believe that the build will crash if you use Maven 2.0.8 That is probably why Jason forced the maven version. Jay Jarek Gawor wrote: Jason, Can you give a reason for this change? I might have to update a few machines. Thanks, Jarek On Dec 13, 2007 5:41 PM, [EMAIL PROTECTED] wrote: Author: jdillon Date: Thu Dec 13 14:41:50 2007 New Revision: 604053 URL: http://svn.apache.org/viewvc?rev=604053view=rev Log: Require Maven 2.0.7 for now Modified: geronimo/server/trunk/pom.xml Modified: geronimo/server/trunk/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml?rev=604053r1=604052r2=604053view=diff = = = = = = = = = = --- geronimo/server/trunk/pom.xml (original) +++ geronimo/server/trunk/pom.xml Thu Dec 13 14:41:50 2007 @@ -2095,9 +2095,9 @@ version[1.5,1.6)/version /requireJavaVersion -!-- Allow any Maven = 2.0.5 -- +!-- Require Maven 2.0.7 -- requireMavenVersion -version[2.0.5,)/version +version[2.0.7]/version /requireMavenVersion /rules /configuration
Re: svn commit: r604053 - /geronimo/server/trunk/pom.xml
I believe that the build will crash if you use Maven 2.0.8 That is probably why Jason forced the maven version. Jay Jarek Gawor wrote: Jason, Can you give a reason for this change? I might have to update a few machines. Thanks, Jarek On Dec 13, 2007 5:41 PM, [EMAIL PROTECTED] wrote: Author: jdillon Date: Thu Dec 13 14:41:50 2007 New Revision: 604053 URL: http://svn.apache.org/viewvc?rev=604053view=rev Log: Require Maven 2.0.7 for now Modified: geronimo/server/trunk/pom.xml Modified: geronimo/server/trunk/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml?rev=604053r1=604052r2=604053view=diff == --- geronimo/server/trunk/pom.xml (original) +++ geronimo/server/trunk/pom.xml Thu Dec 13 14:41:50 2007 @@ -2095,9 +2095,9 @@ version[1.5,1.6)/version /requireJavaVersion -!-- Allow any Maven = 2.0.5 -- +!-- Require Maven 2.0.7 -- requireMavenVersion -version[2.0.5,)/version +version[2.0.7]/version /requireMavenVersion /rules /configuration
Re: svn commit: r604053 - /geronimo/server/trunk/pom.xml
Ok, sure but doesn't that cut off 2.0.5 and 2.0.6 users? Jarek On Dec 13, 2007 8:28 PM, Jason Dillon [EMAIL PROTECTED] wrote: Aye. --jason On Dec 13, 2007, at 5:13 PM, Jay D. McHugh wrote: I believe that the build will crash if you use Maven 2.0.8 That is probably why Jason forced the maven version. Jay Jarek Gawor wrote: Jason, Can you give a reason for this change? I might have to update a few machines. Thanks, Jarek On Dec 13, 2007 5:41 PM, [EMAIL PROTECTED] wrote: Author: jdillon Date: Thu Dec 13 14:41:50 2007 New Revision: 604053 URL: http://svn.apache.org/viewvc?rev=604053view=rev Log: Require Maven 2.0.7 for now Modified: geronimo/server/trunk/pom.xml Modified: geronimo/server/trunk/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml?rev=604053r1=604052r2=604053view=diff = = = = = = = = = = --- geronimo/server/trunk/pom.xml (original) +++ geronimo/server/trunk/pom.xml Thu Dec 13 14:41:50 2007 @@ -2095,9 +2095,9 @@ version[1.5,1.6)/version /requireJavaVersion -!-- Allow any Maven = 2.0.5 -- +!-- Require Maven 2.0.7 -- requireMavenVersion -version[2.0.5,)/version +version[2.0.7]/version /requireMavenVersion /rules /configuration
Re: svn commit: r604053 - /geronimo/server/trunk/pom.xml
I suppose 2.0.6 should work. We can include that. --jason -Original Message- From: Jarek Gawor [EMAIL PROTECTED] Date: Thu, 13 Dec 2007 20:49:10 To:dev@geronimo.apache.org Subject: Re: svn commit: r604053 - /geronimo/server/trunk/pom.xml Ok, sure but doesn't that cut off 2.0.5 and 2.0.6 users? Jarek On Dec 13, 2007 8:28 PM, Jason Dillon [EMAIL PROTECTED] wrote: Aye. --jason On Dec 13, 2007, at 5:13 PM, Jay D. McHugh wrote: I believe that the build will crash if you use Maven 2.0.8 That is probably why Jason forced the maven version. Jay Jarek Gawor wrote: Jason, Can you give a reason for this change? I might have to update a few machines. Thanks, Jarek On Dec 13, 2007 5:41 PM, [EMAIL PROTECTED] wrote: Author: jdillon Date: Thu Dec 13 14:41:50 2007 New Revision: 604053 URL: http://svn.apache.org/viewvc?rev=604053view=rev Log: Require Maven 2.0.7 for now Modified: geronimo/server/trunk/pom.xml Modified: geronimo/server/trunk/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml?rev=604053r1=604052r2=604053view=diff = = = = = = = = = = --- geronimo/server/trunk/pom.xml (original) +++ geronimo/server/trunk/pom.xml Thu Dec 13 14:41:50 2007 @@ -2095,9 +2095,9 @@ version[1.5,1.6)/version /requireJavaVersion -!-- Allow any Maven = 2.0.5 -- +!-- Require Maven 2.0.7 -- requireMavenVersion -version[2.0.5,)/version +version[2.0.7]/version /requireMavenVersion /rules /configuration
[jira] Commented: (GSHELL-97) License and Notice info for gshell-embeddable
[ https://issues.apache.org/jira/browse/GSHELL-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551671 ] Jason Dillon commented on GSHELL-97: Usage of the shade plugin is making this more of a pain to use a static or even m-r-r-p generated license/notice... will fix, but probs have to do some custom ant or groovy muck to get the right bits in there. License and Notice info for gshell-embeddable - Key: GSHELL-97 URL: https://issues.apache.org/jira/browse/GSHELL-97 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Components: Build Affects Versions: 1.0-alpha-1 Reporter: Kevan Miller Assignee: Jason Dillon Fix For: 1.0-alpha-1 Attachments: embeddableLicense.txt, embeddableNotice.txt gshell-embeddable needs to License and Notice files to be included in the jar file. I'm not sure how to add these when using the shade plugin. Hoping Jason D can lend a hand. Will attach the license and notice files to this jira. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3705) Maven 2.0.8 causes build problems
Maven 2.0.8 causes build problems - Key: GERONIMO-3705 URL: https://issues.apache.org/jira/browse/GERONIMO-3705 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: buildsystem Affects Versions: 2.1 Reporter: Jason Dillon Assignee: Jason Dillon Priority: Critical -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
