[jira] Created: (AMQ-716) message is read from queue but not removed
message is read from queue but not removed -- Key: AMQ-716 URL: https://issues.apache.org/activemq/browse/AMQ-716 Project: ActiveMQ Type: Bug Components: Message Store Versions: 4.0 Environment: ActiveMQ Release (08.05.2006) BM Blade JS20 AIX 5.3 DB2 DataBase 8.2 Driver 2.5.33 Configuration: jdbcPersistenceAdapter class=org.activemq.store.jdbc.adapter.DefaultJDBCAdapter dataSource= #db2-ds/ bean id=db2datasource class=org.apache.commons.dbcp.BasicDataSource property name=driverClassName value=com.ibm.db2.jcc.DB2Driver/ property name=url value=URL/ property name=username value=USER/ property name=password value=PASS/ /bean Reporter: klaus terjung Producer send a message with a non transacted Session Testing a Consumer with a non transacted Session to receive Messages the Message is read but not removed. Testing a Consumer with a transacted Session and commit the Message is read and not removed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-434) Create test suite to ensure that servicemix respect the WS-i standar (see www:ws=i.org)
Create test suite to ensure that servicemix respect the WS-i standar (see www:ws=i.org) --- Key: SM-434 URL: https://issues.apache.org/activemq/browse/SM-434 Project: ServiceMix Type: Improvement Components: servicemix-http Versions: 3.0 Environment: Any Reporter: Eric Dofonsou We need to make a test suite to ensure that servicemix-http component is compliant to the WS-i standard this will ensure that web service exposed by JBi can interoperate with a much broader set of ws client technologies (C#, C++ etc...) WS-i web site : http://www.ws-i.org. I think WS-i has a testing kit available for download. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Issues Closed: week of 05-19-2006
Project: Apache Geronimo Status: Resolved, Closed (25 items) Updated In Last: Week (7 days) ** Bug * [GERONIMO-2034] [deployment] ensure output streams are closed in finally blocks * [GERONIMO-2035] [system] ensure input and output streams are closed in finally blocks * [GERONIMO-1997] Not possible to account for startup time in --long startup output due to configurations showing 0s * [GERONIMO-2032] [console] Some input and output streams are not closed in finally blocks * [GERONIMO-2033] [axis] ensure input streams are closed in finally blocks * [GERONIMO-1443] The hot deployer should accept plan-only deployments just like the online deployer * [GERONIMO-1929] Enable web apps exposed on separate ports * [GERONIMO-1981] Web Connector has GBean=(container name) in AbstractName * [GERONIMO-1402] Recipients set by calling MimeMessage.setRecipients(RecipientType, Adress[]) not remembered by getAllRecipients() * [GERONIMO-1958] Handle incomplete plugin downloads * [GERONIMO-2000] PluginInstallerGBean generates invalid geronimo-plugin.xml files * [GERONIMO-1900] Sample app links on welcome app are broken by default * [GERONIMO-1936] WAR deployed with configId with no type isn't treated as WAR by deploy tool, is by console * [GERONIMO-1569] improve packaging plugin control of logging. * [GERONIMO-1934] Incomplete dependency resolution assumes JAR as type * [GERONIMO-1212] Timeouts in commons-fileupload * [GERONIMO-1756] Move from 1.1-dev version of commons-fileupload to version 1.1 * [GERONIMO-2012] Reflect configuration - module change in config.xml * [GERONIMO-1822] Connector builder doesn't check consistency of transaction settings ** Improvement * [GERONIMO-2029] Plugins cannot install files outside repository * [GERONIMO-944] Bundle a JavaMail implementation SMTP provider * [GERONIMO-2022] New printed Book available - patch for documentation page attached * [GERONIMO-2018] Change temporary system proerty flags to start with X * [GERONIMO-2021] backport the activemq-embedded-rar from trunk to 1.1
Re: Geronimo 1.1 still dependent on Java 1.4.2?
On May 18, 2006, at 11:50 AM, [EMAIL PROTECTED] wrote: Dear Developers, I'm updating the Quick Start guide for Geronimo 1.1 (http://opensource.atlassian.com/confluence/oss/display/GERONIMO/ Geronimo+v1.1+-+Quick+start+-+Apache+Geronimo+for+the+impatient). Does Geronimo 1.1 out of the box still depend on Java 1.4.2? G does not depend on 1.4.2. You get some error messages when starting with 1.5.0, but that's due to the Daytrader app which is bundled with G. Also, CORBA support only works with 1.4.2, but that's not a G dependency IMO.
Re: Multiple Server Configurations
I've added a new skeleton document, Geronimo v1.1 - Multiple Server Configurations (http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+v1.1+-+Multiple+Server+Configurations) to the Confluence Wiki if someone more knowledgable (*cough* Hernan *cough*) wants to flesh out the content. Ian It's better to be hated for who you are than loved for who you are not Ian D. Stewart Appl Dev Analyst-Advisory, DCS Automation JPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Pager: (888) 260-0078 Aaron Mulder [EMAIL PROTECTED]To: Geronimo Dev dev@geronimo.apache.org nceton.edu cc: Sent by:Subject: Multiple Server Configurations [EMAIL PROTECTED] 05/18/2006 04:53 PM Please respond to dev All, David Jencks just backported a feature that lets you create multiple server configurations inside a single Geronimo installation. This affects the contents of the var/ directory, if I understand it right. So essentially, you could create a structure like this: geronimo/var/... (default configuration) geronimo/server1/var/... (server1 configuration) geronimo/another/var/... (another configuration) In other words, you can create subdirectories with their own copies of var/* and then tell Geronimo during startup to read from foo/var/* instead of var/* using a command-line parameter. I'd like to propose one change to this, and that is, that we eliminate the var directory and set it up one of these two ways -- the difference being whether the default server configuration is named something like default or named var: Option 1: default configuration named var: geronimo/var/... (default configuration) geronimo/server1/... (server1 configuration) geronimo/another/... (another configuration) Option 2: default configuration named e.g. default: geronimo/default/... (default configuration) geronimo/server1/... (server1 configuration) geronimo/another/... (another configuration) It seems somewhat more usable to me if, for example, the log directory is immediately underneath the server configuration directory. For anyone who's not real UNIX-oriented, I think it will be much nicer to look in the configuration directory and see config/ log/ security/ etc instead of just seeing var. Any thoughts on this? Thanks, Aaron
Re: Multiple Server Configurations
+1 to Matt's suggestion. I know that there are already users working on unstable builds of 1.1. While I think that they understand 1.1 isn't final yet ... we've already forced them to change a good many things. I think it would be nice to avoid any more for 1.1 so I'd vote for option #1. Joe Matt Hogstrom wrote: I'm fine for leaving the code in 1.1 to play with but I'm -1 in promoting it in 1.1. This should be a 1.2 item. One of the reasons we end up making disruptive changes later in the release is we don't have time to think this through and we'll be unhappy with the answer and end up tweaking it next time. That said, for 1.2 this is really needed as clustering will probably take shape. I'd prefer to start the discussion now and finish it in 1.2. Here's my 2c. geronimo/servers/default geronimo/servers/foo geronimo/servers/server1 geronimo/servers/server2 A major grouping off of Geronimo makes sense so we can group servers together. It would make sense to me to leave geronimo/var as the legacy, single server and the above as the clustered convention. Aaron Mulder wrote: All, David Jencks just backported a feature that lets you create multiple server configurations inside a single Geronimo installation. This affects the contents of the var/ directory, if I understand it right. So essentially, you could create a structure like this: geronimo/var/... (default configuration) geronimo/server1/var/... (server1 configuration) geronimo/another/var/... (another configuration) In other words, you can create subdirectories with their own copies of var/* and then tell Geronimo during startup to read from foo/var/* instead of var/* using a command-line parameter. I'd like to propose one change to this, and that is, that we eliminate the var directory and set it up one of these two ways -- the difference being whether the default server configuration is named something like default or named var: Option 1: default configuration named var: geronimo/var/... (default configuration) geronimo/server1/... (server1 configuration) geronimo/another/... (another configuration) Option 2: default configuration named e.g. default: geronimo/default/... (default configuration) geronimo/server1/... (server1 configuration) geronimo/another/... (another configuration) It seems somewhat more usable to me if, for example, the log directory is immediately underneath the server configuration directory. For anyone who's not real UNIX-oriented, I think it will be much nicer to look in the configuration directory and see config/ log/ security/ etc instead of just seeing var. Any thoughts on this? Thanks, Aaron -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Geronimo JEE 5 Status Page
Dear Developers, A user recently posed the following question on the Maven Users mailing list: By the way, is Glassfish the only open source application server implementing the whole JEE 5 right now? Is there a site we can point them to (preferably on geronimo.apache.org) that would highlight the current progress of Apache Geronimo towards JEE 5 compliance? Thanks, Ian It's better to be hated for who you are than loved for who you are not Ian D. Stewart Appl Dev Analyst-Advisory, DCS Automation JPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Pager: (888) 260-0078
Re: Multiple Server Configurations
My 2c is that I prefer Matt's idea of grouping the server specific directories beneath a servers directory. As a new user exploring the directory structure I would find that intuitive. But I'm hesitant to base my position solely on this empathetic gut feel because I'm wondering which parts of this discussion bump up against the clustering decisions for Geronimo 1.2, especially w.r.t. vertical clustering. Maybe this discussion will end up driving the clustering decisions, but maybe vice versa. My other 2c (making my contribution come to a grand total of 4 cents, wow!! can I go home now?) is that tomcat and jetty have already paved the way for at least part of this discussion. For example, in the tomcat 5.5.12 distribution there's a section of RUNNING.txt devoted to configuring multiple instances of tomcat. In the interest of making a transition from those environments go as smoothly as possible we should adopt any pieces of their approach that can fit. Best wishes, Paul p.s. my favorite bikeshed color is Blue. No, yello... :-) On 5/18/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I'm fine for leaving the code in 1.1 to play with but I'm -1 in promoting it in 1.1. This should be a 1.2 item. One of the reasons we end up making disruptive changes later in the release is we don't have time to think this through and we'll be unhappy with the answer and end up tweaking it next time. That said, for 1.2 this is really needed as clustering will probably take shape. I'd prefer to start the discussion now and finish it in 1.2. Here's my 2c. geronimo/servers/default geronimo/servers/foo geronimo/servers/server1 geronimo/servers/server2 A major grouping off of Geronimo makes sense so we can group servers together. It would make sense to me to leave geronimo/var as the legacy, single server and the above as the clustered convention. Aaron Mulder wrote: All, David Jencks just backported a feature that lets you create multiple server configurations inside a single Geronimo installation. This affects the contents of the var/ directory, if I understand it right. So essentially, you could create a structure like this: geronimo/var/... (default configuration) geronimo/server1/var/... (server1 configuration) geronimo/another/var/... (another configuration) In other words, you can create subdirectories with their own copies of var/* and then tell Geronimo during startup to read from foo/var/* instead of var/* using a command-line parameter. I'd like to propose one change to this, and that is, that we eliminate the var directory and set it up one of these two ways -- the difference being whether the default server configuration is named something like default or named var: Option 1: default configuration named var: geronimo/var/... (default configuration) geronimo/server1/... (server1 configuration) geronimo/another/... (another configuration) Option 2: default configuration named e.g. default: geronimo/default/... (default configuration) geronimo/server1/... (server1 configuration) geronimo/another/... (another configuration) It seems somewhat more usable to me if, for example, the log directory is immediately underneath the server configuration directory. For anyone who's not real UNIX-oriented, I think it will be much nicer to look in the configuration directory and see config/ log/ security/ etc instead of just seeing var. Any thoughts on this? Thanks, Aaron
[jira] Created: (GERONIMO-2041) Geronimo 1.3 Mail API : RFC EncodeText and DecodeText methods does nothing
Geronimo 1.3 Mail API : RFC EncodeText and DecodeText methods does nothing --- Key: GERONIMO-2041 URL: http://issues.apache.org/jira/browse/GERONIMO-2041 Project: Geronimo Type: Bug Security: public (Regular issues) Components: mail Versions: 1.x Environment: JavaMail API : geronimo-spec-javamail-1.3.1-rc5.jar Reporter: Laurent CELLA RFC2045 decoding / encoding does nothing. ( static methods decodeText( ... ), encodeText( ... ), decodeWord( ...), ... ). If I use an alternate JAR archive ( like mail-1.3.1.jar ) it is working. for instance sample is hé! àèôu !!! encodeText(sample, utf-8, Q ) should returns =?utf-8?Q?h=C3=A9!_=C3=A0=C3=A8=C3=B4u_!!!?= But it does nothing, without any exception thrown with Geronimo Spec Jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMODEVTOOLS-79) wtp adapter doesnt work with wtp 1.5rc1a
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-79?page=comments#action_12412529 ] Lin Sun commented on GERONIMODEVTOOLS-79: - This bug is reported to WTP 1.5, as a hot bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=141850 wtp adapter doesnt work with wtp 1.5rc1a Key: GERONIMODEVTOOLS-79 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-79 Project: Geronimo-Devtools Type: Bug Components: eclipse-plugin Versions: 1.0.0 Environment: windows xp x86 Reporter: Panagiotis Korros Priority: Critical The geronimo plugin 1.0 gives me this error when i try to publish a project using wtp 1.5rc1a. java.lang.NoSuchMethodError: org.eclipse.wst.common.frameworks.datamodel.IDataModel.getDefaultOperation()Lorg/eclipse/wst/common/frameworks/datamodel/IDataModelOperation; at org.apache.geronimo.core.DeploymentUtils.createJarFile(DeploymentUtils.java:73) at org.apache.geronimo.core.commands.DistributeCommand.execute(DistributeCommand.java:43) at org.apache.geronimo.core.commands.SynchronizedDeploymentOp.run(SynchronizedDeploymentOp.java:77) at org.apache.geronimo.core.commands.SynchronizedDeploymentOp.execute(SynchronizedDeploymentOp.java:69) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.distribute(GeronimoServerBehaviour.java:337) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doDeploy(GeronimoServerBehaviour.java:258) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.invokeCommand(GeronimoServerBehaviour.java:230) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.publishModule(GeronimoServerBehaviour.java:214) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:672) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourDelegate.java:752) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:610) at org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:800) at org.eclipse.wst.server.core.internal.Server.publish(Server.java:788) at org.eclipse.wst.server.core.internal.PublishServerJob.run(PublishServerJob.java:145) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Any updates on the Codehaus CVS/SVN outage?
Has anyone heard when the server problem affecting the Codehaus CVS and SVN repos will be fixed, so we can get outstanding patches applied to OpenEJB, TranQL, ActiveMQ, ... and generate versioned releases for 1.1? smime.p7s Description: S/MIME Cryptographic Signature
[jira] Assigned: (GERONIMO-2041) Geronimo 1.3 Mail API : RFC EncodeText and DecodeText methods does nothing
[ http://issues.apache.org/jira/browse/GERONIMO-2041?page=all ] Rick McGuire reassigned GERONIMO-2041: -- Assign To: Rick McGuire Geronimo 1.3 Mail API : RFC EncodeText and DecodeText methods does nothing --- Key: GERONIMO-2041 URL: http://issues.apache.org/jira/browse/GERONIMO-2041 Project: Geronimo Type: Bug Security: public(Regular issues) Components: mail Versions: 1.x Environment: JavaMail API : geronimo-spec-javamail-1.3.1-rc5.jar Reporter: Laurent CELLA Assignee: Rick McGuire RFC2045 decoding / encoding does nothing. ( static methods decodeText( ... ), encodeText( ... ), decodeWord( ...), ... ). If I use an alternate JAR archive ( like mail-1.3.1.jar ) it is working. for instance sample is hé! àèôu !!! encodeText(sample, utf-8, Q ) should returns =?utf-8?Q?h=C3=A9!_=C3=A0=C3=A8=C3=B4u_!!!?= But it does nothing, without any exception thrown with Geronimo Spec Jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Any updates on the Codehaus CVS/SVN outage?
On 5/19/06, Donald Woods [EMAIL PROTECTED] wrote: Has anyone heard when the server problem affecting the Codehaus CVS and SVN repos will be fixed, so we can get outstanding patches applied to OpenEJB, TranQL, ActiveMQ, ... and generate versioned releases for 1.1? See the following blog entries for status info: http://www.codehaus.org/status.html http://www.fnokd.com/2006/05/15/its-going-around/ Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://incubator.apache.org/activemq/ Apache ServiceMix - http://incubator.apache.org/servicemix/ Castor - http://castor.org/ smime.p7s Description: S/MIME cryptographic signature
[jira] Resolved: (GERONIMO-2041) Geronimo 1.3 Mail API : RFC EncodeText and DecodeText methods does nothing
[ http://issues.apache.org/jira/browse/GERONIMO-2041?page=all ] Rick McGuire resolved GERONIMO-2041: Fix Version: 1.1 Resolution: Fixed The javamail spec version shipping with Geronimo 1.0 was only a partial implementation, particularly with the MimeUtility class. The latest version in the geronimo-spec-javamail-1.3.1-rc6.jar has a proper implementation of encodeWord()/decodeWord() that should match the results from the Sun implementation. Geronimo 1.3 Mail API : RFC EncodeText and DecodeText methods does nothing --- Key: GERONIMO-2041 URL: http://issues.apache.org/jira/browse/GERONIMO-2041 Project: Geronimo Type: Bug Security: public(Regular issues) Components: mail Versions: 1.x Environment: JavaMail API : geronimo-spec-javamail-1.3.1-rc5.jar Reporter: Laurent CELLA Assignee: Rick McGuire Fix For: 1.1 RFC2045 decoding / encoding does nothing. ( static methods decodeText( ... ), encodeText( ... ), decodeWord( ...), ... ). If I use an alternate JAR archive ( like mail-1.3.1.jar ) it is working. for instance sample is hé! àèôu !!! encodeText(sample, utf-8, Q ) should returns =?utf-8?Q?h=C3=A9!_=C3=A0=C3=A8=C3=B4u_!!!?= But it does nothing, without any exception thrown with Geronimo Spec Jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Geronimo JEE 5 Status Page
I think we will be taking this further and have a more robust roadmap for Geronimo on the wiki that will track the direction and hopefully back that up with tracking JIRAs, so we can see where we are at. [EMAIL PROTECTED] wrote: Dear Developers, A user recently posed the following question on the Maven Users mailing list: By the way, is Glassfish the only open source application server implementing the whole JEE 5 right now? Is there a site we can point them to (preferably on geronimo.apache.org) that would highlight the current progress of Apache Geronimo towards JEE 5 compliance? Thanks, Ian It's better to be hated for who you are than loved for who you are not Ian D. Stewart Appl Dev Analyst-Advisory, DCS Automation JPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Pager: (888) 260-0078
[jira] Created: (GERONIMO-2042) ConfigurationAwareReference needs Serial Version UID
ConfigurationAwareReference needs Serial Version UID Key: GERONIMO-2042 URL: http://issues.apache.org/jira/browse/GERONIMO-2042 Project: Geronimo Type: Bug Security: public (Regular issues) Components: kernel Versions: 1.1 Reporter: Aaron Mulder Priority: Blocker Fix For: 1.1 Just had a plugin fail to install because the serial version of ConfigurationAwareReference didn't match. Needless to say we want to avoid problems causing plugins to fail to install on slightly newer Geroinmo platforms wherever possible. Maybe we should look at related code for missing UIDs while we're in there. Caused by: java.io.IOException: Unable to deserialize GBeanData geronimo/welcome-jetty/1.1-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=geronimo/welcome-jetty/1.1-SNAPSHOT/car, attribute: componentContext at org.apache.geronimo.gbean.GBeanData.readExternal(GBeanData.java:239) ... 64 more Caused by: java.io.InvalidClassException: org.apache.geronimo.naming.reference.ConfigurationAwareReference; local class incompatible: stream classdesc serialVersionUID = 7210513100515482358, local class serialVersionUID = 283358809226901462 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2011) Set default logging to INFO rather than DEBUG in minimal assemblies
[ http://issues.apache.org/jira/browse/GERONIMO-2011?page=all ] Matt Hogstrom closed GERONIMO-2011: --- Resolution: Fixed Sendingminimal-jetty-server/src/var/log/server-log4j.properties Sendingminimal-tomcat-server/src/var/log/server-log4j.properties Set default logging to INFO rather than DEBUG in minimal assemblies --- Key: GERONIMO-2011 URL: http://issues.apache.org/jira/browse/GERONIMO-2011 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: general Versions: 1.1 Environment: windows xp Reporter: Joe Bohn Assignee: Matt Hogstrom Fix For: 1.1 Attachments: 2011_LogLevel.patch The assemblies for j2ee-jetty-server and j2ee-tomcat-server have the default logging level set to INFO rather than Debug.The little-G assemblies (minimal-jetty-server minimal-tomcat-server) should have the same settings as we deliver the geronimo 1.1 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2011) Set default logging to INFO rather than DEBUG in minimal assemblies
[ http://issues.apache.org/jira/browse/GERONIMO-2011?page=comments#action_12412574 ] Matt Hogstrom commented on GERONIMO-2011: - Forgot the rev number for the commit. Sendingminimal-jetty-server/src/var/log/server-log4j.properties Sendingminimal-tomcat-server/src/var/log/server-log4j.properties Transmitting file data .. Committed revision 407880. Set default logging to INFO rather than DEBUG in minimal assemblies --- Key: GERONIMO-2011 URL: http://issues.apache.org/jira/browse/GERONIMO-2011 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: general Versions: 1.1 Environment: windows xp Reporter: Joe Bohn Assignee: Matt Hogstrom Fix For: 1.1 Attachments: 2011_LogLevel.patch The assemblies for j2ee-jetty-server and j2ee-tomcat-server have the default logging level set to INFO rather than Debug.The little-G assemblies (minimal-jetty-server minimal-tomcat-server) should have the same settings as we deliver the geronimo 1.1 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (GERONIMO-2011) Set default logging to INFO rather than DEBUG in minimal assemblies
Hi Matt, Will minimal-tomcat-server and minimal-jetty-server be available as binary distributions on the Geronimo Download Site (http://geronimo.apache.org/downloads.html) when 1.1 is released? Thanks, Ian It's better to be hated for who you are than loved for who you are not Ian D. Stewart Appl Dev Analyst-Advisory, DCS Automation JPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Pager: (888) 260-0078 Matt Hogstrom (JIRA) To: dev@geronimo.apache.org [EMAIL PROTECTED]cc: che.org Subject: [jira] Commented: (GERONIMO-2011) Set default logging to INFO rather than DEBUG in minimal assemblies 05/19/2006 02:41 PM Please respond to dev [ http://issues.apache.org/jira/browse/GERONIMO-2011?page=comments#action_12412574 ] Matt Hogstrom commented on GERONIMO-2011: - Forgot the rev number for the commit. Sendingminimal-jetty-server/src/var/log/server-log4j.properties Sendingminimal-tomcat-server/src/var/log/server-log4j.properties Transmitting file data .. Committed revision 407880. Set default logging to INFO rather than DEBUG in minimal assemblies --- Key: GERONIMO-2011 URL: http://issues.apache.org/jira/browse/GERONIMO-2011 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: general Versions: 1.1 Environment: windows xp Reporter: Joe Bohn Assignee: Matt Hogstrom Fix For: 1.1 Attachments: 2011_LogLevel.patch The assemblies for j2ee-jetty-server and j2ee-tomcat-server have the default logging level set to INFO rather than Debug.The little-G assemblies (minimal-jetty-server minimal-tomcat-server) should have the same settings as we deliver the geronimo 1.1 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMODEVTOOLS-55) Update build to use Eclipse 3.1.2 and EMF 2.1.2
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-55?page=comments#action_12412577 ] Donald Woods commented on GERONIMODEVTOOLS-55: -- The following platformURL no longer works, as the referenced location no longer exists on the Eclipse download site - http://download.eclipse.org/eclipse/downloads/drops/I20060329-0800/eclipse-SDK-I20060329-0800 The following should be used for the Eclipse 3.1.2 SDK - http://download.eclipse.org/eclipse/downloads/drops/R-3.1.2-200601181600/eclipse-SDK-3.1.2 Update build to use Eclipse 3.1.2 and EMF 2.1.2 --- Key: GERONIMODEVTOOLS-55 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-55 Project: Geronimo-Devtools Type: Bug Components: eclipse-plugin Environment: Eclipse 3.1 Reporter: Donald Woods Assignee: Sachin Patel Attachments: DevTools-55.patch, build20060320.patch Eclipse 3.1.2 and EMF 2.1.2 have been released. The following recent update - Revision: 373210 Author: sppatel Date: 1:41:36 PM, Saturday, January 28, 2006 Message: committers build uses WTP build M200601281544, which lists Eclipse 3.1.2 and EMF 2.1.2 as the prereqs to use this build level - http://download.eclipse.org/webtools/committers/drops/M-M200601281544-200601281544/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMODEVTOOLS-55) Update build to use Eclipse 3.1.2 SDK
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-55?page=all ] Donald Woods updated GERONIMODEVTOOLS-55: - Summary: Update build to use Eclipse 3.1.2 SDK (was: Update build to use Eclipse 3.1.2 and EMF 2.1.2) Environment: Maven 2.0.4 builds (was: Eclipse 3.1) Priority: Blocker (was: Major) This is blocking compiles for users with clean repos... Update build to use Eclipse 3.1.2 SDK - Key: GERONIMODEVTOOLS-55 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-55 Project: Geronimo-Devtools Type: Bug Components: eclipse-plugin Environment: Maven 2.0.4 builds Reporter: Donald Woods Assignee: Sachin Patel Priority: Blocker Attachments: DevTools-55.patch, build20060320.patch Eclipse 3.1.2 and EMF 2.1.2 have been released. The following recent update - Revision: 373210 Author: sppatel Date: 1:41:36 PM, Saturday, January 28, 2006 Message: committers build uses WTP build M200601281544, which lists Eclipse 3.1.2 and EMF 2.1.2 as the prereqs to use this build level - http://download.eclipse.org/webtools/committers/drops/M-M200601281544-200601281544/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2006) Deploying an application with an incorrect deployment plan results in non-functional admin console panel
[ http://issues.apache.org/jira/browse/GERONIMO-2006?page=all ] Paul McMahan updated GERONIMO-2006: --- Attachment: GERONIMO-2006.patch I was able to recreate the problem on tomcat. It is caused by a buffer overrun when render parameters that are set during the processAction phase are bigger than 8k. Since the error messages from the deployers are often larger than 8k the attached patch works around the buffer overrun by saving the message in the portlet session instead. The patch also looks for use of the configId attribute in the plan and if found uses the new upgrade utility to provide an upgraded version of the plan that the user can save locally as a starting point. In some cases (welcome app, jmx-debug app, etc) no further editing of the plan is required. The user can just save the updated plan for their 1.0 app and immediately deploy it again from the same portlet. The patch doesn't support upgrading plans that are embedded in the archive -- this is a bit more challenging but I think can be done. And finally, since error messages from the deployers are often very, very long and contains several stack traces this patch just shows the first line of the error message in the console (which is usually sufficient) and provides a button to show the full message if the user wants all the gory details. Deploying an application with an incorrect deployment plan results in non-functional admin console panel Key: GERONIMO-2006 URL: http://issues.apache.org/jira/browse/GERONIMO-2006 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment, console Versions: 1.1 Reporter: Dave Colasurdo Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 Attachments: GERONIMO-2006.patch, Myapp.war, badPlan.xml, badPlan2.xml, stackTrace.log Deploying myApp.war using badPlan.xml (both attached) results in a non-functioning Show Web App Wars panel. The console Deploy Applications panel reports application installed and started successfully. However, the application did not startup succesfully. The badPlan file is actually missing tcpListenerAddress=auto which causes TomcatReceiver Gbean to fail startup. I've attached the stacktrace to the JIRA. From then on, the Web App Wars console panel shows portlet error and there is no way to uninstall the bad application via the console. The server must be stopped and restarted in order to have the Web App War panel function correctly. The console should be able to report the true status of the deploy/start and recover from deploying a bad plan. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2006) Deploying an application with an incorrect deployment plan results in non-functional admin console panel
[ http://issues.apache.org/jira/browse/GERONIMO-2006?page=all ] Paul McMahan updated GERONIMO-2006: --- Attachment: deployment_portlet.jpg attaching screenshot of deployment portlet shown providing an upgraded plan Deploying an application with an incorrect deployment plan results in non-functional admin console panel Key: GERONIMO-2006 URL: http://issues.apache.org/jira/browse/GERONIMO-2006 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment, console Versions: 1.1 Reporter: Dave Colasurdo Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 Attachments: GERONIMO-2006.patch, Myapp.war, badPlan.xml, badPlan2.xml, deployment_portlet.jpg, stackTrace.log Deploying myApp.war using badPlan.xml (both attached) results in a non-functioning Show Web App Wars panel. The console Deploy Applications panel reports application installed and started successfully. However, the application did not startup succesfully. The badPlan file is actually missing tcpListenerAddress=auto which causes TomcatReceiver Gbean to fail startup. I've attached the stacktrace to the JIRA. From then on, the Web App Wars console panel shows portlet error and there is no way to uninstall the bad application via the console. The server must be stopped and restarted in order to have the Web App War panel function correctly. The console should be able to report the true status of the deploy/start and recover from deploying a bad plan. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Please try out the upgrade jar
On 5/12/06, Paul McMahan [EMAIL PROTECTED] wrote: Also, I think you (or someone) mentioned earlier that it might be useful to make this utility available from the admin console. Seems like one reasonable approach would be to enable the current application deployment portlet to detect when a backlevel plan is provided (assuming that's always possible) and invoke your utility to provide a head start on creating a new plan. If there's consensus around that idea then I can help with the UI. I attached a patch to GERONIMO-2006 that implements this idea. When a deployment fails the console looks for a configId attribute in the plan and if found provides the user with a new plan generated by the upgrader. They can edit the upgraded plan in place and save it locally. In some cases (welcome app, jmx-debug, and others) the upgraded plan needs no further editing so the user can save the plan and then immediately deploy again from the same portlet. In some cases (daytrader) manual editing is required but the upgraded plan at least provides a starting place. Best wishes, Paul Paul On 5/12/06, David Jencks [EMAIL PROTECTED] wrote: I put the upgrade jar at http://people.apache.org/~djencks/geronimo-upgrade-1.1-SNAPSHOT.jar It would be very helpful to find out to what extent this works in real life. It's supposed to include all the classes it needs (that's why its so big) usage: java -jar geronimo-upgrade-1.1-SNAPSHOT.jar path to source plan [path to target plan] if you leave out the target, you'll get output in the same directory as the source. thanks david jencks
Notes from JavaOne
All, A great time was had at JavaOne, including a variety of Geronimo-related meetings, hacking time in the W and Moscone, a BOF, a party, etc. Here are some thoughts I put together based on the bits I was involved with, which I think we'd all like to run by everyone who couldn't be there. Also, here are the slides from the Geronimo BOF, that talk a bit about the various releases: http://people.apache.org/~ammulder/geronimo-javaone2006.pdf Thanks, Aaron Ebay announced in a BOF that they are deploying their site on WebSphere CE (Geronimo)!!! Yeah, let's talk about acalability... :) Vendor Support - Many vendors are supporting Geronimo, including: - 24x7 support - services - building applications on Geronimo - building/supporting software stacks including Geronimo 1.1/1.2 Merge - Major things changed in 1.2: OpenEJB refactoring, JavaMail providers, initial Maven 2 build script, ActiveMQ 3-4, dynamic EJB queries - Still, not that much compared to 1.1 - We plan for the process to be 1) move 1.2 to branches/1.2-pre 2) copy 1.1 to trunk 3) maintain 1.1 in current 1.1 branch 4) merge changes from branches/1.2-pre to trunk 5) eventually whack branches/1.2-pre perhaps Release Schedule - 1.0 took too long to arrive (since founding) and 1.1 took too long to arrive (since 1.0) - We need to avoid TCK breakage and do a better job of incremental change - Some people advocate time-based releases (2/3/4 months) - Some people would like to see XBean releases more often, outside the Geronimo release schedule - Vendors don't like the uncertainty about release dates; most are still targeting 1.0 because it's here and there's no guarantee when 1.1 will actually arrive - Overall, there seems to be interest in targeting a 3-month release schedule for 1.2 (2 months active development and 1 month stabilization) - Proposal to target 4 features releases per year with incremental features available via plugins Jira Process - lots of open Jiras - estimate we have closed 250 for 1.1, and have 500 currently open - may need to clean up some old/stale issues - Jira never reflects how close we are to a release - Many Jiras go unnoticed - There's not a good way to have a personal work/priority list separate from the project release/priority list - Might be good to have 3 Jira releases: current release, next release, everything else - Might be helpful to have someone take responsibility for evaluating all incoming Jiras for a period of time (1-4 weeks?) and rotate that responsibility - Maybe could add custom fiuelds to help us manage it Java SE 5 - We can develop on Java 5 and support 1.4.2 via Retrotranslator - It supports most of Java 5, with some caveats regarding Serialization and new classes added outside of Collections (some SSL-related stuff, etc.) - Running on 1.4 with Retrotranslator causes a startup penalty of ~20% (but shouldn't have much effect after startup, when all the classes are loaded) - Running on 1.5 speeds startup by 20% and should have benefits after startup too - Dain will try a more extensive test and make sure everything works for us - Yoko is making good progress. Some holes (e.g. SSL) but we can probably start integrating and may have this for 1.2 (Rick will work on this) Java EE 5 - OpenJPA code is only partially available; more expected soon - Should be able to implement a JPA factory that lets us give access to installed JPA implementations - Should be able to get web features from Jetty 6 - Should be able to get JAX-WS from XFire/Celtix - Don't have an immediate plan for EJB3 (outside of JPA), though Spring reportedly has working code we could leverage - Should be easy to get initial EE 5 features in 1.2, may not have full support, but this is enough for people to play with Candidate Features for Future Releases - Console portlets can be added at runtime - OpenEJB 2.x revisions - Initial XBean-style features - Don't require GBeanInfo for GBeans - Integrate XBean reflect to support factory beans, nested complex objects, etc. - Designate startup methods instead of requiring interface - Full XBean Integration - Monitoring / Statistics - DConfigBeans - Improved JMX+SNMP - Pluggable JACC (Acegi, LDAP, etc.) - Start Levels - ActiveIO - IBM AIO??? - Workflow via BeanFlow - Global JNDI - XDoclet - Startup Wrapper - Upgrade on the fly - Security Rewrite - 1-click to disable unused services - Separate App/Server ClassLoaders - Spring Deployment - Improve Hot Deployment - Integrate (plugins, etc.) - XFire - OpenJPA - OpenEJB 3 - Jetty 6 - Yoko - LiveTribe - JetSpeed - Clustering - DAG ClassLoader - Maven 2 - Parallel Startup - Windows/UNIX Service - Performance - No Proxies - Console manage multiple servers - Provisioning via agents - Lingo - Map apps to ports - Eliminate XML namespaces - Telnet / GShell - GShell - Purpose-built XMLs - JPA factory support (app-managed, not CMP) Possible theme for 1.2: Community Requests - Java 5 support - Java EE 5 support (initial) -
Re: [jira] Commented: (GERONIMO-2011) Set default logging to INFO rather than DEBUG in minimal assemblies
Yes, one for *nix and one for Windows each :) [EMAIL PROTECTED] wrote: Hi Matt, Will minimal-tomcat-server and minimal-jetty-server be available as binary distributions on the Geronimo Download Site (http://geronimo.apache.org/downloads.html) when 1.1 is released? Thanks, Ian It's better to be hated for who you are than loved for who you are not Ian D. Stewart Appl Dev Analyst-Advisory, DCS Automation JPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Pager: (888) 260-0078 Matt Hogstrom (JIRA) To: dev@geronimo.apache.org [EMAIL PROTECTED]cc: che.org Subject: [jira] Commented: (GERONIMO-2011) Set default logging to INFO rather than DEBUG in minimal assemblies 05/19/2006 02:41 PM Please respond to dev [ http://issues.apache.org/jira/browse/GERONIMO-2011?page=comments#action_12412574 ] Matt Hogstrom commented on GERONIMO-2011: - Forgot the rev number for the commit. Sendingminimal-jetty-server/src/var/log/server-log4j.properties Sendingminimal-tomcat-server/src/var/log/server-log4j.properties Transmitting file data .. Committed revision 407880. Set default logging to INFO rather than DEBUG in minimal assemblies --- Key: GERONIMO-2011 URL: http://issues.apache.org/jira/browse/GERONIMO-2011 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: general Versions: 1.1 Environment: windows xp Reporter: Joe Bohn Assignee: Matt Hogstrom Fix For: 1.1 Attachments: 2011_LogLevel.patch The assemblies for j2ee-jetty-server and j2ee-tomcat-server have the default logging level set to INFO rather than Debug.The little-G assemblies (minimal-jetty-server minimal-tomcat-server) should have the same settings as we deliver the geronimo 1.1 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Any updates on the Codehaus CVS/SVN outage?
Donald, Once Codehaus is backup we need to re-apply some missing patches. I think we'll be able to cut an unstable release this weekend. Bruce Snyder wrote: On 5/19/06, Donald Woods [EMAIL PROTECTED] wrote: Has anyone heard when the server problem affecting the Codehaus CVS and SVN repos will be fixed, so we can get outstanding patches applied to OpenEJB, TranQL, ActiveMQ, ... and generate versioned releases for 1.1? See the following blog entries for status info: http://www.codehaus.org/status.html http://www.fnokd.com/2006/05/15/its-going-around/ Bruce
Re: Any updates on the Codehaus CVS/SVN outage?
On May 19, 2006, at 9:43 PM, Matt Hogstrom wrote: Donald, Once Codehaus is backup we need to re-apply some missing patches. I think we'll be able to cut an unstable release this weekend. Bruce Snyder wrote: On 5/19/06, Donald Woods [EMAIL PROTECTED] wrote: Has anyone heard when the server problem affecting the Codehaus CVS and SVN repos will be fixed, so we can get outstanding patches applied to OpenEJB, TranQL, ActiveMQ, ... and generate versioned releases for 1.1? See the following blog entries for status info: http://www.codehaus.org/status.html http://www.fnokd.com/2006/05/15/its-going-around/ Bruce Earlier today, they thought svn write access might be enabled, today. However, it doesn't look like their going to make it (at least not on my today). Once it's back up, we'll need to re-apply the RC's from 2651-2656 (this will bring us up to the pre-crash level of OpenEJB 2.1). We'll then need to apply D. Jencks patch. I also have some pending version dependency upgrades. Once this is done, we should be able to cut an unstable. IMO, generating the OpenEJB/TranQL/ActiveMQ non-snapshot releases won't occur until we've been able to bake with all of these changes for a while. --kevan
Re: Any updates on the Codehaus CVS/SVN outage?
inline.. --- Kevan Miller [EMAIL PROTECTED] wrote: On May 19, 2006, at 9:43 PM, Matt Hogstrom wrote: Donald, Once Codehaus is backup we need to re-apply some missing patches. I think we'll be able to cut an unstable release this weekend. Bruce Snyder wrote: On 5/19/06, Donald Woods [EMAIL PROTECTED] wrote: Has anyone heard when the server problem affecting the Codehaus CVS and SVN repos will be fixed, so we can get outstanding patches applied to OpenEJB, TranQL, ActiveMQ, ... and generate versioned releases for 1.1? See the following blog entries for status info: http://www.codehaus.org/status.html http://www.fnokd.com/2006/05/15/its-going-around/ Bruce Earlier today, they thought svn write access might be enabled, today. However, it doesn't look like their going to make it (at least not on my today). Once it's back up, we'll need to re-apply the RC's from 2651-2656 (this will bring us up to the pre-crash level of OpenEJB 2.1). I am almost certain that the my untouched copy of openejb can not be used, but it does not hurt to ask. here is the info - D:\x\geronimo\geronimo-1.1\openejbsvn info Path: . URL: https://svn.codehaus.org/openejb/branches/v2_1/openejb2 Repository UUID: 2b0c1533-c60b-0410-b8bd-89f67432e5c6 Revision: 2656 Node Kind: directory Schedule: normal Last Changed Author: dblevins Last Changed Rev: 2656 Last Changed Date: 2006-05-12 21:10:24 -0400 (Fri, 12 May 2006) Properties Last Updated: 2006-05-09 21:11:00 -0400 (Tue, 09 May 2006) Thanks Anita We'll then need to apply D. Jencks patch. I also have some pending version dependency upgrades. Once this is done, we should be able to cut an unstable. IMO, generating the OpenEJB/TranQL/ActiveMQ non-snapshot releases won't occur until we've been able to bake with all of these changes for a while. --kevan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Any updates on the Codehaus CVS/SVN outage?
I concur. I'm gonna pack it in for tonight and will check in the morning sometime. Kevan Miller wrote: On May 19, 2006, at 9:43 PM, Matt Hogstrom wrote: Donald, Once Codehaus is backup we need to re-apply some missing patches. I think we'll be able to cut an unstable release this weekend. Bruce Snyder wrote: On 5/19/06, Donald Woods [EMAIL PROTECTED] wrote: Has anyone heard when the server problem affecting the Codehaus CVS and SVN repos will be fixed, so we can get outstanding patches applied to OpenEJB, TranQL, ActiveMQ, ... and generate versioned releases for 1.1? See the following blog entries for status info: http://www.codehaus.org/status.html http://www.fnokd.com/2006/05/15/its-going-around/ Bruce Earlier today, they thought svn write access might be enabled, today. However, it doesn't look like their going to make it (at least not on my today). Once it's back up, we'll need to re-apply the RC's from 2651-2656 (this will bring us up to the pre-crash level of OpenEJB 2.1). We'll then need to apply D. Jencks patch. I also have some pending version dependency upgrades. Once this is done, we should be able to cut an unstable. IMO, generating the OpenEJB/TranQL/ActiveMQ non-snapshot releases won't occur until we've been able to bake with all of these changes for a while. --kevan
