[jira] Commented: (GERONIMO-1233) Bulk patch for ORB contribution
[ http://issues.apache.org/jira/browse/GERONIMO-1233?page=comments#action_12359130 ] Alan Cabrera commented on GERONIMO-1233: Checked in work. Still need to fix the error. Bulk patch for ORB contribution --- Key: GERONIMO-1233 URL: http://issues.apache.org/jira/browse/GERONIMO-1233 Project: Geronimo Type: Sub-task Components: CORBA Versions: 1.1 Reporter: Kresten Krab Thorup Assignee: Alan Cabrera Attachments: gcorba-nov-28-2005.patch.gz, gcorba-nov-29-2005.patch.gz This is the (hopefully) last bulk patch for the ORB. This includes the following elements: - JUnit tests for hello world functionality (client stream-based invocations) - code to make the JUnit test work. As such, this is a platform where we can now start doing work in smaller chunks. Up til now nothing worked so it was rather difficult to submit individual patches tied to individual Jira issues. The patch needs the idlj plugin in a version that is not yet in maven repository -- 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
ConfigurationDump
I committed a very rough configuration dump utility. This program will dump **ALL** of the information contained in the config-store. To run it you will need to update and rebuild Geronimo (a rebuild is required). The to run it, simply cd into an unpacked geronimo server (modules/assembly/target/geronimo-1.0-SNAPSHOT) and run the following command in your bash shell (I have no idea what the equivalent command on windows is): java -classpath $(ls lib/*.jar | tr '\n' ':') org.apache.geronimo.system.configuration.ConfigurationDump . The single command line argument to command dump is the location of the geronimo server home directory. This is as much work as I plan on doing on the ConfigurationDump utility, so if you want some more features your going to have to code them yourself :) -dain
Re: ConfigurationDump
If you use ClassWorlds, you can provide a simple command which functions on Windows and Unix, so you could just say run 'configdump' and externalize the loading of libraries into a ClassWorlds configuration file. ;-) --jason On Dec 2, 2005, at 12:53 AM, Dain Sundstrom wrote: I committed a very rough configuration dump utility. This program will dump **ALL** of the information contained in the config-store. To run it you will need to update and rebuild Geronimo (a rebuild is required). The to run it, simply cd into an unpacked geronimo server (modules/assembly/target/geronimo-1.0-SNAPSHOT) and run the following command in your bash shell (I have no idea what the equivalent command on windows is): java -classpath $(ls lib/*.jar | tr '\n' ':') org.apache.geronimo.system.configuration.ConfigurationDump . The single command line argument to command dump is the location of the geronimo server home directory. This is as much work as I plan on doing on the ConfigurationDump utility, so if you want some more features your going to have to code them yourself :) -dain
Re: Editable files other than .bat and .sh files and CRs LFs
i don't particularly care about line endings but I think trying to make half of our distros unusable by half of our users by leaving out some of the scripts in each distro is pointless. What harm exactly is there in including all the scripts in both packages so you only need one for all your machines? This is going to hurt who how? My apologies if I sound too negative but I can't think of any reasons leaving out some of the scripts would be a good idea. thanks david jencks On Dec 1, 2005, at 7:21 PM, John Sisson wrote: Kevan Miller wrote: I'm probably generating more discussion than this topic merits, but simply generating files with CR/LF's and calling it a Windows distribution doesn't seem like enough. Unless Windows users were complaining, I'd just build LF-only distributions from all build platforms. Now, if we built a Windows distribution which contained only .bat files (no .sh files) and appropriate CR/LF's (and vice versa), then it seems like we're making an honest effort towards OS-specific distributions... I'm sure that would be much more involved than your current proposal. Discussion is good! This isn't that hard to do, as it is just a matter of excluding *.sh or *.bat in some fileset statements but I just realised the biggest problem is the IzPack installer. IzPack has support for selecting files in an installation pack based upon the operating system, but since you have the one set of files it is installing from (pack JARs inside the installation JAR) you need to perform fixcrlf processing at install time, the only ways I can think of to get around this are: * use ant during the install (IzPack provides ant integration), but it means ant needs to be bundled with it, so adds to the size of the installer * if on Windows, run a program in the izpack-process.xml file that converts line endings. * a windows build of the IzPack installer - kind of defeats the purpose of having a java installer AFAIK, Izpack doesn't provide a simple solution to this. Unless someone has a solution to the above IzPack issue, I will change my mind and say we should build only LF distributions. John I'm +1 for creating consistent distributions regardless of the build platform. I'm +0 for making zip files use CR/LF and not doing more to create OS-specific distributions... --kevan
Re: Why would a manual deployment be new-style configId with a /car?
On Dec 1, 2005, at 8:07 PM, Aaron Mulder wrote: So a change was made to the database portlet so when it deploys a new pool it uses the configId user/database-pool-(name)/1/car I don't really understand -- since this deployment doesn't use the Maven tools, it's not packaged into a CAR or put into the repository, right? So this configId seems pretty bogus and I'm not sure why's it's any better than setting the configId to just database-pool-(name). Any insight? Well, before I ran into the next set of roadblocks I was planning on talking with you about adding groupId, artifactId and version fields to the form so you could actually construct a new-style configId if you wanted to. I would also like an option to construct a .car file in the servers geronimo repo. However, without these the new configId doesn't have much going for it, but it is consistent with the ones we use, so I don't really see the harm. If you strongly object to the capabilities I'm proposing you are welcome to change it back. thanks david jencks Thanks, Aaron
Re: [LONG] Daemon command line option conventions - need to agree before 1.0
On Dec 1, 2005, at 11:36 PM, Jason Dillon wrote: FYI, you can implement -vv simply being the same as -v -v, the option will get processed twice. Add add a simple counter to track how many times -v was used, then once finished paring options, set the verbosity according the the counter. 0=terse, 1=verbose, 2=more-verbose, etc... Exactly. -David --jason On Dec 1, 2005, at 3:26 PM, John Sisson wrote: Whilst trying to come up with a name for the new command line option for the Daemon for the new startup progress output (that doesn't use line feeds to update the status of configurations being loaded and outputs the startup time for each configuration) I chatted with David Blevins and David Jencks on IRC. They brought to my attention that the Daemon doesn't follow the convention where each option has a short form (prefixed with a single dash '-') and a long form prefixed with two dashes --. For example, run maven -h or maven --help . Currently the Daemon supports these options: -quiet -v -vv -override -h -help --help /? In the list above, the -quiet, -override and -help don't fit the convention I described. We discussed using commons CLI to process the arguments but there were concerns with the size of the library and also it is getting too close to 1.0 to make large changes. I proposed that we at least make our options follow the convention discussed above (this would allow us to move to commons CLI or a derivation of it in the future if needed). PROPOSED OPTIONS FOR 1.0 RELEASE -q--quiet ** change impacts existing users ** -v--verbose -vv --veryverbose -o --override ** change impacts existing users ** -h --help -l--long ** new option to change startup progress format ** We could still have hidden support for -help and /? but I'm not sure if they would work with commons CLI if we were to move to it in the future. In regards to the vv option being more than one character, looking at the commons CLI documentation ( http://jakarta.apache.org/ commons/cli/apidocs/org/apache/commons/cli/Options.html ), it says the short option is a single character, but it takes a string argument, so I think it is more of a recommendation. If you use more than one character for the short option you lose the ability to use the Option.getID() method that can be useful in switch statements. The deploy tool uses the long (--) form of options (doesn't support a short form) but it follows the convention. I will send another mail regarding the startup progress and whether we should change the default format. John
Resource Adapter Reference in MDB
hi, I am trying to get a generic jms resource adapter working. The RA delivers to MDB whose onMessage is activated. The MDB openejb-jar.xml has a resource ref link enterprise-beans message-driven ejb-nameTestMDB/ejb-name resource-adapter resource-linkTestRA/resource-link /resource-adapter /message-driven /enterprise-beans /openejb-jar When deploying this MDB i get the following error. Error: Unable to distribute wascemq.jar: Unknown resource adapter reference (query=geronimo.server:J2EEApplication=null,J2EEServer=geronimo,j2eeType=JCA ResourceAdapter,name=TestRA,*) The RA is deployed successfully and i am able to invoke outbound connections from a servlet. The GBeans started have following pattern j2eeType = ResourceAdapter. I also tried setting resource link to test/jms.rar with same results Error: Unable to distribute wascemq.jar: Unknown resource adapter reference (query=geronimo.server:J2EEApplication=null,J2EEServer=geronimo,j2eeType=JCA ResourceAdapter,name=test/jms.rar,*) I am lost here as to how to fix this. Any ideas or help would be great The RA plan is as follows resourceadapter resourceadapter-instance resourceadapter-nameTestRA/resourceadapter-name workmanager gbean-linkDefaultWorkManager/gbean-link /workmanager /resourceadapter-instance outbound-resourceadapter connection-definition connectionfactory-interface/connectionfactory-interface connectiondefinition-instance nameTestFactory/name config-property-setting name=url/config-property-setting config-property-setting name=icf/config-property-setting config-property-setting name=name/config-property-setting connectionmanager no-transaction/ no-pool/ /connectionmanager /connectiondefinition-instance /connection-definition /outbound-resourceadapter /resourceadapter The Geronimo log shows the following GBeans started successfully GBeanInstanceState for: geronimo.config:name=test/jms.rar State changed from starting to running GBeanInstanceState for: geronimo.server:J2EEApplication=null,J2EEServer=geronimo,j2eeType=ResourceAdapterModule,name=test/jms.rar State changed from stopped to starting GBeanInstanceState for: geronimo.server:J2EEApplication=null,J2EEServer=geronimo,j2eeType=ResourceAdapterModule,name=test/jms.rar State changed from starting to running GBeanInstanceState for: geronimo.server:J2EEApplication=null,J2EEServer=geronimo,ResourceAdapter=test/jms.rar,j2eeType=JCAResource,name=test/jms.rar State changed from stopped to starting GBeanInstanceState for: geronimo.server:J2EEApplication=null,J2EEServer=geronimo,ResourceAdapter=test/jms.rar,j2eeType=JCAResource,name=test/jms.rar State changed from starting to running GBeanInstanceState for: geronimo.server:J2EEApplication=null,J2EEServer=geronimo,JCAResource=test/jms.rar,j2eeType=JCAConnectionManager,name=TestFactory State changed from stopped to starting GBeanInstanceState for: geronimo.server:J2EEApplication=null,J2EEServer=geronimo,JCAResource=test/jms.rar,j2eeType=JCAConnectionManager,name=TestFactory State changed from starting to running GBeanInstanceState for: geronimo.server:J2EEApplication=null,J2EEServer=geronimo,JCAResource=test/jms.rar,j2eeType=JCAConnectionFactory,name=TestFactory State changed from stopped to starting GBeanInstanceState for: geronimo.server:J2EEApplication=null,J2EEServer=geronimo,JCAResource=test/jms.rar,j2eeType=JCAConnectionFactory,name=TestFactory State changed from starting to running GBeanInstanceState for: geronimo.server:J2EEApplication=null,J2EEServer=geronimo,ResourceAdapterModule=test/jms.rar,j2eeType=ResourceAdapter,name=test/jms.rar State changed from stopped to starting GBeanInstanceState for: geronimo.server:J2EEApplication=null,J2EEServer=geronimo,ResourceAdapterModule=test/jms.rar,j2eeType=ResourceAdapter,name=test/jms.rar State changed from starting to running GBeanInstanceState for: geronimo.server:J2EEApplication=null,J2EEServer=geronimo,JCAResource=test/jms.rar,j2eeType=JCAManagedConnectionFactory,name=TestFactory State changed from stopped to starting GBeanInstanceState for: geronimo.server:J2EEApplication=null,J2EEServer=geronimo,JCAResource=test/jms.rar,j2eeType=JCAManagedConnectionFactory,name=TestFactory State changed from starting to running Regards Krishnakumar B
Re: Resource Adapter Reference in MDB
After looking at the code I don't see how this is possible. There's no evidence the ResourceAdapterWrapper gbean is being started. Could you show the ra.xml please? Exactly which version of geronimo are you using? thanks david jencks On Dec 2, 2005, at 1:36 AM, Krishnakumar B wrote: hi, I am trying to get a generic jms resource adapter working. The RA delivers to MDB whose onMessage is activated. The MDB openejb-jar.xml has a resource ref link enterprise-beans message-driven ejb-nameTestMDB/ejb-name resource-adapter resource-linkTestRA/resource-link /resource-adapter /message-driven /enterprise-beans /openejb-jar When deploying this MDB i get the following error. Error: Unable to distribute wascemq.jar: Unknown resource adapter reference (query=geronimo.server: J2EEApplication=null,J2EEServer=geronimo,j2eeType=JCA ResourceAdapter,name=TestRA,*) The RA is deployed successfully and i am able to invoke outbound connections from a servlet. The GBeans started have following pattern j2eeType = ResourceAdapter. I also tried setting resource link to test/jms.rar with same results Error: Unable to distribute wascemq.jar: Unknown resource adapter reference (query=geronimo.server: J2EEApplication=null,J2EEServer=geronimo,j2eeType=JCA ResourceAdapter,name=test/jms.rar,*) I am lost here as to how to fix this. Any ideas or help would be great The RA plan is as follows resourceadapter resourceadapter-instance resourceadapter-nameTestRA/resourceadapter-name workmanager gbean-linkDefaultWorkManager/gbean-link /workmanager /resourceadapter-instance outbound-resourceadapter connection-definition connectionfactory-interface/connectionfactory-interface connectiondefinition-instance nameTestFactory/name config-property-setting name=url/config-property-setting config-property-setting name=icf/config-property-setting config-property-setting name=name/config-property-setting connectionmanager no-transaction/ no-pool/ /connectionmanager /connectiondefinition-instance /connection-definition /outbound-resourceadapter /resourceadapter The Geronimo log shows the following GBeans started successfully GBeanInstanceState for: geronimo.config:name=test/jms.rar State changed from starting to running GBeanInstanceState for: geronimo.server: J2EEApplication=null,J2EEServer=geronimo,j2eeType=ResourceAdapterModule ,name=test/jms.rar State changed from stopped to starting GBeanInstanceState for: geronimo.server: J2EEApplication=null,J2EEServer=geronimo,j2eeType=ResourceAdapterModule ,name=test/jms.rar State changed from starting to running GBeanInstanceState for: geronimo.server: J2EEApplication=null,J2EEServer=geronimo,ResourceAdapter=test/ jms.rar,j2eeType=JCAResource,name=test/jms.rar State changed from stopped to starting GBeanInstanceState for: geronimo.server: J2EEApplication=null,J2EEServer=geronimo,ResourceAdapter=test/ jms.rar,j2eeType=JCAResource,name=test/jms.rar State changed from starting to running GBeanInstanceState for: geronimo.server: J2EEApplication=null,J2EEServer=geronimo,JCAResource=test/ jms.rar,j2eeType=JCAConnectionManager,name=TestFactory State changed from stopped to starting GBeanInstanceState for: geronimo.server: J2EEApplication=null,J2EEServer=geronimo,JCAResource=test/ jms.rar,j2eeType=JCAConnectionManager,name=TestFactory State changed from starting to running GBeanInstanceState for: geronimo.server: J2EEApplication=null,J2EEServer=geronimo,JCAResource=test/ jms.rar,j2eeType=JCAConnectionFactory,name=TestFactory State changed from stopped to starting GBeanInstanceState for: geronimo.server: J2EEApplication=null,J2EEServer=geronimo,JCAResource=test/ jms.rar,j2eeType=JCAConnectionFactory,name=TestFactory State changed from starting to running GBeanInstanceState for: geronimo.server: J2EEApplication=null,J2EEServer=geronimo,ResourceAdapterModule=test/ jms.rar,j2eeType=ResourceAdapter,name=test/jms.rar State changed from stopped to starting GBeanInstanceState for: geronimo.server: J2EEApplication=null,J2EEServer=geronimo,ResourceAdapterModule=test/ jms.rar,j2eeType=ResourceAdapter,name=test/jms.rar State changed from starting to running GBeanInstanceState for: geronimo.server: J2EEApplication=null,J2EEServer=geronimo,JCAResource=test/ jms.rar,j2eeType=JCAManagedConnectionFactory,name=TestFactory State changed from stopped to starting GBeanInstanceState for: geronimo.server: J2EEApplication=null,J2EEServer=geronimo,JCAResource=test/
[jira] Updated: (GERONIMO-1233) Bulk patch for ORB contribution
[ http://issues.apache.org/jira/browse/GERONIMO-1233?page=all ] Anders Hessellund Jensen updated GERONIMO-1233: --- Attachment: tools-dependency.patch This patch addresses the rmic issue by adding the tools.jar from the SDK as a dependency to the antrun plugin. Unfortunately, this breaks the build process on Mac. The problem is that the tools.jar does not exist on Mac, as it is part of the core JRE. For now, i suggest the patch is applied. Mac users can comment out the dependency from their POM. We will have to find a decent solution to this problem. I noticed that a non-working rmic plugin exists. Perhaps it could be finished up without too much effort. Bulk patch for ORB contribution --- Key: GERONIMO-1233 URL: http://issues.apache.org/jira/browse/GERONIMO-1233 Project: Geronimo Type: Sub-task Components: CORBA Versions: 1.1 Reporter: Kresten Krab Thorup Assignee: Alan Cabrera Attachments: gcorba-nov-28-2005.patch.gz, gcorba-nov-29-2005.patch.gz, tools-dependency.patch This is the (hopefully) last bulk patch for the ORB. This includes the following elements: - JUnit tests for hello world functionality (client stream-based invocations) - code to make the JUnit test work. As such, this is a platform where we can now start doing work in smaller chunks. Up til now nothing worked so it was rather difficult to submit individual patches tied to individual Jira issues. The patch needs the idlj plugin in a version that is not yet in maven repository -- 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: Resource Adapter Reference in MDB
hi David, The RA file ?xml version=1.0 encoding=UTF-8? connector xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/connector_1_5.xsd; version=1.5 display-nameTestRA/display-name eis-typeTest EIS/eis-type resourceadapter-version1.0/resourceadapter-version resourceadapter outbound-resourceadapter connection-definition managedconnectionfactory-classcom.test.connector.outbound.TestManagedConnectionFactory/managedconnectionfactory-class config-property descriptionjndi provider/description config-property-nameurl/config-property-name config-property-typejava.lang.String/config-property-type /config-property config-property descriptionicf/description config-property-nameicf/config-property-name config-property-typejava.lang.String/config-property-type /config-property config-property descriptionname/description config-property-namename/config-property-name config-property-typejava.lang.String/config-property-type /config-property connectionfactory-interfacecom.test.connector.TestConnectionFactory/connectionfactory-interface connectionfactory-impl-classcom.test.connector.outbound.TestConnectionFactoryImpl/connectionfactory-impl-class connection-interfacecom.test.connector.TestConnection/connection-interface connection-impl-classcom.test.connector.outbound.TestConnectionImpl/connection-impl-class /connection-definition transaction-supportNoTransaction/transaction-support reauthentication-supportfalse/reauthentication-support /outbound-resourceadapter inbound-resourceadapter messageadapter messagelistener messagelistener-typejavax.jms.MessageListener/messagelistener-type activationspec activationspec-classcom.test.connector.inbound.TestActivationSpecImpl/activationspec-class required-config-property config-property-nameurl/config-property-name /required-config-property required-config-property config-property-nameicf/config-property-name /required-config-property required-config-property config-property-namename/config-property-name /required-config-property /activationspec /messagelistener /messageadapter /inbound-resourceadapter /resourceadapter /connector I am using a snapshot version post M5. Regards Krishnakumar B On 12/2/05, David Jencks [EMAIL PROTECTED] wrote: After looking at the code I don't see how this is possible. There's no evidence the ResourceAdapterWrapper gbean is being started. Could you show the ra.xml please? Exactly which version of geronimo are you using? thanks david jencks On Dec 2, 2005, at 1:36 AM, Krishnakumar B wrote: hi, I am trying to get a generic jms resource adapter working. The RA delivers to MDB whose onMessage is activated. The MDB openejb-jar.xml has a resource ref link enterprise-beans message-driven ejb-nameTestMDB/ejb-name resource-adapter resource-linkTestRA/resource-link /resource-adapter /message-driven /enterprise-beans /openejb-jar When deploying this MDB i get the following error. Error: Unable to distribute wascemq.jar: Unknown resource adapter reference (query=geronimo.server: J2EEApplication=null,J2EEServer=geronimo,j2eeType=JCA ResourceAdapter,name=TestRA,*)
Re: Resource Adapter Reference in MDB
Your resource adapter or the ra.xml is incomplete. You need a ResourceAdapter implementation class to be declared in the ra.xml in order to drive message driven beans. david jencks On Dec 2, 2005, at 2:18 AM, Krishnakumar B wrote: hi David, The RA file ?xml version=1.0 encoding=UTF-8? connector xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/connector_1_5.xsd; version=1.5 display-nameTestRA/display-name eis-typeTest EIS/eis-type resourceadapter-version1.0/resourceadapter-version resourceadapter outbound-resourceadapter connection-definition managedconnectionfactory- classcom.test.connector.outbound.TestManagedConnectionFactory/ managedconnectionfactory-class config-property descriptionjndi provider/description config-property-nameurl/config-property-name config-property-typejava.lang.String/config-property-type /config-property config-property descriptionicf/description config-property-nameicf/config-property-name config-property-typejava.lang.String/config-property-type /config-property config-property descriptionname/description config-property-namename/config-property-name config-property-typejava.lang.String/config-property-type /config-property connectionfactory- interfacecom.test.connector.TestConnectionFactory/connectionfactory- interface connectionfactory-impl- classcom.test.connector.outbound.TestConnectionFactoryImpl/ connectionfactory-impl-class connection-interfacecom.test.connector.TestConnection/ connection-interface connection-impl- classcom.test.connector.outbound.TestConnectionImpl/connection-impl- class /connection-definition transaction-supportNoTransaction/transaction-support reauthentication-supportfalse/reauthentication-support /outbound-resourceadapter inbound-resourceadapter messageadapter messagelistener messagelistener-typejavax.jms.MessageListener/messagelistener- type activationspec activationspec- classcom.test.connector.inbound.TestActivationSpecImpl/ activationspec-class required-config-property config-property-nameurl/config-property-name /required-config-property required-config-property config-property-nameicf/config-property-name /required-config-property required-config-property config-property-namename/config-property-name /required-config-property /activationspec /messagelistener /messageadapter /inbound-resourceadapter /resourceadapter /connector I am using a snapshot version post M5. Regards Krishnakumar B On 12/2/05, David Jencks [EMAIL PROTECTED] wrote: After looking at the code I don't see how this is possible. There's no evidence the ResourceAdapterWrapper gbean is being started. Could you show the ra.xml please? Exactly which version of geronimo are you using? thanks david jencks On Dec 2, 2005, at 1:36 AM, Krishnakumar B wrote: hi, I am trying to get a generic jms resource adapter working. The RA delivers to MDB whose onMessage is activated. The MDB openejb-jar.xml has a resource ref link enterprise-beans message-driven ejb-nameTestMDB/ejb-name resource-adapter resource-linkTestRA/resource-link /resource-adapter /message-driven /enterprise-beans /openejb-jar When deploying this MDB i get the following error. Error: Unable to distribute wascemq.jar: Unknown resource adapter reference (query=geronimo.server: J2EEApplication=null,J2EEServer=geronimo,j2eeType=JCA ResourceAdapter,name=TestRA,*) The RA is deployed successfully
[jira] Created: (GERONIMO-1270) NoClassDefFound exception in JMS Connection Factory portlet
NoClassDefFound exception in JMS Connection Factory portlet --- Key: GERONIMO-1270 URL: http://issues.apache.org/jira/browse/GERONIMO-1270 Project: Geronimo Type: Bug Components: console Reporter: Rick McGuire If you select the Services-JMS option from the main console page, the JMS Connection Factory porlet dies with the following exception: 06:26:24,917 ERROR [PortletFragment] Error in Portlet javax.portlet.PortletException at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:146) at org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73) at org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:119) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPortlet(PortletContainerWrapperImpl.java:70) at org.apache.pluto.portalImpl.aggregation.PortletFragment.service(PortletFragment.java:168) at org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp:65) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:277) at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163) at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112) at org.apache.jsp.WEB_002dINF.aggregation.RowFragment_jsp._jspService(org.apache.jsp.WEB_002dINF.aggregation.RowFragment_jsp:64) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:277) at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163) at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112) at org.apache.jsp.WEB_002dINF.aggregation.PageFragment_jsp._jspService(org.apache.jsp.WEB_002dINF.aggregation.PageFragment_jsp:67) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) at
[jira] Created: (GERONIMO-1271) Delete network listener action should ask for confirmation
Delete network listener action should ask for confirmation -- Key: GERONIMO-1271 URL: http://issues.apache.org/jira/browse/GERONIMO-1271 Project: Geronimo Type: Improvement Components: console Reporter: Rick McGuire Priority: Minor The Delete operation of the Web Server-Network Listeners should ask for confirmation before deleting. It is real easy to accidentally click on delete instead of edit and accidentally delete needed listenersfor example, the listener required by the console itself (ask me how I know :-)). -- 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] Created: (GERONIMO-1272) Edit Network Listener portlet should show name of listener being editted.
Edit Network Listener portlet should show name of listener being editted. -- Key: GERONIMO-1272 URL: http://issues.apache.org/jira/browse/GERONIMO-1272 Project: Geronimo Type: Improvement Components: console Reporter: Rick McGuire When you click on the edit operation of the Web Server-Network Listeners portlet, the editting portlet should show the name of the listener being editted. The lack if context is a little unsettling. -- 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] Created: (GERONIMO-1273) JMS Network Listener add dialogs should give some context information on the protocol.
JMS Network Listener add dialogs should give some context information on the protocol. -- Key: GERONIMO-1273 URL: http://issues.apache.org/jira/browse/GERONIMO-1273 Project: Geronimo Type: Improvement Components: console Reporter: Rick McGuire Priority: Minor The JMS Network Listener add dialogs (add activieio listener, etc) should give some kind of context information rather than presenting the exact dialog for all listener types. This causes a bit of uncertainty on the user's part that the correct operation is being performed. -- 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: zones update
Hi All, it has been a while since this note about the solaris zones but I have not seen any more comments about setting up a confluence site on any of these zones. It would be great if the growing V1 documentation in the confluence site (hosted by atlassian) could be moved and hosted locally by the ASF. I configured on my laptop a confluence site and have a copy of the current documentation up and running in minutes. How do you guys see installing a local confluence site in these zones? I am not a committer but would certainly like to help build this up. Cheers! Hernan Geir Magnusson Jr. wrote: Our zones are done and I'm creating user accounts for those that volunteered to help admin, namely jeff, bruce and david. I've run into a small problem (solaris doesn't seem to like group names bigger than 8 characters!) so I'll get that sorted and we can move forward... geir
Cutting Versions for TranQL (TranQL, Connectors and Vendors)
I would like to cut a release of TranQL sometime in the next few days (perhaps Monday). There has not been a lot of activity in TranQL as of late so there is no major code going in. In the Vendors and Connector I'm experimeting with a few changes. In Vendors I've added connectors for DB2 as an additional vendor. I haven't fully tested it out but that shouldn't impact CTS as we're only certifying with Derby. In the Connector framework I'm working on a statement caching DataSource. Again, this does not affect G directly as the Derby code is not being modified (to the best of my knowledge). If anyone has any concerns please respond back. The new versions will be: TranQL1.2 Connector 1.1 Vendors 1.1 Cheers, Matt
[jira] Assigned: (GERONIMO-1261) Writes to repository broken
[ http://issues.apache.org/jira/browse/GERONIMO-1261?page=all ] Kevan Miller reassigned GERONIMO-1261: -- Assign To: Aaron Mulder Aaron, I was about to investigate this issue since it was open and unassigned. However, it looks like you fixed this issue with r351591 and possibly r351592. If so, can you mark it fixed? Writes to repository broken --- Key: GERONIMO-1261 URL: http://issues.apache.org/jira/browse/GERONIMO-1261 Project: Geronimo Type: Bug Components: console, core Versions: 1.0-M5 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.0 When you download a database driver JAR from the console, it uses the writeable repository interface to save the JAR. Downloading a JAR called mysql-connector-java-3.1.11-bin.jar resulted in: - a repository entry of mysql/jars/jars-mysql-connector-java-3.1.11-bin.jar.jar (note 2 jars and 2 .jar) - a repository URI of mysql/jars-mysql-connector-java/3.1.11-bin.jar/jar (note extra jars and .jar/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] Created: (GERONIMO-1274) Cannot install an application on Tomcat using the admin console
Cannot install an application on Tomcat using the admin console --- Key: GERONIMO-1274 URL: http://issues.apache.org/jira/browse/GERONIMO-1274 Project: Geronimo Type: Bug Components: console Versions: 1.0 Reporter: Dave Colasurdo Attempted to install applications in a Tomcat-only environment using the admin console and simple deployment plans. The app install fails w/o any error in the admin console. However, there are exceptions in the log. Will attach them to this JIRA. The same scenario works fine when deploying via the cmdline. Also, the same apps install fine on Jetty using the admin console. -- 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: zones update
It would be nice to see ASF Infra switch over wiki.apache.org to Confluence 2.x, but I suppose they won't bee too keen to switching wiki systems again so soon, after switching to MoinMoin :-| --jason On Dec 2, 2005, at 6:26 AM, Hernan Cunico wrote: Hi All, it has been a while since this note about the solaris zones but I have not seen any more comments about setting up a confluence site on any of these zones. It would be great if the growing V1 documentation in the confluence site (hosted by atlassian) could be moved and hosted locally by the ASF. I configured on my laptop a confluence site and have a copy of the current documentation up and running in minutes. How do you guys see installing a local confluence site in these zones? I am not a committer but would certainly like to help build this up. Cheers! Hernan Geir Magnusson Jr. wrote: Our zones are done and I'm creating user accounts for those that volunteered to help admin, namely jeff, bruce and david. I've run into a small problem (solaris doesn't seem to like group names bigger than 8 characters!) so I'll get that sorted and we can move forward... geir
Build Failure executing new4 goal
I did a fresh checkout this morning and successfully built the using the
traditional goal (maven m:rebuild-all).
Then attempted to build using the new goals (new0, new00, new1-new5)..
I'm getting the following failure while executing maven -o new4..
350 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanInstanceState -
GBeanInstanceState for: geronimo.maven:name=ManagedAttributeStore State
changed from starting to running
380 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanInstanceState -
GBeanInstanceState for:
geronimo.maven:name=ConfigurationManager,j2eeType=Configuration
Manager State changed from starting to running
BUILD FAILED
File.. C:\Documents and
Settings\davecola\.maven\cache\maven-multiproject-plugin-1.3.1\plugin.jelly
Element... maven:reactor
Line.. 217
Column 9
Unable to obtain goal [multiproject:install-callback] -- C:\Documents
and
Settings\davecola\.maven\cache\geronimo-packaging-plugin-1.0-SNAPSHOT\plugin.jelly:67:15:
car:package null
Total time: 10 seconds
Finished at: Fri Dec 02 10:06:32 EST 2005
Here is the goal from plugin.jelly:
goal name=car:package prereqs=car:prepare-plan
description=Package a Geronimo Configuration
car:package
context=${context}
artifacts=${pom.artifacts}
pluginArtifacts=${plugin.artifacts}
repository=${geronimo.packaging.repository}
deploymentConfig=${geronimo.packaging.deploymentConfig}
deployerName=${geronimo.packaging.deployerName}
planFile=${geronimo.packaging.buildFile}
moduleFile=${geronimo.packaging.moduleFile}
packageFile=${maven.build.dir}/${maven.final.name}.car
mainClass=${geronimo.packaging.mainClass}
classPath=${geronimo.packaging.classPath}
endorsedDirs=${geronimo.packaging.endorsedDirs}
/
/goal
Thoughts?
Thanks
-Dave-
Re: Cutting Versions for TranQL (TranQL, Connectors and Vendors)
Sounds good -- but can you recap the XA drivers that we'll ship with? Last I heard there was some Oracle code, you've mentioned DB2, and someone got MySQL working, but right this minute I think Geronimo only ships with the Derby XA integration, right? I'm hoping we can include more for 1.0. Thanks, Aaron On 12/2/05, Matt Hogstrom [EMAIL PROTECTED] wrote: I would like to cut a release of TranQL sometime in the next few days (perhaps Monday). There has not been a lot of activity in TranQL as of late so there is no major code going in. In the Vendors and Connector I'm experimeting with a few changes. In Vendors I've added connectors for DB2 as an additional vendor. I haven't fully tested it out but that shouldn't impact CTS as we're only certifying with Derby. In the Connector framework I'm working on a statement caching DataSource. Again, this does not affect G directly as the Derby code is not being modified (to the best of my knowledge). If anyone has any concerns please respond back. The new versions will be: TranQL1.2 Connector 1.1 Vendors 1.1 Cheers, Matt
J2SE 1.5?
What are the chances that geronimo might add support for J2SE 1.5 before supporting J2EE 1.5? btw, Sun's J2EE 1.4 SDK bundles J2SE 1.5: http://java.sun.com/j2ee/1.4/download.html#sdk
Re: [LONG] Daemon command line option conventions - need to agree before 1.0
What is the issue with using Commons CLI? --jason We discussed using commons CLI to process the arguments but there were concerns with the size of the library and also it is getting too close to 1.0 to make large changes. I proposed that we at least make our options follow the convention discussed above (this would allow us to move to commons CLI or a derivation of it in the future if needed). PROPOSED OPTIONS FOR 1.0 RELEASE -q--quiet ** change impacts existing users ** -v--verbose -vv --veryverbose -o --override ** change impacts existing users ** -h --help -l--long ** new option to change startup progress format ** We could still have hidden support for -help and /? but I'm not sure if they would work with commons CLI if we were to move to it in the future. In regards to the vv option being more than one character, looking at the commons CLI documentation ( http:// jakarta.apache.org/commons/cli/apidocs/org/apache/commons/cli/ Options.html ), it says the short option is a single character, but it takes a string argument, so I think it is more of a recommendation. If you use more than one character for the short option you lose the ability to use the Option.getID() method that can be useful in switch statements. The deploy tool uses the long (--) form of options (doesn't support a short form) but it follows the convention. I will send another mail regarding the startup progress and whether we should change the default format. John
Re: Build Failure executing new4 goal
This one was my fault. It should be fixed now.
-dain
On Dec 2, 2005, at 7:28 AM, Dave Colasurdo wrote:
I did a fresh checkout this morning and successfully built the
using the traditional goal (maven m:rebuild-all).
Then attempted to build using the new goals (new0, new00, new1-
new5).. I'm getting the following failure while executing maven -
o new4..
350 [main] DEBUG
org.apache.geronimo.gbean.runtime.GBeanInstanceState -
GBeanInstanceState for: geronimo.maven:name=ManagedAttributeStore
State changed from starting to running
380 [main] DEBUG
org.apache.geronimo.gbean.runtime.GBeanInstanceState -
GBeanInstanceState for:
geronimo.maven:name=ConfigurationManager,j2eeType=Configuration
Manager State changed from starting to running
BUILD FAILED
File.. C:\Documents and Settings\davecola\.maven\cache\maven-
multiproject-plugin-1.3.1\plugin.jelly
Element... maven:reactor
Line.. 217
Column 9
Unable to obtain goal [multiproject:install-callback] -- C:
\Documents and Settings\davecola\.maven\cache\geronimo-packaging-
plugin-1.0-SNAPSHOT\plugin.jelly:67:15: car:package null
Total time: 10 seconds
Finished at: Fri Dec 02 10:06:32 EST 2005
Here is the goal from plugin.jelly:
goal name=car:package prereqs=car:prepare-plan
description=Package a Geronimo Configuration
car:package
context=${context}
artifacts=${pom.artifacts}
pluginArtifacts=${plugin.artifacts}
repository=${geronimo.packaging.repository}
deploymentConfig=${geronimo.packaging.deploymentConfig}
deployerName=${geronimo.packaging.deployerName}
planFile=${geronimo.packaging.buildFile}
moduleFile=${geronimo.packaging.moduleFile}
packageFile=${maven.build.dir}/${maven.final.name}.car
mainClass=${geronimo.packaging.mainClass}
classPath=${geronimo.packaging.classPath}
endorsedDirs=${geronimo.packaging.endorsedDirs}
/
/goal
Thoughts?
Thanks
-Dave-
Re: Build Failure executing new4 goal
In general maven provides no useful information with this kind of
problem unless you run with -X. So, in the future :-) when there is a
problem please run again with -X and provide the stack trace to help
diagnose what is wrong.
Also if anyone knows how to make maven report more about the error
please speak up!
thanks
david jencks
On Dec 2, 2005, at 7:28 AM, Dave Colasurdo wrote:
I did a fresh checkout this morning and successfully built the using
the traditional goal (maven m:rebuild-all).
Then attempted to build using the new goals (new0, new00,
new1-new5).. I'm getting the following failure while executing maven
-o new4..
350 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanInstanceState
- GBeanInstanceState for: geronimo.maven:name=ManagedAttributeStore
State changed from starting to running
380 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanInstanceState
- GBeanInstanceState for:
geronimo.maven:name=ConfigurationManager,j2eeType=Configuration
Manager State changed from starting to running
BUILD FAILED
File.. C:\Documents and
Settings\davecola\.maven\cache\maven-multiproject-plugin
-1.3.1\plugin.jelly
Element... maven:reactor
Line.. 217
Column 9
Unable to obtain goal [multiproject:install-callback] -- C:\Documents
and
Settings\davecola\.maven\cache\geronimo-packaging-plugin-1.0-
SNAPSHOT\plugin.jelly:67:15: car:package null
Total time: 10 seconds
Finished at: Fri Dec 02 10:06:32 EST 2005
Here is the goal from plugin.jelly:
goal name=car:package prereqs=car:prepare-plan
description=Package a Geronimo Configuration
car:package
context=${context}
artifacts=${pom.artifacts}
pluginArtifacts=${plugin.artifacts}
repository=${geronimo.packaging.repository}
deploymentConfig=${geronimo.packaging.deploymentConfig}
deployerName=${geronimo.packaging.deployerName}
planFile=${geronimo.packaging.buildFile}
moduleFile=${geronimo.packaging.moduleFile}
packageFile=${maven.build.dir}/${maven.final.name}.car
mainClass=${geronimo.packaging.mainClass}
classPath=${geronimo.packaging.classPath}
endorsedDirs=${geronimo.packaging.endorsedDirs}
/
/goal
Thoughts?
Thanks
-Dave-
Re: zones update + suggestion [long]
As I said, I am willing to help in any way I can. Getting confluence up and running is fairly simple. IIRC, Aaron offered some time ago a MoinMoin to confluence migration tool, so migrating the current content should not be a show stopper. IMHO, the current wiki still should have major surgery, independently of whether it will be migrated or not. There is a lot of unnecessary/redundant information there. There has been endless discussions on whether a wiki is the right tool or not for documentation. Well, for the Geronimo project we could even maintain both, the current wiki and confluence (to ease the transition). Limiting confluence to just documentation (like JBoss wiki), host it within the ASF and make it official (see the Geronimo documentation page, ...There is not yet a full manual or similar official documentation... By make it official I mean to work all the necessary aspects to make it official (technical accuracy, up-to-date, complete, etc). I'm already working on this ;) I keep thinking that for many users Geronimo will be as good as its documentation. V1 is around the bend, if we don't tell the users how good and simple Geronimo is, they'll use some other product that is documented. In the mean time, could anybody make a reference to the confluence site (http://opensource2.atlassian.com/confluence/oss/pages/viewpage.action?pageId=1692) from the official Geronimo documentation page (http://geronimo.apache.org/documentation.html) Sorry for the size of the note. Cheers! Hernan Jason Dillon wrote: It would be nice to see ASF Infra switch over wiki.apache.org to Confluence 2.x, but I suppose they won't bee too keen to switching wiki systems again so soon, after switching to MoinMoin :-| --jason On Dec 2, 2005, at 6:26 AM, Hernan Cunico wrote: Hi All, it has been a while since this note about the solaris zones but I have not seen any more comments about setting up a confluence site on any of these zones. It would be great if the growing V1 documentation in the confluence site (hosted by atlassian) could be moved and hosted locally by the ASF. I configured on my laptop a confluence site and have a copy of the current documentation up and running in minutes. How do you guys see installing a local confluence site in these zones? I am not a committer but would certainly like to help build this up. Cheers! Hernan Geir Magnusson Jr. wrote: Our zones are done and I'm creating user accounts for those that volunteered to help admin, namely jeff, bruce and david. I've run into a small problem (solaris doesn't seem to like group names bigger than 8 characters!) so I'll get that sorted and we can move forward... geir
Re: Editable files other than .bat and .sh files and CRs LFs
I thought is was a discussion only about line endings To clarify, I am for using windows line endings in the zip file and unix line endings in the tar.gz file. I am against leaving out some of the files from the distros (i.e., they should have the same files, just different line endings). -dain On Dec 2, 2005, at 1:11 AM, David Jencks wrote: i don't particularly care about line endings but I think trying to make half of our distros unusable by half of our users by leaving out some of the scripts in each distro is pointless. What harm exactly is there in including all the scripts in both packages so you only need one for all your machines? This is going to hurt who how? My apologies if I sound too negative but I can't think of any reasons leaving out some of the scripts would be a good idea. thanks david jencks On Dec 1, 2005, at 7:21 PM, John Sisson wrote: Kevan Miller wrote: I'm probably generating more discussion than this topic merits, but simply generating files with CR/LF's and calling it a Windows distribution doesn't seem like enough. Unless Windows users were complaining, I'd just build LF-only distributions from all build platforms. Now, if we built a Windows distribution which contained only .bat files (no .sh files) and appropriate CR/LF's (and vice versa), then it seems like we're making an honest effort towards OS- specific distributions... I'm sure that would be much more involved than your current proposal. Discussion is good! This isn't that hard to do, as it is just a matter of excluding *.sh or *.bat in some fileset statements but I just realised the biggest problem is the IzPack installer. IzPack has support for selecting files in an installation pack based upon the operating system, but since you have the one set of files it is installing from (pack JARs inside the installation JAR) you need to perform fixcrlf processing at install time, the only ways I can think of to get around this are: * use ant during the install (IzPack provides ant integration), but it means ant needs to be bundled with it, so adds to the size of the installer * if on Windows, run a program in the izpack-process.xml file that converts line endings. * a windows build of the IzPack installer - kind of defeats the purpose of having a java installer AFAIK, Izpack doesn't provide a simple solution to this. Unless someone has a solution to the above IzPack issue, I will change my mind and say we should build only LF distributions. John I'm +1 for creating consistent distributions regardless of the build platform. I'm +0 for making zip files use CR/LF and not doing more to create OS-specific distributions... --kevan
Re: [jira] Assigned: (GERONIMO-1261) Writes to repository broken
Yeah, I just crashed before I got around to it last night. :) Aaron On 12/2/05, Kevan Miller (JIRA) dev@geronimo.apache.org wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1261?page=all ] Kevan Miller reassigned GERONIMO-1261: -- Assign To: Aaron Mulder Aaron, I was about to investigate this issue since it was open and unassigned. However, it looks like you fixed this issue with r351591 and possibly r351592. If so, can you mark it fixed? Writes to repository broken --- Key: GERONIMO-1261 URL: http://issues.apache.org/jira/browse/GERONIMO-1261 Project: Geronimo Type: Bug Components: console, core Versions: 1.0-M5 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.0 When you download a database driver JAR from the console, it uses the writeable repository interface to save the JAR. Downloading a JAR called mysql-connector-java-3.1.11-bin.jar resulted in: - a repository entry of mysql/jars/jars-mysql-connector-java-3.1.11-bin.jar.jar (note 2 jars and 2 .jar) - a repository URI of mysql/jars-mysql-connector-java/3.1.11-bin.jar/jar (note extra jars and .jar/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: Cutting Versions for TranQL (TranQL, Connectors and Vendors)
We should have: Derby (client and embedded) XA DB2 XA Oracle XA Jeremy said he was working on a MySQL XA driver. Matt Aaron Mulder wrote: Sounds good -- but can you recap the XA drivers that we'll ship with? Last I heard there was some Oracle code, you've mentioned DB2, and someone got MySQL working, but right this minute I think Geronimo only ships with the Derby XA integration, right? I'm hoping we can include more for 1.0. Thanks, Aaron On 12/2/05, Matt Hogstrom [EMAIL PROTECTED] wrote: I would like to cut a release of TranQL sometime in the next few days (perhaps Monday). There has not been a lot of activity in TranQL as of late so there is no major code going in. In the Vendors and Connector I'm experimeting with a few changes. In Vendors I've added connectors for DB2 as an additional vendor. I haven't fully tested it out but that shouldn't impact CTS as we're only certifying with Derby. In the Connector framework I'm working on a statement caching DataSource. Again, this does not affect G directly as the Derby code is not being modified (to the best of my knowledge). If anyone has any concerns please respond back. The new versions will be: TranQL1.2 Connector 1.1 Vendors 1.1 Cheers, Matt
Geronimo Documentation
Hi All, I finished documenting the administration tools and *Administration Console*, here is the link http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/Administration I will be 100% with the console (http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Administration+Console) as soon as I can successfully make a new checkout and validate the applied patches. As usual, any volunteers for any section? Administrative tasks (within Administration) has already a topics wish list (TOC) Cheers! Hernan
Re: zones update
Hey Jason, any chance you'd be interested in setting up Confluence in our zone? -David On Dec 2, 2005, at 12:14 PM, Jason Dillon wrote: It would be nice to see ASF Infra switch over wiki.apache.org to Confluence 2.x, but I suppose they won't bee too keen to switching wiki systems again so soon, after switching to MoinMoin :-| --jason On Dec 2, 2005, at 6:26 AM, Hernan Cunico wrote: Hi All, it has been a while since this note about the solaris zones but I have not seen any more comments about setting up a confluence site on any of these zones. It would be great if the growing V1 documentation in the confluence site (hosted by atlassian) could be moved and hosted locally by the ASF. I configured on my laptop a confluence site and have a copy of the current documentation up and running in minutes. How do you guys see installing a local confluence site in these zones? I am not a committer but would certainly like to help build this up. Cheers! Hernan Geir Magnusson Jr. wrote: Our zones are done and I'm creating user accounts for those that volunteered to help admin, namely jeff, bruce and david. I've run into a small problem (solaris doesn't seem to like group names bigger than 8 characters!) so I'll get that sorted and we can move forward... geir
Re: Cutting Versions for TranQL (TranQL, Connectors and Vendors)
Are we sure apache policy allows us to ship the tranql connectors that depend on non-open-source stuff in order to compile? I don't think this is clear and think we might want to wait and try to clarify it at apachecon. thanks david jencks On Dec 2, 2005, at 1:12 PM, Matt Hogstrom wrote: We should have: Derby (client and embedded) XA DB2 XA Oracle XA Jeremy said he was working on a MySQL XA driver. Matt Aaron Mulder wrote: Sounds good -- but can you recap the XA drivers that we'll ship with? Last I heard there was some Oracle code, you've mentioned DB2, and someone got MySQL working, but right this minute I think Geronimo only ships with the Derby XA integration, right? I'm hoping we can include more for 1.0. Thanks, Aaron On 12/2/05, Matt Hogstrom [EMAIL PROTECTED] wrote: I would like to cut a release of TranQL sometime in the next few days (perhaps Monday). There has not been a lot of activity in TranQL as of late so there is no major code going in. In the Vendors and Connector I'm experimeting with a few changes. In Vendors I've added connectors for DB2 as an additional vendor. I haven't fully tested it out but that shouldn't impact CTS as we're only certifying with Derby. In the Connector framework I'm working on a statement caching DataSource. Again, this does not affect G directly as the Derby code is not being modified (to the best of my knowledge). If anyone has any concerns please respond back. The new versions will be: TranQL1.2 Connector 1.1 Vendors 1.1 Cheers, Matt
Re: Editable files other than .bat and .sh files and CRs LFs
This reflects my sentiment as well. Regards, Alan Dain Sundstrom wrote, On 12/2/2005 9:19 AM: I thought is was a discussion only about line endings To clarify, I am for using windows line endings in the zip file and unix line endings in the tar.gz file. I am against leaving out some of the files from the distros (i.e., they should have the same files, just different line endings). -dain On Dec 2, 2005, at 1:11 AM, David Jencks wrote: i don't particularly care about line endings but I think trying to make half of our distros unusable by half of our users by leaving out some of the scripts in each distro is pointless. What harm exactly is there in including all the scripts in both packages so you only need one for all your machines? This is going to hurt who how? My apologies if I sound too negative but I can't think of any reasons leaving out some of the scripts would be a good idea. thanks david jencks On Dec 1, 2005, at 7:21 PM, John Sisson wrote: Kevan Miller wrote: I'm probably generating more discussion than this topic merits, but simply generating files with CR/LF's and calling it a Windows distribution doesn't seem like enough. Unless Windows users were complaining, I'd just build LF-only distributions from all build platforms. Now, if we built a Windows distribution which contained only .bat files (no .sh files) and appropriate CR/LF's (and vice versa), then it seems like we're making an honest effort towards OS- specific distributions... I'm sure that would be much more involved than your current proposal. Discussion is good! This isn't that hard to do, as it is just a matter of excluding *.sh or *.bat in some fileset statements but I just realised the biggest problem is the IzPack installer. IzPack has support for selecting files in an installation pack based upon the operating system, but since you have the one set of files it is installing from (pack JARs inside the installation JAR) you need to perform fixcrlf processing at install time, the only ways I can think of to get around this are: * use ant during the install (IzPack provides ant integration), but it means ant needs to be bundled with it, so adds to the size of the installer * if on Windows, run a program in the izpack-process.xml file that converts line endings. * a windows build of the IzPack installer - kind of defeats the purpose of having a java installer AFAIK, Izpack doesn't provide a simple solution to this. Unless someone has a solution to the above IzPack issue, I will change my mind and say we should build only LF distributions. John I'm +1 for creating consistent distributions regardless of the build platform. I'm +0 for making zip files use CR/LF and not doing more to create OS-specific distributions... --kevan
[jira] Commented: (GERONIMO-1233) Bulk patch for ORB contribution
[ http://issues.apache.org/jira/browse/GERONIMO-1233?page=comments#action_12359165 ] Alan Cabrera commented on GERONIMO-1233: The tests fail because I have a space in the path to my M2 repo; I'm on a windows box. The error I get is: [server:err] java.rmi.UnmarshalException: error unmarshalling return; nested exception is: [server:err]java.net.MalformedURLException: no protocol: and [server:err]at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source) [server:err]at org.apache.geronimo.corba.testframework.TestAgent.main(TestAgent.java:150) [server:err] Caused by: java.net.MalformedURLException: no protocol: and [server:err]at java.net.URL.init(URL.java:537) [server:err]at java.net.URL.init(URL.java:434) [server:err]at java.net.URL.init(URL.java:383) [server:err]at sun.rmi.server.LoaderHandler.pathToURLs(LoaderHandler.java:747) [server:err]at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:147) [server:err]at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:631) [server:err]at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257) [server:err]at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:200) [server:err]at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513) [server:err]at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435) [server:err]at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626) [server:err]at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274) [server:err]at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324) [server:err]... 2 more [server:out] EOF [server:err] Exception in thread main [server:err] EOF The proper way fix this is to install a custom RMIClassLoader that handles spaces. The problem is that, currently, the only way around this is to declare it on the command line for the entire build/test. The Surefire group is working on extending the surefire testing framework to allow spawning of tests and it is there that we will declare our custom RMIClassLoader. Bulk patch for ORB contribution --- Key: GERONIMO-1233 URL: http://issues.apache.org/jira/browse/GERONIMO-1233 Project: Geronimo Type: Sub-task Components: CORBA Versions: 1.1 Reporter: Kresten Krab Thorup Assignee: Alan Cabrera Attachments: gcorba-nov-28-2005.patch.gz, gcorba-nov-29-2005.patch.gz, tools-dependency.patch This is the (hopefully) last bulk patch for the ORB. This includes the following elements: - JUnit tests for hello world functionality (client stream-based invocations) - code to make the JUnit test work. As such, this is a platform where we can now start doing work in smaller chunks. Up til now nothing worked so it was rather difficult to submit individual patches tied to individual Jira issues. The patch needs the idlj plugin in a version that is not yet in maven repository -- 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-751) wsdl4j version is a private build
[ http://issues.apache.org/jira/browse/GERONIMO-751?page=comments#action_12359181 ] Kevan Miller commented on GERONIMO-751: --- At the request of John Kaputin (one of the wsdl4j project admins), I've generated a Maven upload request -- http://jira.codehaus.org/browse/MAVENUPLOAD-617. Once the bundles have been processed, I'll update the project properties... wsdl4j version is a private build - Key: GERONIMO-751 URL: http://issues.apache.org/jira/browse/GERONIMO-751 Project: Geronimo Type: Bug Components: dependencies Versions: 1.0-M3 Reporter: David Jencks Assignee: Kevan Miller Fix For: 1.0 We are using a private build of wsdl4j that incorporates patches for defects 1176773 and 1193602. We should try to talk the wsld4j guys into making another point release. These patches were applied after 1.5.1 the last released version and we need the patches for web services. Dims, do you know how to get in touch with these people? -- 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: zones update
I'd love to... but what the heck is a zone? --jason On Dec 2, 2005, at 1:54 PM, David Blevins wrote: Hey Jason, any chance you'd be interested in setting up Confluence in our zone? -David On Dec 2, 2005, at 12:14 PM, Jason Dillon wrote: It would be nice to see ASF Infra switch over wiki.apache.org to Confluence 2.x, but I suppose they won't bee too keen to switching wiki systems again so soon, after switching to MoinMoin :-| --jason On Dec 2, 2005, at 6:26 AM, Hernan Cunico wrote: Hi All, it has been a while since this note about the solaris zones but I have not seen any more comments about setting up a confluence site on any of these zones. It would be great if the growing V1 documentation in the confluence site (hosted by atlassian) could be moved and hosted locally by the ASF. I configured on my laptop a confluence site and have a copy of the current documentation up and running in minutes. How do you guys see installing a local confluence site in these zones? I am not a committer but would certainly like to help build this up. Cheers! Hernan Geir Magnusson Jr. wrote: Our zones are done and I'm creating user accounts for those that volunteered to help admin, namely jeff, bruce and david. I've run into a small problem (solaris doesn't seem to like group names bigger than 8 characters!) so I'll get that sorted and we can move forward... geir
Re: Cutting Versions for TranQL (TranQL, Connectors and Vendors)
Perhaps the mighty ROUS can comment on this? David Jencks wrote: Are we sure apache policy allows us to ship the tranql connectors that depend on non-open-source stuff in order to compile? I don't think this is clear and think we might want to wait and try to clarify it at apachecon. thanks david jencks On Dec 2, 2005, at 1:12 PM, Matt Hogstrom wrote: We should have: Derby (client and embedded) XA DB2 XA Oracle XA Jeremy said he was working on a MySQL XA driver. Matt Aaron Mulder wrote: Sounds good -- but can you recap the XA drivers that we'll ship with? Last I heard there was some Oracle code, you've mentioned DB2, and someone got MySQL working, but right this minute I think Geronimo only ships with the Derby XA integration, right? I'm hoping we can include more for 1.0. Thanks, Aaron On 12/2/05, Matt Hogstrom [EMAIL PROTECTED] wrote: I would like to cut a release of TranQL sometime in the next few days (perhaps Monday). There has not been a lot of activity in TranQL as of late so there is no major code going in. In the Vendors and Connector I'm experimeting with a few changes. In Vendors I've added connectors for DB2 as an additional vendor. I haven't fully tested it out but that shouldn't impact CTS as we're only certifying with Derby. In the Connector framework I'm working on a statement caching DataSource. Again, this does not affect G directly as the Derby code is not being modified (to the best of my knowledge). If anyone has any concerns please respond back. The new versions will be: TranQL1.2 Connector 1.1 Vendors 1.1 Cheers, Matt
Moved SMTP transport out of sandbox
I just applied the SMTP patches from Rick McGuire, and moved the SMTP transport out of sandbox/mail and into modules/javamail-transport. I also repackaged it into org.apache.geronimo.javamail.transport.smtp because org.apache.geronimo.mail is already used by the mail module and it is bad form to split packages across modules. Rick said he as tested transport has been tested on a few mail servers, but more testing would be good. Also I don't think the code supports SMTP auth yet. How do we package this with the server? -dain
[jira] Closed: (GERONIMO-1246) BasicKernel.listGBeansByInterface should get GBeanInfo directly
[ http://issues.apache.org/jira/browse/GERONIMO-1246?page=all ] Dain Sundstrom closed GERONIMO-1246: Resolution: Fixed BasicKernel.listGBeansByInterface should get GBeanInfo directly --- Key: GERONIMO-1246 URL: http://issues.apache.org/jira/browse/GERONIMO-1246 Project: Geronimo Type: Improvement Components: kernel Versions: 1.0 Environment: all Reporter: Joe Bohn Assignee: Dain Sundstrom Fix For: 1.0 Attachments: BasicKernel.patch See dev list discussion http://mail-archives.apache.org/mod_mbox/geronimo-dev/200511.mbox/[EMAIL PROTECTED] On Nov 29, 2005, at 12:56 PM, Joe Bohn wrote: Is there a reason why BasicKernel.listGBeansByInterface(String[] interfaces) first obtains the GBeanData for the named object to get the GBeanInfo instead of just directly getting the GBeanInfo for the named object? (see line 289 of BasicKernel). It looks as if GBeanInfo(name) would be more efficient. That is grossly inefficient. The code should just ask for the gbeanInfo directly. -dain -- 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-526) Default domain not added to object names
[ http://issues.apache.org/jira/browse/GERONIMO-526?page=all ]
Dain Sundstrom closed GERONIMO-526:
---
Resolution: Fixed
Both the BasicKernel and BasicRegistry use the following logic when converting
object names to gbean names:
private GBeanName createGBeanName(ObjectName objectName) {
if (objectName.getDomain().length() == 0) {
return new GBeanName(kernelName, objectName.getKeyPropertyList());
}
return new GBeanName(objectName);
}
Default domain not added to object names
Key: GERONIMO-526
URL: http://issues.apache.org/jira/browse/GERONIMO-526
Project: Geronimo
Type: Bug
Components: kernel
Reporter: Dain Sundstrom
Assignee: Dain Sundstrom
Fix For: 1.1
ObjectNames using a default domain (e.g. :name=foo) can not be invoked. Name
registry should add the default domain name to the name a domain is not
present.
--
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-1276) Installing an application into Jetty - started state not retained after a restart
[ http://issues.apache.org/jira/browse/GERONIMO-1276?page=comments#action_12359185 ] Joe Bohn commented on GERONIMO-1276: This problem seems to be peculiar to the the configuration. I was able to reproduce the same results as Dave when deploying from the console on a Jetty-only configuration. However, if I was running with the default confguration (jetty on 8080 and tomcat on 8090) the application was restarted on server restarts. This seemed pretty consistent for the several attempts I made with each configuration. Of course, the tomcat only deploy failed on the console per another JIRA Dave created. (1275 I think) Installing an application into Jetty - started state not retained after a restart --- Key: GERONIMO-1276 URL: http://issues.apache.org/jira/browse/GERONIMO-1276 Project: Geronimo Type: Bug Versions: 1.0 Reporter: Dave Colasurdo I installed an application into the Jetty web container using the admin console and checking the start application box. The app installs and starts fine. However, the started state for the application is not retained over a server restart. Tryed this using the cmdline via: java -jar deployer.jar deploy c:\Example_WARs-from-ibiblio\geronimo-servlet-examples-tomcat-5.5.12 .war c:\Example_WARs-from-ibiblio\servlets-jetty-plan.xml java -jar deployer.jar start geronimo/servlets-examples/1.0-SNAPSHOT/war Again the app installed and started fine. The started state did not survive a server restart. This works fine when installing via cmdline for Tomcat. -- 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] Created: (GERONIMO-1276) Installing an application into Jetty - started state not retained after a restart
Installing an application into Jetty - started state not retained after a restart --- Key: GERONIMO-1276 URL: http://issues.apache.org/jira/browse/GERONIMO-1276 Project: Geronimo Type: Bug Versions: 1.0 Reporter: Dave Colasurdo I installed an application into the Jetty web container using the admin console and checking the start application box. The app installs and starts fine. However, the started state for the application is not retained over a server restart. Tryed this using the cmdline via: java -jar deployer.jar deploy c:\Example_WARs-from-ibiblio\geronimo-servlet-examples-tomcat-5.5.12 .war c:\Example_WARs-from-ibiblio\servlets-jetty-plan.xml java -jar deployer.jar start geronimo/servlets-examples/1.0-SNAPSHOT/war Again the app installed and started fine. The started state did not survive a server restart. This works fine when installing via cmdline for Tomcat. -- 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-1211) Problems with javamail implementation
[ http://issues.apache.org/jira/browse/GERONIMO-1211?page=all ] Dain Sundstrom closed GERONIMO-1211: Fix Version: 1.0 Resolution: Fixed Assign To: Dain Sundstrom (was: Geir Magnusson Jr) Sending specs/trunk/geronimo-spec-javamail/src/java/javax/mail/internet/InternetHeaders.java Sendingtrunk/sandbox/mail/project.xml Sending trunk/sandbox/mail/src/java/org/apache/geronimo/mail/smtp/SMTPTransport.java Transmitting file data ... Committed revision 351843. Problems with javamail implementation - Key: GERONIMO-1211 URL: http://issues.apache.org/jira/browse/GERONIMO-1211 Project: Geronimo Type: Bug Components: specs, mail Versions: 1.0-M5 Environment: All Reporter: Rick McGuire Assignee: Dain Sundstrom Fix For: 1.0 Attachments: javamail.patch, sandbox-mail.patch There are a couple of problems with the Geronimo javamail implementation: 1) When adding recipients to the message using the array form, the address list is not updated correctly, resulting in a ClassCastException when the message is sent. 2) The MAIL commands used by the SMTP Transport code (currently in the sandbox) is not compatible with all SMTP servers (i.e., the Apache James server). The email addresses on the commands need to be enclosed in pairs -- 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-1188) Get necessary izpack jars into Maven repository for access during build
[ http://issues.apache.org/jira/browse/GERONIMO-1188?page=comments#action_12359162 ] erik daughtrey commented on GERONIMO-1188: -- This issue can be closed. MAVENUPLOAD-598 was completed on 11/22 and the needed files are now in the repository. Get necessary izpack jars into Maven repository for access during build --- Key: GERONIMO-1188 URL: http://issues.apache.org/jira/browse/GERONIMO-1188 Project: Geronimo Type: Improvement Components: installer Versions: 1.0 Environment: maven and maven repository Reporter: erik daughtrey As Aaron points out, there's probably only one jar needed. David J would like to see this in a public repository such as ibiblio. -- 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-1274) Cannot install an application on Tomcat using the admin console
[ http://issues.apache.org/jira/browse/GERONIMO-1274?page=all ] Dave Colasurdo updated GERONIMO-1274: - Attachment: geronimo.save.log Here is the geronimo log. I believe the failure starts at 11:05:45 in the log.. Cannot install an application on Tomcat using the admin console --- Key: GERONIMO-1274 URL: http://issues.apache.org/jira/browse/GERONIMO-1274 Project: Geronimo Type: Bug Components: console Versions: 1.0 Reporter: Dave Colasurdo Attachments: geronimo.save.log Attempted to install applications in a Tomcat-only environment using the admin console and simple deployment plans. The app install fails w/o any error in the admin console. However, there are exceptions in the log. Will attach them to this JIRA. The same scenario works fine when deploying via the cmdline. Also, the same apps install fine on Jetty using the admin console. -- 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] Created: (GERONIMO-1277) Change group-id to org.apache.geronimo
Change group-id to org.apache.geronimo -- Key: GERONIMO-1277 URL: http://issues.apache.org/jira/browse/GERONIMO-1277 Project: Geronimo Type: Improvement Components: buildsystem Versions: 1.0-M5 Reporter: Dain Sundstrom Assigned to: Dain Sundstrom Priority: Blocker Fix For: 1.0 We need to change our group-id to org.apache.geronimo before 1.0 comes out, or else everyone's server will break when we do switch. We must make this switch when we convert to maven 2, so it is best to do it now. I will do this tomorrow. -- 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-1275) Security realm configuration file connecting specifically to the Apache Directory Server in Geronimo
[ http://issues.apache.org/jira/browse/GERONIMO-1275?page=all ] Chris Cardona updated GERONIMO-1275: Attachment: geronimo-realm-ok.ldif ldap-realm-ok.xml ldap-realm-demo-ok.war Attached are the ff. files: 1. geronimo-realm-ok.ldif ldif file to populate the Apache DS in Geronimo / creates test users and groups 2. ldap-realm-ok.xml LDAP realm configuration that connects to Apache DS in Geronimo 3. ldap-realm-demo-ok.war webapp that uses the LDAP realm Running the ldap realm webapp: 1. Add users and groups to Apache Directory (assumes you installed ldap command line tools like ldapadd, etc. / I installed OpenLDAP): c:\ ldapadd.exe -a -D uid=admin,ou=system -f geronimo-realm-ok.ldif -h localhost -p 1389 -x -w secret 2. Deploy ldap realm configuration: C:\geronimo java -jar bin\deployer.jar --user system --password manager deploy ldap-realm-ok.xml 3. Deploy ldap realm webapp: C:\geronimo java -jar bin\deployer.jar deploy --user system --password manager ldap-realm-demo-ok.war 4. Open a browser and go to: http://localhost:8080/ldap-demo/protect/hello.html and login using system/manager Security realm configuration file connecting specifically to the Apache Directory Server in Geronimo Key: GERONIMO-1275 URL: http://issues.apache.org/jira/browse/GERONIMO-1275 Project: Geronimo Type: Improvement Components: security Versions: 1.0 Reporter: Chris Cardona Attachments: geronimo-realm-ok.ldif, ldap-realm-demo-ok.war, ldap-realm-ok.xml It would be nice to have a readily available Security realm configuration that apps can use which connects to the Apache DS bundled with Geronimo. -- 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-1276) Installing an application into Jetty - started state not retained after a restart
[ http://issues.apache.org/jira/browse/GERONIMO-1276?page=all ] Joe Bohn updated GERONIMO-1276: --- Component: deployment startup/shutdown Installing an application into Jetty - started state not retained after a restart --- Key: GERONIMO-1276 URL: http://issues.apache.org/jira/browse/GERONIMO-1276 Project: Geronimo Type: Bug Components: deployment, startup/shutdown Versions: 1.0 Reporter: Dave Colasurdo I installed an application into the Jetty web container using the admin console and checking the start application box. The app installs and starts fine. However, the started state for the application is not retained over a server restart. Tryed this using the cmdline via: java -jar deployer.jar deploy c:\Example_WARs-from-ibiblio\geronimo-servlet-examples-tomcat-5.5.12 .war c:\Example_WARs-from-ibiblio\servlets-jetty-plan.xml java -jar deployer.jar start geronimo/servlets-examples/1.0-SNAPSHOT/war Again the app installed and started fine. The started state did not survive a server restart. This works fine when installing via cmdline for Tomcat. -- 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-1264) Link icon in console is the Gluecode Joe logo
[ http://issues.apache.org/jira/browse/GERONIMO-1264?page=all ] Joe Bohn updated GERONIMO-1264: --- Attachment: favicon.ico As Chris mentioned ... the easiest way to correct this is to just replace the icon. The replacement icon is the attachment (not sure how we're supposed to handle a binary replacement via a patch). There is still one problem but that will have to wait for another day since there are so many other critical issues right now. The icon works when creating a shortcut on firefox (even though it request a refresh to pick it up). However, it does not work for IE for some reason. This is no better (or worse) than things were prior to this with the Gluecode Joe icon which also didn't seem to work with IE. Link icon in console is the Gluecode Joe logo - Key: GERONIMO-1264 URL: http://issues.apache.org/jira/browse/GERONIMO-1264 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Reporter: Dain Sundstrom Assignee: Joe Bohn Priority: Critical Fix For: 1.0 Attachments: favicon.ico The link icon in the console (the icon used when creating bookmarks and in the location bar) is the logo for the Gluecode Joe product. I don't think we want to be shipping someone else's logo on our console :) -dain -- 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-1264) Link icon in console is the Gluecode Joe logo
[ http://issues.apache.org/jira/browse/GERONIMO-1264?page=all ] Joe Bohn updated GERONIMO-1264: --- Geronimo Info: [Patch Available] Fix Version: 1.0 Link icon in console is the Gluecode Joe logo - Key: GERONIMO-1264 URL: http://issues.apache.org/jira/browse/GERONIMO-1264 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Reporter: Dain Sundstrom Assignee: Joe Bohn Priority: Critical Fix For: 1.0 Attachments: favicon.ico The link icon in the console (the icon used when creating bookmarks and in the location bar) is the logo for the Gluecode Joe product. I don't think we want to be shipping someone else's logo on our console :) -dain -- 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] Created: (GERONIMO-1275) Security realm configuration file connecting specifically to the Apache Directory Server in Geronimo
Security realm configuration file connecting specifically to the Apache Directory Server in Geronimo Key: GERONIMO-1275 URL: http://issues.apache.org/jira/browse/GERONIMO-1275 Project: Geronimo Type: Improvement Components: security Versions: 1.0 Reporter: Chris Cardona It would be nice to have a readily available Security realm configuration that apps can use which connects to the Apache DS bundled with Geronimo. -- 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: zones update
On Dec 2, 2005, at 5:15 PM, Jason Dillon wrote: I'd love to... but what the heck is a zone? Awesome! Here is the zone info i am aware of: http://www.apache.org/ dev/solaris-zones.html I'll set you up an account. -David --jason On Dec 2, 2005, at 1:54 PM, David Blevins wrote: Hey Jason, any chance you'd be interested in setting up Confluence in our zone? -David On Dec 2, 2005, at 12:14 PM, Jason Dillon wrote: It would be nice to see ASF Infra switch over wiki.apache.org to Confluence 2.x, but I suppose they won't bee too keen to switching wiki systems again so soon, after switching to MoinMoin :-| --jason On Dec 2, 2005, at 6:26 AM, Hernan Cunico wrote: Hi All, it has been a while since this note about the solaris zones but I have not seen any more comments about setting up a confluence site on any of these zones. It would be great if the growing V1 documentation in the confluence site (hosted by atlassian) could be moved and hosted locally by the ASF. I configured on my laptop a confluence site and have a copy of the current documentation up and running in minutes. How do you guys see installing a local confluence site in these zones? I am not a committer but would certainly like to help build this up. Cheers! Hernan Geir Magnusson Jr. wrote: Our zones are done and I'm creating user accounts for those that volunteered to help admin, namely jeff, bruce and david. I've run into a small problem (solaris doesn't seem to like group names bigger than 8 characters!) so I'll get that sorted and we can move forward... geir
[jira] Created: (GERONIMO-1278) Upgrade to XML Beans 2.1.0 from 2.0.0
Upgrade to XML Beans 2.1.0 from 2.0.0 - Key: GERONIMO-1278 URL: http://issues.apache.org/jira/browse/GERONIMO-1278 Project: Geronimo Type: Improvement Versions: 1.0 Reporter: Matt Hogstrom Assigned to: Matt Hogstrom Fix For: 1.0 Get to a current version of XML Beans -- 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] Assigned: (GERONIMO-1247) Patch for xml.xsd, geronimo-connector-1.0.xsd and geronimo-security-1.1.xsd
[ http://issues.apache.org/jira/browse/GERONIMO-1247?page=all ] Sachin Patel reassigned GERONIMO-1247: -- Assign To: Sachin Patel Patch for xml.xsd, geronimo-connector-1.0.xsd and geronimo-security-1.1.xsd --- Key: GERONIMO-1247 URL: http://issues.apache.org/jira/browse/GERONIMO-1247 Project: Geronimo Type: Bug Environment: jdk 1.4.2_10, Eclipse 3.1.1, WTP 1.0M9 Reporter: Brian Bonner Assignee: Sachin Patel Attachments: geronimo-xsd-patch-20051130.txt, geronimo-xsd.patch.txt I was having problems with the provided schemas not validating. This was causing extraneous errors in the xml-editor when creating deployment plans for a database pool and web-app. The xsd:import were added to each of the respective geronimo- .xsds The xml.xsd was compared to http://www.w3.org/2001/xml.xsd which resulted i the changes I added. Hopefully you can include this patch :) p.s. thanks to Ed Marks over at the Eclipse site and Aaron for their help. -- 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] Resolved: (GERONIMO-1247) Patch for xml.xsd, geronimo-connector-1.0.xsd and geronimo-security-1.1.xsd
[ http://issues.apache.org/jira/browse/GERONIMO-1247?page=all ] Sachin Patel resolved GERONIMO-1247: Fix Version: 1.0 Resolution: Fixed This should be fixed now. Patch for xml.xsd, geronimo-connector-1.0.xsd and geronimo-security-1.1.xsd --- Key: GERONIMO-1247 URL: http://issues.apache.org/jira/browse/GERONIMO-1247 Project: Geronimo Type: Bug Environment: jdk 1.4.2_10, Eclipse 3.1.1, WTP 1.0M9 Reporter: Brian Bonner Assignee: Sachin Patel Fix For: 1.0 Attachments: geronimo-xsd-patch-20051130.txt, geronimo-xsd.patch.txt I was having problems with the provided schemas not validating. This was causing extraneous errors in the xml-editor when creating deployment plans for a database pool and web-app. The xsd:import were added to each of the respective geronimo- .xsds The xml.xsd was compared to http://www.w3.org/2001/xml.xsd which resulted i the changes I added. Hopefully you can include this patch :) p.s. thanks to Ed Marks over at the Eclipse site and Aaron for their help. -- 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] Assigned: (GERONIMO-1258) Introduce Tomcat examples - using new build structure
[ http://issues.apache.org/jira/browse/GERONIMO-1258?page=all ] Dain Sundstrom reassigned GERONIMO-1258: Assign To: Matt Hogstrom Introduce Tomcat examples - using new build structure - Key: GERONIMO-1258 URL: http://issues.apache.org/jira/browse/GERONIMO-1258 Project: Geronimo Type: Improvement Components: sample apps Versions: 1.0 Reporter: Dave Colasurdo Assignee: Matt Hogstrom Priority: Minor Attachments: examples.patch, welcome.patch Add the Tomcat Examples (jsp-examples, servlet-examples) to the server images for Tomcat and Jetty. The patch uses the new build structure (/config and /assemblies) and installs the examples as default started applications. -- 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] Assigned: (GERONIMO-1264) Link icon in console is the Gluecode Joe logo
[ http://issues.apache.org/jira/browse/GERONIMO-1264?page=all ] Dain Sundstrom reassigned GERONIMO-1264: Assign To: Dain Sundstrom (was: Joe Bohn) Link icon in console is the Gluecode Joe logo - Key: GERONIMO-1264 URL: http://issues.apache.org/jira/browse/GERONIMO-1264 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Reporter: Dain Sundstrom Assignee: Dain Sundstrom Priority: Critical Fix For: 1.0 Attachments: favicon.ico The link icon in the console (the icon used when creating bookmarks and in the location bar) is the logo for the Gluecode Joe product. I don't think we want to be shipping someone else's logo on our console :) -dain -- 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] Created: (GERONIMO-1279) Upgrade to Ant 1.6.5 from 1.5
Upgrade to Ant 1.6.5 from 1.5 -- Key: GERONIMO-1279 URL: http://issues.apache.org/jira/browse/GERONIMO-1279 Project: Geronimo Type: Improvement Versions: 1.0 Reporter: Matt Hogstrom Fix For: 1.0 Upgrade to current ANT Version -- 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-1264) Link icon in console is the Gluecode Joe logo
[ http://issues.apache.org/jira/browse/GERONIMO-1264?page=all ] Dain Sundstrom closed GERONIMO-1264: Resolution: Fixed Applied. I used this site to convert it to a valid ico file so it should work on ie: http://www.chami.com/html-kit/services/ Sendingtrunk/applications/console-framework/src/webapp/favicon.ico Transmitting file data . Committed revision 351878. Link icon in console is the Gluecode Joe logo - Key: GERONIMO-1264 URL: http://issues.apache.org/jira/browse/GERONIMO-1264 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Reporter: Dain Sundstrom Assignee: Dain Sundstrom Priority: Critical Fix For: 1.0 Attachments: favicon.ico The link icon in the console (the icon used when creating bookmarks and in the location bar) is the logo for the Gluecode Joe product. I don't think we want to be shipping someone else's logo on our console :) -dain -- 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] Created: (GERONIMO-1281) Upgrade TranQL Connector Version 1.1
Upgrade TranQL Connector Version 1.1 Key: GERONIMO-1281 URL: http://issues.apache.org/jira/browse/GERONIMO-1281 Project: Geronimo Type: Improvement Versions: 1.0 Reporter: Matt Hogstrom Fix For: 1.0 Migrate to the current version of the TranQL connector framework -- 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] Created: (GERONIMO-1280) Upgrade from TranQL 1.1 to 1.2
Upgrade from TranQL 1.1 to 1.2 -- Key: GERONIMO-1280 URL: http://issues.apache.org/jira/browse/GERONIMO-1280 Project: Geronimo Type: Improvement Reporter: Matt Hogstrom Upgrade to the current Version of TranQL -- 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] Created: (GERONIMO-1282) Upgrade to TranQL Vendor connectors 1.1
Upgrade to TranQL Vendor connectors 1.1 --- Key: GERONIMO-1282 URL: http://issues.apache.org/jira/browse/GERONIMO-1282 Project: Geronimo Type: Improvement Versions: 1.0 Reporter: Matt Hogstrom Fix For: 1.0 Upgrade to current TranQL Vendor Version -- 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] Assigned: (GERONIMO-1282) Upgrade to TranQL Vendor connectors 1.1
[ http://issues.apache.org/jira/browse/GERONIMO-1282?page=all ] Matt Hogstrom reassigned GERONIMO-1282: --- Assign To: Matt Hogstrom Upgrade to TranQL Vendor connectors 1.1 --- Key: GERONIMO-1282 URL: http://issues.apache.org/jira/browse/GERONIMO-1282 Project: Geronimo Type: Improvement Versions: 1.0 Reporter: Matt Hogstrom Assignee: Matt Hogstrom Fix For: 1.0 Upgrade to current TranQL Vendor Version -- 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] Assigned: (GERONIMO-1227) please re-allow read-only repositories
[ http://issues.apache.org/jira/browse/GERONIMO-1227?page=all ] Dain Sundstrom reassigned GERONIMO-1227: Assign To: Dain Sundstrom please re-allow read-only repositories -- Key: GERONIMO-1227 URL: http://issues.apache.org/jira/browse/GERONIMO-1227 Project: Geronimo Type: Wish Components: core Versions: Wish List Environment: fedora core 2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) Geronimo source At revision 348532. Reporter: toby cabot Assignee: Dain Sundstrom Priority: Minor Attachments: readonly-repo-patch.txt In our application we build Geronimo and deploy our app on a read/write filesystem but run it on a read-only filesystem. This used to work, but I upgraded our Geronimo recently and found that it checks if the repo is writeable and bails out if it isn't. I disabled that check and then Geronimo runs fine on a read-only filesystem (after hacking various xml files to put logs, etc on a read/write partition). Please consider removing the read/write repository check - I'll attach a patch that does this. -- 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] Assigned: (GERONIMO-1279) Upgrade to Ant 1.6.5 from 1.5
[ http://issues.apache.org/jira/browse/GERONIMO-1279?page=all ] Matt Hogstrom reassigned GERONIMO-1279: --- Assign To: Matt Hogstrom Upgrade to Ant 1.6.5 from 1.5 - Key: GERONIMO-1279 URL: http://issues.apache.org/jira/browse/GERONIMO-1279 Project: Geronimo Type: Improvement Versions: 1.0 Reporter: Matt Hogstrom Assignee: Matt Hogstrom Fix For: 1.0 Upgrade to current ANT Version -- 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
Move WritableRepository methods to Repository interface?
I was applying GERONIMO-1227 from Toby and it occurred to me that we may want to simply merge WritableRepository into the Repository interface and add a boolean canWrite() method to the interface. Then the console could just scan for all repositories and allow the user a choice of which writable one to upload to. What do you think? BTW this would be for 1.1. -dain
[jira] Assigned: (GERONIMO-1281) Upgrade TranQL Connector Version 1.1
[ http://issues.apache.org/jira/browse/GERONIMO-1281?page=all ] Matt Hogstrom reassigned GERONIMO-1281: --- Assign To: Matt Hogstrom Upgrade TranQL Connector Version 1.1 Key: GERONIMO-1281 URL: http://issues.apache.org/jira/browse/GERONIMO-1281 Project: Geronimo Type: Improvement Versions: 1.0 Reporter: Matt Hogstrom Assignee: Matt Hogstrom Fix For: 1.0 Migrate to the current version of the TranQL connector framework -- 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-1227) please re-allow read-only repositories
[ http://issues.apache.org/jira/browse/GERONIMO-1227?page=all ] Dain Sundstrom closed GERONIMO-1227: Fix Version: 1.0 Resolution: Fixed Sending trunk/modules/system/src/java/org/apache/geronimo/system/repository/FileSystemRepository.java Transmitting file data . Committed revision 351882. please re-allow read-only repositories -- Key: GERONIMO-1227 URL: http://issues.apache.org/jira/browse/GERONIMO-1227 Project: Geronimo Type: Wish Components: core Versions: Wish List Environment: fedora core 2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) Geronimo source At revision 348532. Reporter: toby cabot Assignee: Dain Sundstrom Priority: Minor Fix For: 1.0 Attachments: readonly-repo-patch.txt In our application we build Geronimo and deploy our app on a read/write filesystem but run it on a read-only filesystem. This used to work, but I upgraded our Geronimo recently and found that it checks if the repo is writeable and bails out if it isn't. I disabled that check and then Geronimo runs fine on a read-only filesystem (after hacking various xml files to put logs, etc on a read/write partition). Please consider removing the read/write repository check - I'll attach a patch that does this. -- 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: Move WritableRepository methods to Repository interface?
On 12/2/05, Dain Sundstrom [EMAIL PROTECTED] wrote: I was applying GERONIMO-1227 from Toby and it occurred to me that we may want to simply merge WritableRepository into the Repository interface and add a boolean canWrite() method to the interface. Then the console could just scan for all repositories and allow the user a choice of which writable one to upload to. What do you think? I'm not so sure about the patch for this. I'd almost rather see a separate repository implementation that was read-only rather than impementing WritableRepository on a file system that can't write. I would be fine with your recommendation, but I'm not too happy with having a read-only WriteableRepository for 1.0. Think there's anything we can do in the short term? Aaron BTW this would be for 1.1. -dain
Re: Cutting Versions for TranQL (TranQL, Connectors and Vendors)
My understanding was that we could ship stuff requiring non-ASL code so long as it is definitely an add-on and not core functionality. But a clarification would be great. Aaron On 12/2/05, David Jencks [EMAIL PROTECTED] wrote: Are we sure apache policy allows us to ship the tranql connectors that depend on non-open-source stuff in order to compile? I don't think this is clear and think we might want to wait and try to clarify it at apachecon. thanks david jencks On Dec 2, 2005, at 1:12 PM, Matt Hogstrom wrote: We should have: Derby (client and embedded) XA DB2 XA Oracle XA Jeremy said he was working on a MySQL XA driver. Matt Aaron Mulder wrote: Sounds good -- but can you recap the XA drivers that we'll ship with? Last I heard there was some Oracle code, you've mentioned DB2, and someone got MySQL working, but right this minute I think Geronimo only ships with the Derby XA integration, right? I'm hoping we can include more for 1.0. Thanks, Aaron On 12/2/05, Matt Hogstrom [EMAIL PROTECTED] wrote: I would like to cut a release of TranQL sometime in the next few days (perhaps Monday). There has not been a lot of activity in TranQL as of late so there is no major code going in. In the Vendors and Connector I'm experimeting with a few changes. In Vendors I've added connectors for DB2 as an additional vendor. I haven't fully tested it out but that shouldn't impact CTS as we're only certifying with Derby. In the Connector framework I'm working on a statement caching DataSource. Again, this does not affect G directly as the Derby code is not being modified (to the best of my knowledge). If anyone has any concerns please respond back. The new versions will be: TranQL1.2 Connector 1.1 Vendors 1.1 Cheers, Matt
Jetty Logging: INFO output
I've taken a first stab at reducing our INFO output. One of the standouts is Jetty, which log various stuff as INFO during startup, where the logger name is the web context name (/ or /console or /console-standard, etc.). Is there any chance of getting a Jetty build in the next few days that emits no INFO output during startup? The problem is, since the log categories are literally only / or /console or whatever (not AFAICT org.mortbay.jetty./console or something), we can't easily override those categories to log at only WARN or higher. I mean, we could do it for the console and the stuff we ship, but as soon as the user deployed a new web app, there would be more INFO output again (under their custom context name). I'm hoping to eliminate INFO output entirely except for stuff like Geronimo server started. So it would be great to find a way to suppress the context started INFO messages from Jetty. Thanks, Aaron
Re: Jetty Logging: INFO output
It would be nice if there was a prepended package to the context for logging. Like com.mortbay.jetty.webapp./console er something. I've never been too happy with services going outside of the standard package based logger naming conventions. --jason On Dec 2, 2005, at 9:08 PM, Aaron Mulder wrote: I've taken a first stab at reducing our INFO output. One of the standouts is Jetty, which log various stuff as INFO during startup, where the logger name is the web context name (/ or /console or /console-standard, etc.). Is there any chance of getting a Jetty build in the next few days that emits no INFO output during startup? The problem is, since the log categories are literally only / or /console or whatever (not AFAICT org.mortbay.jetty./console or something), we can't easily override those categories to log at only WARN or higher. I mean, we could do it for the console and the stuff we ship, but as soon as the user deployed a new web app, there would be more INFO output again (under their custom context name). I'm hoping to eliminate INFO output entirely except for stuff like Geronimo server started. So it would be great to find a way to suppress the context started INFO messages from Jetty. Thanks, Aaron
Updated etc/project.properties with new versions of TranQL and Ant
I have updated the etc/project.properties to take TranQL connector and vendors to 1.1-SNAPSHOT. Ant was changed from 1.5 to 1.6.5. G has built and appears to be ok...I'll close the JIRA's in the morning if there are no reported issues. Sendingetc/project.properties Transmitting file data . Committed revision 351889. Matt
[VOTE] Sponsor OpenEJB to become sub-project of Geronimo
The OpenEJB committers have discussed it and voted to be become a Geronimo sub-project. The incubator proposl is here: http://wiki.apache.org/incubator/OpenEjbProposal Please vote if you'd like Geronimo to be the sponsor of OpenEJB during incubation [ ] +1 = I support the move to sponsor OpenEJB during incubation as a sub-project of Geronimo [ ] +0 = I don't mind either way [ ] -1 = I don't support this move because: ___ +1 from me -- David
Re: [VOTE] Sponsor OpenEJB to become sub-project of Geronimo
+1 Sounds very reasonable to me. --jason On Dec 2, 2005, at 11:00 PM, David Blevins wrote: The OpenEJB committers have discussed it and voted to be become a Geronimo sub-project. The incubator proposl is here: http://wiki.apache.org/incubator/OpenEjbProposal Please vote if you'd like Geronimo to be the sponsor of OpenEJB during incubation [ ] +1 = I support the move to sponsor OpenEJB during incubation as a sub-project of Geronimo [ ] +0 = I don't mind either way [ ] -1 = I don't support this move because: ___ +1 from me -- David
Re: [VOTE] Sponsor OpenEJB to become sub-project of Geronimo
+1 David Blevins wrote: The OpenEJB committers have discussed it and voted to be become a Geronimo sub-project. The incubator proposl is here: http://wiki.apache.org/incubator/OpenEjbProposal Please vote if you'd like Geronimo to be the sponsor of OpenEJB during incubation [ ] +1 = I support the move to sponsor OpenEJB during incubation as a sub-project of Geronimo [ ] +0 = I don't mind either way [ ] -1 = I don't support this move because: ___ +1 from me --David
Re: [VOTE] Sponsor OpenEJB to become sub-project of Geronimo
On 12/3/05, David Blevins [EMAIL PROTECTED] wrote: [X] +1 = I support the move to sponsor OpenEJB during incubation as a sub-project of Geronimo Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' The Castor Project http://www.castor.org/ Apache Geronimo http://geronimo.apache.org/
Re: [VOTE] Sponsor OpenEJB to become sub-project of Geronimo
+ 1 - I can't wait for my apache.org email. ;)On 12/3/05, Bruce Snyder [EMAIL PROTECTED] wrote:On 12/3/05, David Blevins [EMAIL PROTECTED] wrote: [X] +1 = I support the move to sponsor OpenEJB during incubation as a sub-project of GeronimoBruce--perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );'The Castor Projecthttp://www.castor.org/Apache Geronimohttp://geronimo.apache.org/
Re: Jetty Logging: INFO output
Aaron, I'm not sure what logging setup you are using with jetty in geronimo. The normal way to surpress the INFO level messages at jetty startup is to set the system property DEBUG_VERBOSE to a negative number on the runline. cheers Jan Aaron Mulder wrote: I've taken a first stab at reducing our INFO output. One of the standouts is Jetty, which log various stuff as INFO during startup, where the logger name is the web context name (/ or /console or /console-standard, etc.). Is there any chance of getting a Jetty build in the next few days that emits no INFO output during startup? The problem is, since the log categories are literally only / or /console or whatever (not AFAICT org.mortbay.jetty./console or something), we can't easily override those categories to log at only WARN or higher. I mean, we could do it for the console and the stuff we ship, but as soon as the user deployed a new web app, there would be more INFO output again (under their custom context name). I'm hoping to eliminate INFO output entirely except for stuff like Geronimo server started. So it would be great to find a way to suppress the context started INFO messages from Jetty. Thanks, Aaron
