Re: XBean namespace for ra
I think its 4.1-SNAPSHOT thats got the xbean generated namespace in it. I certainly see it in the one in my local repo On 8/4/06, Dain Sundstrom [EMAIL PROTECTED] wrote: I looked in activemq-ra-4.0-SNAPSHOT.jar and activemq-ra-4.0.jar in my local repo and neither contain a namespace file. What jar are you using? -dain On Aug 4, 2006, at 12:35 AM, James Strachan wrote: Yes - its the activemq-ra (the Resource Adapter). We used a different namespace as its easier to use a different namespace per module with the current xbean plugin On 8/4/06, Hiram Chirino [EMAIL PROTECTED] wrote: I would think it's the activemq-ra.jar but I'll have to double check. On 8/3/06, Dain Sundstrom [EMAIL PROTECTED] wrote: Looking at the examples in the Jencks project, I see the use of the following namespace: xmlns:amqra=http://activemq.org/ra/1.0; but I can't seem to find which jar/version contains that namespace. Anyone know which published jar has that ns? Thanks, -dain -- Regards, Hiram Blog: http://hiramchirino.com -- James --- http://radio.weblogs.com/0112098/ -- James --- http://radio.weblogs.com/0112098/
New examples work broken build?
Just synchronised and performed a step1, step2 build but it seems to be failing on the bridge samples stuff: [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.servicemix.samples.bridge:bridge-jms-su:jar:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.samples.bridge -DartifactId=bridge-jms-su \ -Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.servicemix.samples.bridge:bridge-sa:jbi-service-assembly:3.0-in cubating-SNAPSHOT 2) org.apache.servicemix.samples.bridge:bridge-jms-su:jar:1.0-SNAPSHOT 2) org.apache.servicemix.samples.bridge:bridge-http-su:jar:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.samples.bridge -DartifactId=bridge-http-su \ -Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.servicemix.samples.bridge:bridge-sa:jbi-service-assembly:3.0-in cubating-SNAPSHOT 2) org.apache.servicemix.samples.bridge:bridge-http-su:jar:1.0-SNAPSHOT 3) org.apache.servicemix.samples.bridge:bridge-eip-su:jar:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.samples.bridge -DartifactId=bridge-eip-su \ -Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.servicemix.samples.bridge:bridge-sa:jbi-service-assembly:3.0-in cubating-SNAPSHOT 2) org.apache.servicemix.samples.bridge:bridge-eip-su:jar:1.0-SNAPSHOT 4) org.apache.servicemix.samples.bridge:bridge-xslt-su:jar:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.samples.bridge -DartifactId=bridge-xslt-su \ -Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.servicemix.samples.bridge:bridge-sa:jbi-service-assembly:3.0-in cubating-SNAPSHOT 2) org.apache.servicemix.samples.bridge:bridge-xslt-su:jar:1.0-SNAPSHOT -- 4 required artifacts are missing. for artifact: org.apache.servicemix.samples.bridge:bridge-sa:jbi-service-assembly:3.0-in cubating-SNAPSHOT from the specified remote repositories: central (http://ibiblio.org/maven2/), servicemix-m2-repo (http://servicemix.org/m2-repo), apache.snapshots (http://svn.apache.org/maven-snapshot-repository), codehaus (http://repository.codehaus.org), codehaus.m1 (http://dist.codehaus.org), activemq-tmp-repo (http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC2/maven2) Terry
[jira] Commented: (SM-511) Problem with schemas' import when there are multiple xsds in many dirs
[ https://issues.apache.org/activemq/browse/SM-511?page=comments#action_36686 ] Grant McDonald commented on SM-511: --- This issue has been fixed for 3.0 (after M3) of ServiceMix. It was due to two things: 1) WSDLFlattener did not utilise the baseURI when parsing schema/wsdl imports. (SM-479) 2) Apache ODE BPE version had not implemented relative import functionality. (ODE-5) The patch for the first issue is in the codebase after the M3 release. The ODE patch has also been accepted in the ODE codebase but ServiceMix is not currently using this version. Problem with schemas' import when there are multiple xsds in many dirs -- Key: SM-511 URL: https://issues.apache.org/activemq/browse/SM-511 Project: ServiceMix Issue Type: Bug Components: servicemix-bpe Affects Versions: 3.0-M2 Environment: Windows XP SP2, java version 1.5.0_05 Reporter: Lukasz Attachments: bpe-demo-sa.zip The problem appears when the wsdl file, that accompanies the bpel file, imports data types' definitions from multiple referenced xsd files that are located in subdirectories relative to 'root' directory of service unit. It is impossible to deploy such a service unit to ServiceMix. In the attachment there is the example of such service unit. Test case is simple, just try to deploy this service and the error messages should be clearly seen in the logs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2278) Problems in editing Jetty SSL Connector and the edit page in Geronimo Console
Problems in editing Jetty SSL Connector and the edit page in Geronimo Console - Key: GERONIMO-2278 URL: http://issues.apache.org/jira/browse/GERONIMO-2278 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 1.1, 1.1.1 Environment: Win XP, G1.1.1-SNAPHOT, Jetty Reporter: Vamsavardhana Reddy Fix For: 1.1.x, 1.2 Here is what I noticed. 1. Edit page does not show the current values for fields in the select boxes. 2. Changes made to the KeyStore field are not saved. 3. The page does not provide for editing the keyAlias. keyAlias is hardcoded as geronimo. Even if 2 from above is fixed, users are forced to use geronimo for the keyAlias. -- 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-2278) Problems in editing Jetty SSL Connector and the edit page in Geronimo Console
[ http://issues.apache.org/jira/browse/GERONIMO-2278?page=comments#action_12425950 ] Vamsavardhana Reddy commented on GERONIMO-2278: --- I take my work back on keyAlias being hardcoded. When a new SSL Connector is created, the value is set to the alias of unlocked key in the store. May be edit keyStore logic should take care of modifying the alias accordingly. Problems in editing Jetty SSL Connector and the edit page in Geronimo Console - Key: GERONIMO-2278 URL: http://issues.apache.org/jira/browse/GERONIMO-2278 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1, 1.1.1 Environment: Win XP, G1.1.1-SNAPHOT, Jetty Reporter: Vamsavardhana Reddy Fix For: 1.2, 1.1.x Here is what I noticed. 1. Edit page does not show the current values for fields in the select boxes. 2. Changes made to the KeyStore field are not saved. 3. The page does not provide for editing the keyAlias. keyAlias is hardcoded as geronimo. Even if 2 from above is fixed, users are forced to use geronimo for the keyAlias. -- 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-2278) Problems in editing Jetty SSL Connector and the edit page in Geronimo Console
[ http://issues.apache.org/jira/browse/GERONIMO-2278?page=all ] Vamsavardhana Reddy updated GERONIMO-2278: -- Attachment: GERONIMO-2278.patch GERONIMO-2278.patch: 1. Fixes edit page so that current values show in the select boxes 2. Changes made to keyStore and trustStore are now saved and alias is set to the current unlocked key in the keystore 3. Empty string is a valid trustStore parameter, meaning the value should be cleared. Q 1: Should the trustStore parameter be made optional since it is required only when Client Auth is checked? Q 2: Even when Client Auth is checked, the trustStore parameter can be left empty so that something like the following takes effect The validity is checked using the CA certificates stored in the first of these to be found: 1. A keystore file specified by the javax.net.ssl.trustStore system property 2. java-home/lib/security/jssecacerts 3. java-home/lib/security/cacerts Problems in editing Jetty SSL Connector and the edit page in Geronimo Console - Key: GERONIMO-2278 URL: http://issues.apache.org/jira/browse/GERONIMO-2278 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1, 1.1.1 Environment: Win XP, G1.1.1-SNAPHOT, Jetty Reporter: Vamsavardhana Reddy Fix For: 1.2, 1.1.x Attachments: GERONIMO-2278.patch Here is what I noticed. 1. Edit page does not show the current values for fields in the select boxes. 2. Changes made to the KeyStore field are not saved. 3. The page does not provide for editing the keyAlias. keyAlias is hardcoded as geronimo. Even if 2 from above is fixed, users are forced to use geronimo for the keyAlias. -- 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-2279) FileKeyStoreInstance: Does not save keyPasswords after removing an entry
FileKeyStoreInstance: Does not save keyPasswords after removing an entry Key: GERONIMO-2279 URL: http://issues.apache.org/jira/browse/GERONIMO-2279 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: security Affects Versions: 1.1.1 Reporter: Vamsavardhana Reddy Priority: Minor Fix For: 1.1.1, 1.1.x, 1.2 keyPasswords are not saved after the password of deleted entry is removed from the HashMap. -- 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: Maven2... we are almost there!
The mvn eclipse:eclipse has big issues with the xmlbeans generated classes (I wrote a hack in our maven 1 build to deal with this). Have you gotten this to work? Thanks, jeff Jason Dillon wrote: I have finished merging svkmerge/m2migration to trunk. Now it is time for everyone to start using the m2 build... and avoid using the m1 build. I updated the docs here which explain what you must do: http://cwiki.apache.org/GMOxDEV/building-apache-geronimo-with-maven-2.html You should bootstrap at least once. This is temporary and will be removed soon. * * * Please, please, please start using the m2 build. If for some reason you end up going back to m1 please let us know so we can fix it. The last major issue left unresolved (that I am ware of) is the car plugins support for geronimo-plugin.xml fluff, which I am working on resolving. --jason
[jira] Updated: (GERONIMO-2279) FileKeyStoreInstance: Does not save keyPasswords after removing an entry
[ http://issues.apache.org/jira/browse/GERONIMO-2279?page=all ] Vamsavardhana Reddy updated GERONIMO-2279: -- Attachment: GERONIMO-2279.patch FileKeyStoreInstance: Does not save keyPasswords after removing an entry Key: GERONIMO-2279 URL: http://issues.apache.org/jira/browse/GERONIMO-2279 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 1.1.1 Reporter: Vamsavardhana Reddy Priority: Minor Fix For: 1.1.1, 1.1.x, 1.2 Attachments: GERONIMO-2279.patch keyPasswords are not saved after the password of deleted entry is removed from the HashMap. -- 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-2278) Problems in editing Jetty SSL Connector and the edit page in Geronimo Console
[ http://issues.apache.org/jira/browse/GERONIMO-2278?page=all ] Vamsavardhana Reddy updated GERONIMO-2278: -- Patch Info: [Patch Available] Problems in editing Jetty SSL Connector and the edit page in Geronimo Console - Key: GERONIMO-2278 URL: http://issues.apache.org/jira/browse/GERONIMO-2278 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1, 1.1.1 Environment: Win XP, G1.1.1-SNAPHOT, Jetty Reporter: Vamsavardhana Reddy Fix For: 1.2, 1.1.x Attachments: GERONIMO-2278.patch Here is what I noticed. 1. Edit page does not show the current values for fields in the select boxes. 2. Changes made to the KeyStore field are not saved. 3. The page does not provide for editing the keyAlias. keyAlias is hardcoded as geronimo. Even if 2 from above is fixed, users are forced to use geronimo for the keyAlias. -- 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-2280) FileKeystoreInstance.getKeyManager() fails when there is more than one privatekey in the store
FileKeystoreInstance.getKeyManager() fails when there is more than one privatekey in the store -- Key: GERONIMO-2280 URL: http://issues.apache.org/jira/browse/GERONIMO-2280 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: security Affects Versions: 1.1, 1.1.1 Reporter: Vamsavardhana Reddy Fix For: 1.1.1, 1.1.2, 1.1.x, 1.2 FileKeystoreInstance.getKeyManager() fails when there is more than one privatekey in the store. Scenario 1: The method will throw UnrecoverableKeyException if the all the private key entries in the keystore do not have the same password (as the entry of our interest). Scenario 2: Even if all the private key entries have the same password and the method returns a KeyManager, there is no control on which enrty will be used. To overcome this, a temporary keystore (I call it a SubKeystore) can be generated and initialized with the entry corresponding to the alias and used to init the KeyManagerFactory. -- 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: Maven2... we are almost there!
Actually this can be fixed if we go to xbean 2.2 where they use reflection for the TypeSystemHolder class. This makes the IDE's happy. How do people feel about upping to xbean 2.2.0? See http://issues.apache.org/jira/browse/XMLBEANS-120 for this problem and that its fixed ;-) Jeff Jeff Genender wrote: The mvn eclipse:eclipse has big issues with the xmlbeans generated classes (I wrote a hack in our maven 1 build to deal with this). Have you gotten this to work? Thanks, jeff Jason Dillon wrote: I have finished merging svkmerge/m2migration to trunk. Now it is time for everyone to start using the m2 build... and avoid using the m1 build. I updated the docs here which explain what you must do: http://cwiki.apache.org/GMOxDEV/building-apache-geronimo-with-maven-2.html You should bootstrap at least once. This is temporary and will be removed soon. * * * Please, please, please start using the m2 build. If for some reason you end up going back to m1 please let us know so we can fix it. The last major issue left unresolved (that I am ware of) is the car plugins support for geronimo-plugin.xml fluff, which I am working on resolving. --jason
Re: Maven2... we are almost there!
On Aug 5, 2006, at 7:39 AM, Jeff Genender wrote: Actually this can be fixed if we go to xbean 2.2 where they use reflection for the TypeSystemHolder class. This makes the IDE's happy. How do people feel about upping to xbean 2.2.0? That would be great, but it involves abandoning the m1 build since there is no m1 plugin for xbean 2.2.0. +1 from me thanks david jencks See http://issues.apache.org/jira/browse/XMLBEANS-120 for this problem and that its fixed ;-) Jeff Jeff Genender wrote: The mvn eclipse:eclipse has big issues with the xmlbeans generated classes (I wrote a hack in our maven 1 build to deal with this). Have you gotten this to work? Thanks, jeff Jason Dillon wrote: I have finished merging svkmerge/m2migration to trunk. Now it is time for everyone to start using the m2 build... and avoid using the m1 build. I updated the docs here which explain what you must do: http://cwiki.apache.org/GMOxDEV/building-apache-geronimo-with- maven-2.html You should bootstrap at least once. This is temporary and will be removed soon. * * * Please, please, please start using the m2 build. If for some reason you end up going back to m1 please let us know so we can fix it. The last major issue left unresolved (that I am ware of) is the car plugins support for geronimo-plugin.xml fluff, which I am working on resolving. --jason
Re: Maven2... we are almost there!
On Aug 5, 2006, at 7:40 AM, David Jencks wrote: On Aug 5, 2006, at 7:39 AM, Jeff Genender wrote: Actually this can be fixed if we go to xbean 2.2 where they use reflection for the TypeSystemHolder class. This makes the IDE's happy. How do people feel about upping to xbean 2.2.0? That would be great, but it involves abandoning the m1 build since there is no m1 plugin for xbean 2.2.0. +1 from me I'm not actually sure that there's a released m2 xmlbeans 2.2 plugin either, and I'd rather get the poms for xmlbeans 2.2 straightened out properly before there is. Maybe I can get this process to move along a bit. I assume you mean xmlbeans 2.2.0 rather than xbean 2.2.0 thanks david jencks thanks david jencks See http://issues.apache.org/jira/browse/XMLBEANS-120 for this problem and that its fixed ;-) Jeff Jeff Genender wrote: The mvn eclipse:eclipse has big issues with the xmlbeans generated classes (I wrote a hack in our maven 1 build to deal with this). Have you gotten this to work? Thanks, jeff Jason Dillon wrote: I have finished merging svkmerge/m2migration to trunk. Now it is time for everyone to start using the m2 build... and avoid using the m1 build. I updated the docs here which explain what you must do: http://cwiki.apache.org/GMOxDEV/building-apache-geronimo-with- maven-2.html You should bootstrap at least once. This is temporary and will be removed soon. * * * Please, please, please start using the m2 build. If for some reason you end up going back to m1 please let us know so we can fix it. The last major issue left unresolved (that I am ware of) is the car plugins support for geronimo-plugin.xml fluff, which I am working on resolving. --jason
Re: Maven2... we are almost there!
David Jencks wrote: On Aug 5, 2006, at 7:40 AM, David Jencks wrote: On Aug 5, 2006, at 7:39 AM, Jeff Genender wrote: Actually this can be fixed if we go to xbean 2.2 where they use reflection for the TypeSystemHolder class. This makes the IDE's happy. How do people feel about upping to xbean 2.2.0? That would be great, but it involves abandoning the m1 build since there is no m1 plugin for xbean 2.2.0. +1 from me I'm not actually sure that there's a released m2 xmlbeans 2.2 plugin either, and I'd rather get the poms for xmlbeans 2.2 straightened out properly before there is. Maybe I can get this process to move along a bit. I assume you mean xmlbeans 2.2.0 rather than xbean 2.2.0 Right. If you could be so kind as to do that it would be great, as this will fix many of our IDE woes with XMLBeans. thanks david jencks thanks david jencks See http://issues.apache.org/jira/browse/XMLBEANS-120 for this problem and that its fixed ;-) Jeff Jeff Genender wrote: The mvn eclipse:eclipse has big issues with the xmlbeans generated classes (I wrote a hack in our maven 1 build to deal with this). Have you gotten this to work? Thanks, jeff Jason Dillon wrote: I have finished merging svkmerge/m2migration to trunk. Now it is time for everyone to start using the m2 build... and avoid using the m1 build. I updated the docs here which explain what you must do: http://cwiki.apache.org/GMOxDEV/building-apache-geronimo-with-maven-2.html You should bootstrap at least once. This is temporary and will be removed soon. * * * Please, please, please start using the m2 build. If for some reason you end up going back to m1 please let us know so we can fix it. The last major issue left unresolved (that I am ware of) is the car plugins support for geronimo-plugin.xml fluff, which I am working on resolving. --jason
Re: Maven2... we are almost there!
On 8/5/06, David Jencks [EMAIL PROTECTED] wrote: I'm not actually sure that there's a released m2 xmlbeans 2.2 plugin either, and I'd rather get the poms for xmlbeans 2.2 straightened out properly before there is. Maybe I can get this process to move along a bit. Effectively, there's not a released xmlbeans 2.0 m2 plugin right? I thought we had to use the snapshot of the xmlbeans 2.0 plugin to avoid the crazy dependency issues that result in the first build of an xmlbeans module failing but the second passing. Anyway, I'm happy to abandon the M1 build and go with XMLBeans 2.2. Thanks, Aaron See http://issues.apache.org/jira/browse/XMLBEANS-120 for this problem and that its fixed ;-) Jeff Jeff Genender wrote: The mvn eclipse:eclipse has big issues with the xmlbeans generated classes (I wrote a hack in our maven 1 build to deal with this). Have you gotten this to work? Thanks, jeff Jason Dillon wrote: I have finished merging svkmerge/m2migration to trunk. Now it is time for everyone to start using the m2 build... and avoid using the m1 build. I updated the docs here which explain what you must do: http://cwiki.apache.org/GMOxDEV/building-apache-geronimo-with- maven-2.html You should bootstrap at least once. This is temporary and will be removed soon. * * * Please, please, please start using the m2 build. If for some reason you end up going back to m1 please let us know so we can fix it. The last major issue left unresolved (that I am ware of) is the car plugins support for geronimo-plugin.xml fluff, which I am working on resolving. --jason
Fwd: LICENSE and NOTICE in jar artifacts (was: New copyright header policy)
I've seen discussion about this new policy on several other apache lists but AFAICT I did not receive any direct notice of the new policy and AFAICT our source files do not yet have the new header. Did any other committers get notice of this? Don't we have to fix the source for 1.1.1 before releasing it?thanksdavid jencksBegin forwarded message:From: Reinhard Poetz [EMAIL PROTECTED]Date: July 31, 2006 11:51:25 PM PDTTo: dev@maven.apache.orgSubject: LICENSE and NOTICE in jar artifacts (was: New copyright header policy)Reply-To: "Maven Developers List" dev@maven.apache.org According to the two mails below from [EMAIL PROTECTED], starting with today a PMC isn't allowed to release an artifact if the sources don't cover the new copyright header policy (second mail). Additionally we need to add LICENSE and NOTICE files inside jars too (first mail).Has the maven-jar-plugin been adapted to meet this requirement or is there some simple way to achieve the same result?ReinhardCliff Schmidt wrote: On Jun 2, 2006, at 6:59 PM, Carlos Sanchez wrote: What would be the policy for jar files that can be distributedindividually through the Apache repository? do all of them need tohave the LICENSE and NOTICE files inside the jar? Yes -- if they are the result of work created at the ASF (not third-party works, which should just be left as they were found) - o -On 6/2/06, Cliff Schmidt [EMAIL PROTECTED] wrote: During the last ASF Board meeting, a resolution was passed to require a different licensing header in source files plus requirements for copyright notices. PMCs are not required to make any changes to past releases, but must apply these new rules to all distributions released on or after August 1, 2006. Before I send this out to committers@, I thought I'd start by sending it here to collect and answer any FAQ-type questions. So, here's the new policy; hit me with any questions you have. Thanks, Cliff --- New copyright notice and source header policy --- A. THIRD-PARTY COPYRIGHT NOTICES AND LICENSES 0. The term "third-party work" refers to a work not submitted directly to the ASF by the copyright owner or owner's agent. 1. Do not modify or remove any copyright notices or licenses within third-party works. 2. Do not add the standard Apache License header to the top of any third-party source files. 3. Minor modifications/additions to third-party source files should typically be licensed under the same terms as the rest of the source for convenience. 4. Major modifications/additions to third-party should be dealt with on a case-by-case basis by the PMC. B. SOURCE FILE HEADERS 0. This section refers only to works submitted directly to the ASF by the copyright owner or owner's agent. 1. If the source file is submitted with a copyright notice included in it, the copyright owner (or owner's agent) must either: a. remove such notices, or b. move them to the NOTICE file associated with each applicable project release, or c. provide written permission for the ASF to make such removal or relocation of the notices. 2. Each source file should include the following license header -- note that there should be no copyright notice in the header: Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. C. NOTICE FILE 0. Every Apache distribution should include a NOTICE file in the top directory, along with the standard LICENSE file 1. The top of each NOTICE file should include the following text, suitably modified to reflect the product name and year(s) of distribution of the current and past versions of the product: Apache [PRODUCT_NAME] Copyright [] The Apache Software Foundation This product includes software developed at The Apache Software Foundation (http://www.apache.org/). 2. The remainder of the NOTICE file is to be used for required third-party notices. The NOTICE file may also include copyright notices moved from source files submitted to the ASF (see B.1.). ___ Telefonate ohne weitere Kosten
[jira] Updated: (GERONIMO-2278) Problems in editing Jetty SSL Connector and the edit page in Geronimo Console
[ http://issues.apache.org/jira/browse/GERONIMO-2278?page=all ] Vamsavardhana Reddy updated GERONIMO-2278: -- Attachment: GERONIMO-2278-new.patch Use this GERONIMO-2278-new.patch. Ignore GERONIMO-2278.patch Problems in editing Jetty SSL Connector and the edit page in Geronimo Console - Key: GERONIMO-2278 URL: http://issues.apache.org/jira/browse/GERONIMO-2278 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1, 1.1.1 Environment: Win XP, G1.1.1-SNAPHOT, Jetty Reporter: Vamsavardhana Reddy Fix For: 1.2, 1.1.x Attachments: GERONIMO-2278-new.patch, GERONIMO-2278.patch Here is what I noticed. 1. Edit page does not show the current values for fields in the select boxes. 2. Changes made to the KeyStore field are not saved. 3. The page does not provide for editing the keyAlias. keyAlias is hardcoded as geronimo. Even if 2 from above is fixed, users are forced to use geronimo for the keyAlias. -- 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: LICENSE and NOTICE in jar artifacts (was: New copyright header policy)
Reading some more mails on the maven list, this change has apparently been postponed but we should no doubt watch out for it.thanksdavid jencksOn Aug 5, 2006, at 8:13 AM, David Jencks wrote:I've seen discussion about this new policy on several other apache lists but AFAICT I did not receive any direct notice of the new policy and AFAICT our source files do not yet have the new header. Did any other committers get notice of this? Don't we have to fix the source for 1.1.1 before releasing it?thanksdavid jencksBegin forwarded message:From: Reinhard Poetz [EMAIL PROTECTED]Date: July 31, 2006 11:51:25 PM PDTTo: dev@maven.apache.orgSubject: LICENSE and NOTICE in jar artifacts (was: New copyright header policy)Reply-To: "Maven Developers List" dev@maven.apache.org According to the two mails below from [EMAIL PROTECTED], starting with today a PMC isn't allowed to release an artifact if the sources don't cover the new copyright header policy (second mail). Additionally we need to add LICENSE and NOTICE files inside jars too (first mail).Has the maven-jar-plugin been adapted to meet this requirement or is there some simple way to achieve the same result?ReinhardCliff Schmidt wrote: On Jun 2, 2006, at 6:59 PM, Carlos Sanchez wrote: What would be the policy for jar files that can be distributedindividually through the Apache repository? do all of them need tohave the LICENSE and NOTICE files inside the jar? Yes -- if they are the result of work created at the ASF (not third-party works, which should just be left as they were found) - o -On 6/2/06, Cliff Schmidt [EMAIL PROTECTED] wrote: During the last ASF Board meeting, a resolution was passed to require a different licensing header in source files plus requirements for copyright notices. PMCs are not required to make any changes to past releases, but must apply these new rules to all distributions released on or after August 1, 2006. Before I send this out to committers@, I thought I'd start by sending it here to collect and answer any FAQ-type questions. So, here's the new policy; hit me with any questions you have. Thanks, Cliff --- New copyright notice and source header policy --- A. THIRD-PARTY COPYRIGHT NOTICES AND LICENSES 0. The term "third-party work" refers to a work not submitted directly to the ASF by the copyright owner or owner's agent. 1. Do not modify or remove any copyright notices or licenses within third-party works. 2. Do not add the standard Apache License header to the top of any third-party source files. 3. Minor modifications/additions to third-party source files should typically be licensed under the same terms as the rest of the source for convenience. 4. Major modifications/additions to third-party should be dealt with on a case-by-case basis by the PMC. B. SOURCE FILE HEADERS 0. This section refers only to works submitted directly to the ASF by the copyright owner or owner's agent. 1. If the source file is submitted with a copyright notice included in it, the copyright owner (or owner's agent) must either: a. remove such notices, or b. move them to the NOTICE file associated with each applicable project release, or c. provide written permission for the ASF to make such removal or relocation of the notices. 2. Each source file should include the following license header -- note that there should be no copyright notice in the header: Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. C. NOTICE FILE 0. Every Apache distribution should include a NOTICE file in the top directory, along with the standard LICENSE file 1. The top of each NOTICE file should include the following text, suitably modified to reflect the product name and year(s) of distribution of the current and past versions of the product: Apache [PRODUCT_NAME] Copyright [] The Apache Software Foundation This product includes software developed at The Apache Software Foundation (http://www.apache.org/). 2. The remainder of the NOTICE file is to be used for required third-party notices. The
[jira] Updated: (GERONIMO-2280) FileKeystoreInstance.getKeyManager() fails when there is more than one privatekey in the store
[ http://issues.apache.org/jira/browse/GERONIMO-2280?page=all ] Vamsavardhana Reddy updated GERONIMO-2280: -- Attachment: GERONIMO-2280.patch GERONIMO-2280.patch: To be applied to modules\security FileKeystoreInstance.getKeyManager() fails when there is more than one privatekey in the store -- Key: GERONIMO-2280 URL: http://issues.apache.org/jira/browse/GERONIMO-2280 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 1.1, 1.1.1 Reporter: Vamsavardhana Reddy Fix For: 1.2, 1.1.1, 1.1.x, 1.1.2 Attachments: GERONIMO-2280.patch FileKeystoreInstance.getKeyManager() fails when there is more than one privatekey in the store. Scenario 1: The method will throw UnrecoverableKeyException if the all the private key entries in the keystore do not have the same password (as the entry of our interest). Scenario 2: Even if all the private key entries have the same password and the method returns a KeyManager, there is no control on which enrty will be used. To overcome this, a temporary keystore (I call it a SubKeystore) can be generated and initialized with the entry corresponding to the alias and used to init the KeyManagerFactory. -- 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: Maven2... we are almost there!
This is a small work around... Jason was awesome enough to copy the nasty classes out into the target/clover/classes directory, so by adding that to the src in the IDEs, it seems to temporarily fix the problem ;-) But..I agree...I would like to see us up to 2.2 to not have ot hack this. Jeff Aaron Mulder wrote: On 8/5/06, David Jencks [EMAIL PROTECTED] wrote: I'm not actually sure that there's a released m2 xmlbeans 2.2 plugin either, and I'd rather get the poms for xmlbeans 2.2 straightened out properly before there is. Maybe I can get this process to move along a bit. Effectively, there's not a released xmlbeans 2.0 m2 plugin right? I thought we had to use the snapshot of the xmlbeans 2.0 plugin to avoid the crazy dependency issues that result in the first build of an xmlbeans module failing but the second passing. Anyway, I'm happy to abandon the M1 build and go with XMLBeans 2.2. Thanks, Aaron See http://issues.apache.org/jira/browse/XMLBEANS-120 for this problem and that its fixed ;-) Jeff Jeff Genender wrote: The mvn eclipse:eclipse has big issues with the xmlbeans generated classes (I wrote a hack in our maven 1 build to deal with this). Have you gotten this to work? Thanks, jeff Jason Dillon wrote: I have finished merging svkmerge/m2migration to trunk. Now it is time for everyone to start using the m2 build... and avoid using the m1 build. I updated the docs here which explain what you must do: http://cwiki.apache.org/GMOxDEV/building-apache-geronimo-with- maven-2.html You should bootstrap at least once. This is temporary and will be removed soon. * * * Please, please, please start using the m2 build. If for some reason you end up going back to m1 please let us know so we can fix it. The last major issue left unresolved (that I am ware of) is the car plugins support for geronimo-plugin.xml fluff, which I am working on resolving. --jason
[jira] Commented: (GERONIMO-2280) FileKeystoreInstance.getKeyManager() fails when there is more than one privatekey in the store
[ http://issues.apache.org/jira/browse/GERONIMO-2280?page=comments#action_12425970 ] Vamsavardhana Reddy commented on GERONIMO-2280: --- With this fix, 1. A keystore can have more than one private key in unlocked state. 2. If a user creates a second private key entry (with a different password that that of the alias currently used by JettySSLConnector) in the keystore geronimo-default, this patch enables successful server startup. Otherwise server startup will fail (Scenario 1 from above). 3. keyAlias field can be made editable in Jetty edit HTTPS Connectors page. FileKeystoreInstance.getKeyManager() fails when there is more than one privatekey in the store -- Key: GERONIMO-2280 URL: http://issues.apache.org/jira/browse/GERONIMO-2280 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 1.1, 1.1.1 Reporter: Vamsavardhana Reddy Fix For: 1.2, 1.1.1, 1.1.x, 1.1.2 Attachments: GERONIMO-2280.patch FileKeystoreInstance.getKeyManager() fails when there is more than one privatekey in the store. Scenario 1: The method will throw UnrecoverableKeyException if the all the private key entries in the keystore do not have the same password (as the entry of our interest). Scenario 2: Even if all the private key entries have the same password and the method returns a KeyManager, there is no control on which enrty will be used. To overcome this, a temporary keystore (I call it a SubKeystore) can be generated and initialized with the entry corresponding to the alias and used to init the KeyManagerFactory. -- 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-2281) Deploy tool does not work (built from new m2 build)
Deploy tool does not work (built from new m2 build) --- Key: GERONIMO-2281 URL: http://issues.apache.org/jira/browse/GERONIMO-2281 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment Affects Versions: 1.2 Reporter: Bill Dudney A fresh build of geronimo from trunk (with m2) does not have a working deployer. Tested only with the tomcat install but its likely a bug in all. To recreate; build with m2 (follow directions on wiki) install the g-tomcat-1.2-S.tar.gz start the server with bin/startup.sh deploy something with bin/deploy.sh fails to find class javax/enterprise/deploy/spi/status/ProgressListener.class patch adds to the manifest class path of deployer.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] Updated: (GERONIMO-2281) Deploy tool does not work (built from new m2 build)
[ http://issues.apache.org/jira/browse/GERONIMO-2281?page=all ] Bill Dudney updated GERONIMO-2281: -- Attachment: 2281-online-deployer.patch apply from the root, one simple change in 'configs/online-deployer/pom.xml' Deploy tool does not work (built from new m2 build) --- Key: GERONIMO-2281 URL: http://issues.apache.org/jira/browse/GERONIMO-2281 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.2 Reporter: Bill Dudney Attachments: 2281-online-deployer.patch A fresh build of geronimo from trunk (with m2) does not have a working deployer. Tested only with the tomcat install but its likely a bug in all. To recreate; build with m2 (follow directions on wiki) install the g-tomcat-1.2-S.tar.gz start the server with bin/startup.sh deploy something with bin/deploy.sh fails to find class javax/enterprise/deploy/spi/status/ProgressListener.class patch adds to the manifest class path of deployer.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: Maven2... we are almost there!
Hi Jason, Thanks again for all the hard work! Build works fine, I get an assembly that I can install and run. However there is a problem deploying. I filed; https://issues.apache.org/jira/browse/GERONIMO-2281 and attached a patch to fix it. The console will not deploy anything either, probably related but I've not had a chance to track it down. Will look at it later tonight if its not fixed by then. TTFN, bd- On Aug 4, 2006, at 6:25 PM, Jason Dillon wrote: I have finished merging svkmerge/m2migration to trunk. Now it is time for everyone to start using the m2 build... and avoid using the m1 build. I updated the docs here which explain what you must do: http://cwiki.apache.org/GMOxDEV/building-apache-geronimo-with- maven-2.html You should bootstrap at least once. This is temporary and will be removed soon. * * * Please, please, please start using the m2 build. If for some reason you end up going back to m1 please let us know so we can fix it. The last major issue left unresolved (that I am ware of) is the car plugins support for geronimo-plugin.xml fluff, which I am working on resolving. --jason
[jira] Created: (GERONIMO-2282) Too hard to install JARs into the repository
Too hard to install JARs into the repository Key: GERONIMO-2282 URL: http://issues.apache.org/jira/browse/GERONIMO-2282 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.1.x It's asking too much of a user to create a proper Maven 2 directory structure in the repository and copy a JAR in there with precisely the right name. There should be an easy command-line tool to install a JAR into the Geronimo repository. As in, you point it at the JAR you want to install, and it prompts you for the group, artifact, version, and type, installs the JAR into the repository, and then tells you how to use it from an application. -- 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-2283) Common libs portlet guesses wrong group ID, gives no usage advice
Common libs portlet guesses wrong group ID, gives no usage advice - Key: GERONIMO-2283 URL: http://issues.apache.org/jira/browse/GERONIMO-2283 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.1.x When selecting a file for the repository portlet, it selected the version number as the group ID. It should probably default to a blank group ID and make the user enter it -- the best it can select from the file name is probably the artifact, version, and type. Also, it should have an option where you pick a JAR and it gives you the dependency syntax you need to add that JAR to the classpath for an application or other Geronimo module. -- 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-2284) Console DB/JMS and Security Realm naming inconsistent
Console DB/JMS and Security Realm naming inconsistent - Key: GERONIMO-2284 URL: http://issues.apache.org/jira/browse/GERONIMO-2284 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.1.x When the console creates a database connection pool or JMS resource, the module ID has the group console.dbpool or console.jms. However, when it creates a security realm, the module ID just has the group console and the artifact ID has the prefix realm-. Instead, the security realm module ID should have the group console.realm and the artifact ID should be the same as the name the user specified. -- 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-2285) Console DB Pool Show Plan has bad EAR plan in advice
Console DB Pool Show Plan has bad EAR plan in advice
Key: GERONIMO-2285
URL: http://issues.apache.org/jira/browse/GERONIMO-2285
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: console, databases
Affects Versions: 1.1
Reporter: Aaron Mulder
Assigned To: Aaron Mulder
Fix For: 1.1.2
It shows:
{code:xml}
application
xmlns=http://geronimo.apache.org/xml/ns/j2ee/application-1.0;
configId=MyApplication
module
connectorrar-file-name.rar/connector
alt-ddplan-file-name.xml/alt-dd
/module
/application
{code}
--
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-2285) Console Show Plan screens have bad EAR plan in advice
[ http://issues.apache.org/jira/browse/GERONIMO-2285?page=all ]
Aaron Mulder updated GERONIMO-2285:
---
Summary: Console Show Plan screens have bad EAR plan in advice (was:
Console DB Pool Show Plan has bad EAR plan in advice)
Component/s: ActiveMQ
security
Description:
The JDBC show plan page shows:
{code:xml}
application
xmlns=http://geronimo.apache.org/xml/ns/j2ee/application-1.0;
configId=MyApplication
module
connectorrar-file-name.rar/connector
alt-ddplan-file-name.xml/alt-dd
/module
/application
{code}
The JMS and security realm Show Plan pages have similar errors.
was:
It shows:
{code:xml}
application
xmlns=http://geronimo.apache.org/xml/ns/j2ee/application-1.0;
configId=MyApplication
module
connectorrar-file-name.rar/connector
alt-ddplan-file-name.xml/alt-dd
/module
/application
{code}
Console Show Plan screens have bad EAR plan in advice
-
Key: GERONIMO-2285
URL: http://issues.apache.org/jira/browse/GERONIMO-2285
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security, ActiveMQ, console, databases
Affects Versions: 1.1
Reporter: Aaron Mulder
Assigned To: Aaron Mulder
Fix For: 1.1.2
The JDBC show plan page shows:
{code:xml}
application
xmlns=http://geronimo.apache.org/xml/ns/j2ee/application-1.0;
configId=MyApplication
module
connectorrar-file-name.rar/connector
alt-ddplan-file-name.xml/alt-dd
/module
/application
{code}
The JMS and security realm Show Plan pages have similar errors.
--
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: (XBEAN-36) [RTC] Support annotating properties with the ProperyEditor that should be used when wiring in the value.
[RTC] Support annotating properties with the ProperyEditor that should be used when wiring in the value. Key: XBEAN-36 URL: http://issues.apache.org/jira/browse/XBEAN-36 Project: XBean Issue Type: New Feature Components: spring Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 2.6 -- 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: (XBEAN-36) [RTC] Support annotating properties with the ProperyEditor that should be used when wiring in the value.
[ http://issues.apache.org/jira/browse/XBEAN-36?page=all ] Hiram Chirino updated XBEAN-36: --- Attachment: XBEAN-36.patch Attaching patch that implements the requirment. [RTC] Support annotating properties with the ProperyEditor that should be used when wiring in the value. Key: XBEAN-36 URL: http://issues.apache.org/jira/browse/XBEAN-36 Project: XBean Issue Type: New Feature Components: spring Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 2.6 Attachments: XBEAN-36.patch -- 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: (XBEAN-36) [RTC] Support annotating properties with the ProperyEditor that should be used when wiring in the value.
[ http://issues.apache.org/jira/browse/XBEAN-36?page=all ]
Hiram Chirino updated XBEAN-36:
---
Description:
This patch allows you to configure a PropertyEditor for any property. For
example, if you annotate a property as follows:
/**
* Sets the amount of beer remaining in the keg (in ml)
*
* @org.apache.xbean.Property
propertyEditor=org.apache.xbean.spring.example.MilliLittersPropertyEditor
* @param remaining
*/
public void setRemaining(long remaining) {
this.remaining = remaining;
}
Then when you configure the value of the 'remaining' property in xbean then the
MilliLittersPropertyEditor will be used to convert the string value to a long.
In the test case, our MilliLittersPropertyEditor can handle converting
different units of measurement to ml. For example:
beans xmlns:x=http://xbean.apache.org/schemas/pizza;
x:keg id=ml1000 remaining=1000 ml/
x:keg id=pints5 remaining=5 pints/
x:keg id=liter20 remaining=20 liter/
x:keg id=empty remaining=0/
/beans
[RTC] Support annotating properties with the ProperyEditor that should be
used when wiring in the value.
Key: XBEAN-36
URL: http://issues.apache.org/jira/browse/XBEAN-36
Project: XBean
Issue Type: New Feature
Components: spring
Reporter: Hiram Chirino
Assigned To: Hiram Chirino
Fix For: 2.6
Attachments: XBEAN-36.patch
This patch allows you to configure a PropertyEditor for any property. For
example, if you annotate a property as follows:
/**
* Sets the amount of beer remaining in the keg (in ml)
*
* @org.apache.xbean.Property
propertyEditor=org.apache.xbean.spring.example.MilliLittersPropertyEditor
* @param remaining
*/
public void setRemaining(long remaining) {
this.remaining = remaining;
}
Then when you configure the value of the 'remaining' property in xbean then
the MilliLittersPropertyEditor will be used to convert the string value to a
long. In the test case, our MilliLittersPropertyEditor can handle converting
different units of measurement to ml. For example:
beans xmlns:x=http://xbean.apache.org/schemas/pizza;
x:keg id=ml1000 remaining=1000 ml/
x:keg id=pints5 remaining=5 pints/
x:keg id=liter20 remaining=20 liter/
x:keg id=empty remaining=0/
/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
Re: [Review] Support per property PropertyEditors
I gave you one... Hiram Chirino wrote: Hi Everybody, I'm looking for 3 PMC +1s so that I can commit the patch attached to: http://issues.apache.org/jira/browse/XBEAN-36 It basically allows us to do things like: x:memoryManager limit=100 bytes/ x:memoryManager limit=1000 k/ x:memoryManager limit=20 Meg/ By annotating the property with a custom property editor that understands the bytes, k, Megs suffixes and knows how to create the right value. This would come in very handy in a couple of spots in the ActiveMQ configuration.
[jira] Commented: (XBEAN-33) [RTC] Add a new Wiki source generator that generates wiki markup so that reference docs can be pasted into confluence.
[ http://issues.apache.org/jira/browse/XBEAN-33?page=comments#action_12426009 ] Hiram Chirino commented on XBEAN-33: The one cool thing is that since we are moving to Confluence generated websites, this would produce reference documentation that has the same look and feel. [RTC] Add a new Wiki source generator that generates wiki markup so that reference docs can be pasted into confluence. -- Key: XBEAN-33 URL: http://issues.apache.org/jira/browse/XBEAN-33 Project: XBean Issue Type: RTC Components: spring, maven-plugin Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 2.6 Attachments: XBEAN-33.patch Added a new generator plugin. -- 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-1168) Bundle TranQL Oracle XA Driver
[ http://issues.apache.org/jira/browse/GERONIMO-1168?page=all ] Aaron Mulder closed GERONIMO-1168. -- Fix Version/s: 1.1 (was: 1.2) Resolution: Fixed Assignee: Aaron Mulder Currently available as a plugin Bundle TranQL Oracle XA Driver -- Key: GERONIMO-1168 URL: http://issues.apache.org/jira/browse/GERONIMO-1168 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: databases, connector Affects Versions: 1.0-M5 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.1 I hear that TranQL has an Oracle XA connector available, but it's not necessarily well-tested. I think it would be great to get a build of that into a Maven repo (presumably, under tranql/rars) so we can include it with Geronimo, list it in the console database pool UI, and get it some testing. (I don't think it's all that attractive to tell end users that if they want it they need to build it from source!) -- 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-2286) app client plan still uses Strings for dependency Module IDs
app client plan still uses Strings for dependency Module IDs Key: GERONIMO-2286 URL: http://issues.apache.org/jira/browse/GERONIMO-2286 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: application client, deployment Affects Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.2 The geronimo-application-client schema has: xs:complexType name=resourceType xs:sequence xs:choice xs:element name=external-rar type=xs:string/ xs:element name=internal-rar type=xs:string/ /xs:choice xs:element ref=connector:connector/ /xs:sequence /xs:complexType That would typically be used like this: resource external-rartranql/tranql-connector/1.2/rar/external-rar connector ... /resource Everywhere else we've changed elements holding module IDs to be of patternType, using separate groupId, artifactId, version, and type elements. There's no reason external-rar should still be a single slash-delimited String here (though internal-rar should be since it's presumably a path within the 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: [Review] Support per property PropertyEditors
Where's the property editor for bytes? Also can you add one for duration (e.g, ms, sec, minutes) -dain On Aug 5, 2006, at 4:24 PM, Hiram Chirino wrote: Hi Everybody, I'm looking for 3 PMC +1s so that I can commit the patch attached to: http://issues.apache.org/jira/browse/XBEAN-36 It basically allows us to do things like: x:memoryManager limit=100 bytes/ x:memoryManager limit=1000 k/ x:memoryManager limit=20 Meg/ By annotating the property with a custom property editor that understands the bytes, k, Megs suffixes and knows how to create the right value. This would come in very handy in a couple of spots in the ActiveMQ configuration. -- Regards, Hiram Blog: http://hiramchirino.com
Re: [Review] Support per property PropertyEditors
BTW I voted +1 for what is already in the patch. -dain On Aug 5, 2006, at 5:20 PM, Dain Sundstrom wrote: Where's the property editor for bytes? Also can you add one for duration (e.g, ms, sec, minutes) -dain On Aug 5, 2006, at 4:24 PM, Hiram Chirino wrote: Hi Everybody, I'm looking for 3 PMC +1s so that I can commit the patch attached to: http://issues.apache.org/jira/browse/XBEAN-36 It basically allows us to do things like: x:memoryManager limit=100 bytes/ x:memoryManager limit=1000 k/ x:memoryManager limit=20 Meg/ By annotating the property with a custom property editor that understands the bytes, k, Megs suffixes and knows how to create the right value. This would come in very handy in a couple of spots in the ActiveMQ configuration. -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Commented: (XBEAN-36) [RTC] Support annotating properties with the ProperyEditor that should be used when wiring in the value.
[
http://issues.apache.org/jira/browse/XBEAN-36?page=comments#action_12426011 ]
Matt Hogstrom commented on XBEAN-36:
+1
[RTC] Support annotating properties with the ProperyEditor that should be
used when wiring in the value.
Key: XBEAN-36
URL: http://issues.apache.org/jira/browse/XBEAN-36
Project: XBean
Issue Type: New Feature
Components: spring
Reporter: Hiram Chirino
Assigned To: Hiram Chirino
Fix For: 2.6
Attachments: XBEAN-36.patch
This patch allows you to configure a PropertyEditor for any property. For
example, if you annotate a property as follows:
/**
* Sets the amount of beer remaining in the keg (in ml)
*
* @org.apache.xbean.Property
propertyEditor=org.apache.xbean.spring.example.MilliLittersPropertyEditor
* @param remaining
*/
public void setRemaining(long remaining) {
this.remaining = remaining;
}
Then when you configure the value of the 'remaining' property in xbean then
the MilliLittersPropertyEditor will be used to convert the string value to a
long. In the test case, our MilliLittersPropertyEditor can handle converting
different units of measurement to ml. For example:
beans xmlns:x=http://xbean.apache.org/schemas/pizza;
x:keg id=ml1000 remaining=1000 ml/
x:keg id=pints5 remaining=5 pints/
x:keg id=liter20 remaining=20 liter/
x:keg id=empty remaining=0/
/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] Commented: (XBEAN-36) [RTC] Support annotating properties with the ProperyEditor that should be used when wiring in the value.
[
http://issues.apache.org/jira/browse/XBEAN-36?page=comments#action_12426012 ]
David Jencks commented on XBEAN-36:
---
RTC +1
[RTC] Support annotating properties with the ProperyEditor that should be
used when wiring in the value.
Key: XBEAN-36
URL: http://issues.apache.org/jira/browse/XBEAN-36
Project: XBean
Issue Type: New Feature
Components: spring
Reporter: Hiram Chirino
Assigned To: Hiram Chirino
Fix For: 2.6
Attachments: XBEAN-36.patch
This patch allows you to configure a PropertyEditor for any property. For
example, if you annotate a property as follows:
/**
* Sets the amount of beer remaining in the keg (in ml)
*
* @org.apache.xbean.Property
propertyEditor=org.apache.xbean.spring.example.MilliLittersPropertyEditor
* @param remaining
*/
public void setRemaining(long remaining) {
this.remaining = remaining;
}
Then when you configure the value of the 'remaining' property in xbean then
the MilliLittersPropertyEditor will be used to convert the string value to a
long. In the test case, our MilliLittersPropertyEditor can handle converting
different units of measurement to ml. For example:
beans xmlns:x=http://xbean.apache.org/schemas/pizza;
x:keg id=ml1000 remaining=1000 ml/
x:keg id=pints5 remaining=5 pints/
x:keg id=liter20 remaining=20 liter/
x:keg id=empty remaining=0/
/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
Re: [Review] Support per property PropertyEditors
I've also voted, with matt's you have 3. Jeff, I think it would be clearer if we not only voted but commented that it's a RTC +1 vote. Do we have a policy on this? I think I saw it discussed somewhere thanks david jencks On Aug 5, 2006, at 4:27 PM, Jeff Genender wrote: I gave you one... Hiram Chirino wrote: Hi Everybody, I'm looking for 3 PMC +1s so that I can commit the patch attached to: http://issues.apache.org/jira/browse/XBEAN-36 It basically allows us to do things like: x:memoryManager limit=100 bytes/ x:memoryManager limit=1000 k/ x:memoryManager limit=20 Meg/ By annotating the property with a custom property editor that understands the bytes, k, Megs suffixes and knows how to create the right value. This would come in very handy in a couple of spots in the ActiveMQ configuration.
Remove server-environment from app client
Currently, the application client plan has both a client-environment and a server-environment. These can have separate module IDs and separate classpath modifiers. The client-environment is used for when you run the application client in the application client container (which is essentially a stripped-down Geronimo runtime). The server-environment is used to create a JSR-77 GBean representing the application client, on the server side. That is, the module ID is used as part of the GBean name for the JSR-77 GBean, and the class path is used to run the JSR-77 GBean. There was apparently some thought that the client might be able to list GBeans that should run on the server side using that class path and module ID as well, but that was never implemented. So here are my claims: * There's no need to have different module IDs on the client side and server side. The JSR-77 GBean and app client container GBeans could all use the same module ID for GBeans associated with the same app client. * If an application client wants code to run on the server side, it should be packaged in an EAR, and the EAR's environment, classpath, and GBeans would be used on the server side. * It's not workable for a standalone (non-EAR) app client to include server-side code. What happens, for example, if you have different Geronimo installations for the client and server, and only deploy the app client in your client Geronimo installation? It can talk to code (e.g. remote EJBs) running in the server, but how can it possibly cause GBeans or other code to be run on the server which are defined and available only in the client's Geronimo installation? That being the case, I'd like to remove the server-environment. The impact here is that the client container GBeans and JSR-77 GBean for the app client would all use the same Module ID for the app client in question, and we'd always use a fixed classpath for the JSR-77 GBean representing the app client. We'd keep the client-environment (as is, or renamed to just environment like in all the other plans) to hold that module ID and to customize the client-side class path. Any objections? I would consider this for the 1.2-or-later timeframe since it involves plan format changes and there's no pressing need to undertake this in 1.1.x. Thanks, Aaron P.S. My first claim is unproven -- there may actually currently be a problem if the JSR-77 GBean and app client container GBeans use the same module ID. If we agree to the change in principle, we can investigate and if necessary fix any conflicts, to avoid needing two different module IDs to refer to the same app client.
[jira] Created: (GERONIMO-2287) Error in Connector schema header documentation
Error in Connector schema header documentation
--
Key: GERONIMO-2287
URL: http://issues.apache.org/jira/browse/GERONIMO-2287
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: connector, deployment
Affects Versions: 1.1
Reporter: Aaron Mulder
Fix For: 1.1.x
The geronimo-connector schema has this in the header:
{noformat}
xs:annotation
xs:documentation
![CDATA[
documents using this schema should start like:
connector xmlns=http://geronimo.apache.org/xml/ns/j2ee/connector-1.1;
version=1.5
@(#)geronimo-connector_1_5.xsds
]]
/xs:documentation
/xs:annotation
{noformat}
That is incorrect in that there is no longer a version attribute on the
connector element. Also, I'm really unsure what
@(#)geronimo-connector_1_5.xsds means. I think we should simplify to
something like
{noformat}
xs:annotation
xs:documentation
![CDATA[
XML Schema for the Geronimo deployment plan for a J2EE Connector.
Documents using this schema should start like:
connector xmlns=http://geronimo.apache.org/xml/ns/j2ee/connector-1.1;
If the plan is packaged in the connector RAR file it should appear
at
META-INF/geronimo-ra.xml
]]
/xs:documentation
/xs:annotation
{noformat}
--
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: Maven2... we are almost there!
I'd like to see us damn the torpedoes and full speed ahead with M2. +1 for moving to XMLBeans 2.2 Aaron Mulder wrote: On 8/5/06, David Jencks [EMAIL PROTECTED] wrote: I'm not actually sure that there's a released m2 xmlbeans 2.2 plugin either, and I'd rather get the poms for xmlbeans 2.2 straightened out properly before there is. Maybe I can get this process to move along a bit. Effectively, there's not a released xmlbeans 2.0 m2 plugin right? I thought we had to use the snapshot of the xmlbeans 2.0 plugin to avoid the crazy dependency issues that result in the first build of an xmlbeans module failing but the second passing. Anyway, I'm happy to abandon the M1 build and go with XMLBeans 2.2. Thanks, Aaron See http://issues.apache.org/jira/browse/XMLBEANS-120 for this problem and that its fixed ;-) Jeff Jeff Genender wrote: The mvn eclipse:eclipse has big issues with the xmlbeans generated classes (I wrote a hack in our maven 1 build to deal with this). Have you gotten this to work? Thanks, jeff Jason Dillon wrote: I have finished merging svkmerge/m2migration to trunk. Now it is time for everyone to start using the m2 build... and avoid using the m1 build. I updated the docs here which explain what you must do: http://cwiki.apache.org/GMOxDEV/building-apache-geronimo-with- maven-2.html You should bootstrap at least once. This is temporary and will be removed soon. * * * Please, please, please start using the m2 build. If for some reason you end up going back to m1 please let us know so we can fix it. The last major issue left unresolved (that I am ware of) is the car plugins support for geronimo-plugin.xml fluff, which I am working on resolving. --jason
[jira] Closed: (GERONIMO-2285) Console Show Plan screens have bad EAR plan in advice
[ http://issues.apache.org/jira/browse/GERONIMO-2285?page=all ]
Aaron Mulder closed GERONIMO-2285.
--
Fix Version/s: 1.2
Resolution: Fixed
Console Show Plan screens have bad EAR plan in advice
-
Key: GERONIMO-2285
URL: http://issues.apache.org/jira/browse/GERONIMO-2285
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security, ActiveMQ, console, databases
Affects Versions: 1.1
Reporter: Aaron Mulder
Assigned To: Aaron Mulder
Fix For: 1.1.2, 1.2
The JDBC show plan page shows:
{code:xml}
application
xmlns=http://geronimo.apache.org/xml/ns/j2ee/application-1.0;
configId=MyApplication
module
connectorrar-file-name.rar/connector
alt-ddplan-file-name.xml/alt-dd
/module
/application
{code}
The JMS and security realm Show Plan pages have similar errors.
--
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: [Review] Support per property PropertyEditors
David Jencks wrote: I've also voted, with matt's you have 3. Jeff, I think it would be clearer if we not only voted but commented that it's a RTC +1 vote. Do we have a policy on this? I think I saw it discussed somewhere Yep...good point...I needed to do that. I have been *really* busy lately, so it slipped by...sorry about that. I will update it now. Jeff thanks david jencks On Aug 5, 2006, at 4:27 PM, Jeff Genender wrote: I gave you one... Hiram Chirino wrote: Hi Everybody, I'm looking for 3 PMC +1s so that I can commit the patch attached to: http://issues.apache.org/jira/browse/XBEAN-36 It basically allows us to do things like: x:memoryManager limit=100 bytes/ x:memoryManager limit=1000 k/ x:memoryManager limit=20 Meg/ By annotating the property with a custom property editor that understands the bytes, k, Megs suffixes and knows how to create the right value. This would come in very handy in a couple of spots in the ActiveMQ configuration.
[jira] Commented: (XBEAN-36) [RTC] Support annotating properties with the ProperyEditor that should be used when wiring in the value.
[
http://issues.apache.org/jira/browse/XBEAN-36?page=comments#action_12426015 ]
Jeff Genender commented on XBEAN-36:
+1
[RTC] Support annotating properties with the ProperyEditor that should be
used when wiring in the value.
Key: XBEAN-36
URL: http://issues.apache.org/jira/browse/XBEAN-36
Project: XBean
Issue Type: New Feature
Components: spring
Reporter: Hiram Chirino
Assigned To: Hiram Chirino
Fix For: 2.6
Attachments: XBEAN-36.patch
This patch allows you to configure a PropertyEditor for any property. For
example, if you annotate a property as follows:
/**
* Sets the amount of beer remaining in the keg (in ml)
*
* @org.apache.xbean.Property
propertyEditor=org.apache.xbean.spring.example.MilliLittersPropertyEditor
* @param remaining
*/
public void setRemaining(long remaining) {
this.remaining = remaining;
}
Then when you configure the value of the 'remaining' property in xbean then
the MilliLittersPropertyEditor will be used to convert the string value to a
long. In the test case, our MilliLittersPropertyEditor can handle converting
different units of measurement to ml. For example:
beans xmlns:x=http://xbean.apache.org/schemas/pizza;
x:keg id=ml1000 remaining=1000 ml/
x:keg id=pints5 remaining=5 pints/
x:keg id=liter20 remaining=20 liter/
x:keg id=empty remaining=0/
/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] Updated: (GERONIMO-2277) Remove TransactionContextManager
[ http://issues.apache.org/jira/browse/GERONIMO-2277?page=all ] Dain Sundstrom updated GERONIMO-2277: - Attachment: GERONIMO-2277.patch I merged all changes from head back into notcm and fixed the m2 build. I also made a few changes noted below based on requests for David. I suggest you test the notcm branch directly. If you want to try the merge, use the same command as before, and you'll have to resolve some conflicts (I have no idea why svn marks them as conflicts). Here are the commands I used: svn co https://svn.apache.org/repos/asf/geronimo/trunk geronimo cd geronimo svn merge -r 427246:HEAD https://svn.apache.org/repos/asf/geronimo/branches/dain/notcm . # resolve the conflicts by taking the files from notcm mv bootstrap.merge-right* \ bootstrap svn resolved bootstrap chmod u+x bootstrap mv pom.xml.merge-right* \ pom.xml svn resolved pom.xml mv m2-assemblies/geronimo-boilerplate-j2ee/src/main/resources/var/security/keystores/geronimo-default.merge-right* \ m2-assemblies/geronimo-boilerplate-j2ee/src/main/resources/var/security/keystores/geronimo-default svn resolved m2-assemblies/geronimo-boilerplate-j2ee/src/main/resources/var/security/keystores/geronimo-default mv m2-assemblies/geronimo-boilerplate-minimal/src/main/resources/var/security/keystores/geronimo-default.merge-right* \ m2-assemblies/geronimo-boilerplate-minimal/src/main/resources/var/security/keystores/geronimo-default svn resolved m2-assemblies/geronimo-boilerplate-minimal/src/main/resources/var/security/keystores/geronimo-default # run the m2 build or run the m1 build ./bootstrap mvn clean install # maven new Remove TransactionContextManager Key: GERONIMO-2277 URL: http://issues.apache.org/jira/browse/GERONIMO-2277 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: transaction manager Reporter: Dain Sundstrom Assigned To: Dain Sundstrom Fix For: 1.2 Attachments: GERONIMO-2277.patch If you use the Geronimo TransactionContextManager, you can't use the TransactionManager interface directly since the TCM needs to know about all TM calls. Additionally, to use the TCM you must demarcate all changes in component context by starting an unspecified transaction context. This is all quite invasive and makes it hard to use our code in third part environments such as Spring or plain old Tomcat. I propose we remove the TransactionContextManager and replaced all uses with a plain old TransactionManager. This will also allow us to removed all code from web containers, app client and timer that was simply demarcating an unspecified transaction context, which is no longer needed. -- 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: (XBEAN-37) Compile error in QdoxMappingLoader introduced in XBEAN-27
Compile error in QdoxMappingLoader introduced in XBEAN-27 - Key: XBEAN-37 URL: http://issues.apache.org/jira/browse/XBEAN-37 Project: XBean Issue Type: Bug Components: spring Reporter: John Sisson Assigned To: John Sisson Priority: Blocker Fix For: 2.6 Seems this compile error slipped through the RTC on the XBEAN-27 patch! C:\dev\geronimo\xbean\trunkmvn install SNIP [INFO] [INFO] Building XBean :: Spring :: Common [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] Compiling 42 source files to C:\dev\geronimo\xbean\trunk\xbean-spring-common\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\dev\geronimo\xbean\trunk\xbean-spring-common\src\main\java\org\apache\xbean\spring\generator\QdoxMappingLoader.java:[507,29] repl ace(char,char) in java.lang.String cannot be applied to (java.lang.String,java.lang.String) -- 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
