[jira] Commented: (GERONIMO-2537) All Geronimo source files must be brought in line with the new ASF source header and copyright notice policy
[ http://issues.apache.org/jira/browse/GERONIMO-2537?page=comments#action_12446850 ] Jacek Laskowski commented on GERONIMO-2537: --- Assemblies got a shot as well. All Geronimo source files must be brought in line with the new ASF source header and copyright notice policy Key: GERONIMO-2537 URL: http://issues.apache.org/jira/browse/GERONIMO-2537 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Affects Versions: 1.1.2, 1.2 Reporter: Kevan Miller Assigned To: Jacek Laskowski Priority: Blocker Fix For: 1.1.2, 1.2 The ASF has new requirements for Source headers and copyright notices. See http://www.apache.org/legal/src-headers.html for details. All releases after November 1, 2006 must comply with this policy. It seems that 1.2 will be post November 1... :-) All Geronimo source files in trunk must be brought in line with this new policy... If we create a 1.1.2 release, we need to insure that all src files in branches/1.1 are brought inline with this new policy, also. There seem to be some scripts that will aid with these updates (see the FAQ in the above url). However, I can't access them at the moment... -- 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-2192) Jetty can't handle encoded urls that contain a jsessionid
[ http://issues.apache.org/jira/browse/GERONIMO-2192?page=comments#action_12446855 ] Nikla Ratinen commented on GERONIMO-2192: - Hello, Did you ever find a workaround for this one? I'm experiencing the same issue. Jetty also outputs something like Alias request of '/foo/bar.jsp;jsessionid=xxx' for '/foo/bar.jsp;jsessionid=xxx' to the log. This does happen whenever the session is first created - at that time container cannot know if the cookies are enabled or not so it both writes a cookie and encodes all URL's - which is a correct behaviour. I think it might help to enable alias serving according to http://docs.codehaus.org/display/JETTY/How+to+enable+serving+aliased+files but I have no clue on how to conf this in Geronimo. Cheers, -- Nikla Jetty can't handle encoded urls that contain a jsessionid - Key: GERONIMO-2192 URL: http://issues.apache.org/jira/browse/GERONIMO-2192 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.1 Environment: Geronimo 1.1, Jetty version; Sun JDK 1.5_4, OpenSuSE 10.1, 712 MB RAM Reporter: D. Strauss Priority: Critical Hello, another testing here was to check if a webapp would still be usable when the user blocks any cookies from us. JEE typically uses a cookie named JSESSIONID (I think this is specified somewhere) to identify a user at a web request time. Now, if cookies are blocked, the developers are instructed to encode the urls using the HttpServletResponse.encode() method. Even the JSTL and c:url use this behaviour (fortunately :P). Anyway, today, Jetty had some problems when cookies are blocked. The urls are encoded at request time, so, a url like /register.jspx becomes /register.jspx;jsessionid=long hexadecimal value Using Tomcat, everything works as expected (i.e. the user gets identified as long as he/she uses the session identifier). Jetty, on the other hand, drops the request with a HTTP 404 error telling that it can't find a file named register.jspx;jsessionid=long value. This is, of course, right. However, it's not the expected behaviour. Seems that Jetty can't figure out that this request is encoded ... -- 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-2537) All Geronimo source files must be brought in line with the new ASF source header and copyright notice policy
[ http://issues.apache.org/jira/browse/GERONIMO-2537?page=comments#action_12446858 ] Jacek Laskowski commented on GERONIMO-2537: --- Applications done too. All Geronimo source files must be brought in line with the new ASF source header and copyright notice policy Key: GERONIMO-2537 URL: http://issues.apache.org/jira/browse/GERONIMO-2537 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Affects Versions: 1.1.2, 1.2 Reporter: Kevan Miller Assigned To: Jacek Laskowski Priority: Blocker Fix For: 1.1.2, 1.2 The ASF has new requirements for Source headers and copyright notices. See http://www.apache.org/legal/src-headers.html for details. All releases after November 1, 2006 must comply with this policy. It seems that 1.2 will be post November 1... :-) All Geronimo source files in trunk must be brought in line with this new policy... If we create a 1.1.2 release, we need to insure that all src files in branches/1.1 are brought inline with this new policy, also. There seem to be some scripts that will aid with these updates (see the FAQ in the above url). However, I can't access them at the moment... -- 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-2448) Add ServiceModules group in the JMX tree of the JMX portlet
[ http://issues.apache.org/jira/browse/GERONIMO-2448?page=all ] Christopher M. Cardona closed GERONIMO-2448. Resolution: Fixed patch applied Add ServiceModules group in the JMX tree of the JMX portlet --- Key: GERONIMO-2448 URL: http://issues.apache.org/jira/browse/GERONIMO-2448 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Reporter: Christopher M. Cardona Assigned To: Christopher M. Cardona Fix For: 1.2 Attachments: GERONIMO-2448.jpg, GERONIMO-2448_2471_2472-trunk.patch Add ServiceModules group in the JMX tree of the JMX portlet. Adding this will enable a user to list / view MBeans grouped by service modules as suggested in the devlist - http://www.mail-archive.com/dev@geronimo.apache.org/msg33687.html. -- 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-2472) Remove the display of GBeanInfo attribute in the JMX portlet
[ http://issues.apache.org/jira/browse/GERONIMO-2472?page=all ] Christopher M. Cardona closed GERONIMO-2472. Resolution: Fixed Remove the display of GBeanInfo attribute in the JMX portlet Key: GERONIMO-2472 URL: http://issues.apache.org/jira/browse/GERONIMO-2472 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: Christopher M. Cardona Assigned To: Christopher M. Cardona Priority: Minor Fix For: 1.2 Attachments: GERONIMO-2471_2472-trunk.patch When viewing MBean's attributes in the JMX portlet we should exclude GBeanInfo attributes. This was suggested in the devlist. -- 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-2471) JMX Portlet doesn't display all the attributes of a web module
[ http://issues.apache.org/jira/browse/GERONIMO-2471?page=all ] Christopher M. Cardona closed GERONIMO-2471. Resolution: Fixed Patch applied for this issue. Please file a different jira for non-related additional work. JMX Portlet doesn't display all the attributes of a web module -- Key: GERONIMO-2471 URL: http://issues.apache.org/jira/browse/GERONIMO-2471 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.2 Reporter: Christopher M. Cardona Assigned To: Anita Kulshreshtha Fix For: 1.2 Attachments: GERONIMO-2471_2472-trunk.patch Viewing a web module doesn't display all its attributes. -- 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-1823) Add Embedded LDAP Server Viewer Portlet
[ http://issues.apache.org/jira/browse/GERONIMO-1823?page=all ] Christopher M. Cardona reassigned GERONIMO-1823: Assignee: Christopher M. Cardona Add Embedded LDAP Server Viewer Portlet --- Key: GERONIMO-1823 URL: http://issues.apache.org/jira/browse/GERONIMO-1823 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: console Affects Versions: 1.2 Reporter: Christopher M. Cardona Assigned To: Christopher M. Cardona Attachments: dojo-0.3.1-bin.zip, GERONIMO-1823-trunk2.patch, GERONIMO-1823-trunk3.patch, ldapMgrPortlet-B1.1.1.jpg, ldapMgrPortlet-B1.1.1.patch, ldapMgrPortlet-Snapshot.zip, ldapMgrPortlet.patch, ldapviewer-jetty-1.2-SNAPSHOT.car, ldapviewer-portlet-1.2-SNAPSHOT.jpg, ldapviewer-tomcat-1.2-SNAPSHOT.car, ldapviewer-webapp-1.2-SNAPSHOT.jpg, sample.ldif Add a new portlet for viewing the contents of the embedded directory server (Apache DS). This portlet will be under 'Misc' portlets. -- 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-2274) realm-principal does not work in web app security
[ http://issues.apache.org/jira/browse/GERONIMO-2274?page=all ] Vamsavardhana Reddy closed GERONIMO-2274. - Resolution: Fixed Assignee: Vamsavardhana Reddy (was: Alan Cabrera) Fixed. Rev 470703 (branches\1.1) and Rev 470733 (trunk). realm-principal does not work in web app security - Key: GERONIMO-2274 URL: http://issues.apache.org/jira/browse/GERONIMO-2274 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 1.1 Environment: WinXP, G1.1.1-SNAPSHOT, Tomcat Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: 1.1.2, 1.2 Attachments: Geronimo-2274-tester.zip, GERONIMO-2274.patch, geronimo-web.xml, sql-realm-advanced.xml I have deployed a security realm with wrap-principals set to true. Then, I have deployed a web application to authenticate against this security realm. In the web app deployment plan, I have used realm-principal in role mapping. Even though login is successful, I am getting Error HTTP 403 Forbidden. Authorization works as expected if I use login-domain-principal or principal instead of realm-principal. Appears like realm-principal is not working as expected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: geronimo-online-deploy configuration classpath missing server.jar... offline deployer broken
I think either removing geronimo-deployment from the manifest cp or adding xmlbeans jar will solve this problem. I don't think the former will work and I really don't like the latter. Maybe we can split up geronimo-deployment jar into a remote piece and a local piece? This may take some more investigation meanwhile temporarily adding xmlbeans to lib and the cp might get this going for now.thanksdavid jencksOn Nov 2, 2006, at 4:58 PM, Sachin Patel wrote:So after being able to bootstrap the j2ee-system configuration, we are running into a NoClassDef exception on XMLObject when attempting to start the gbean-deployer configuration. Comparing the gbean-deployer config to 1.1.1, it looks like a GBeanBuilder bean was introduced in the plan, and this happens to be the gbean that fails to load and causes the exception. The Deployer and ServiceConfigBuilder gbeans prior to it seem to load successfully (which is strange since ServiceConfigBuilder imports XMLObject as well). So on GBeanBuilder when attempting to construct the GBeanInstance and the GBeanAttribute for GBeanInfo for (Iterator iterator = gbeanInfo.getAttributes().iterator(); iterator.hasNext();) { GAttributeInfo attributeInfo = (GAttributeInfo) iterator.next(); attributesMap.put(attributeInfo.getName(), new GBeanAttribute(this, attributeInfo, constructorArgs.contains(attributeInfo.getName(; }The exception is thrown on line 249 in the constructor of GBeanAttribute getInvoker = new FastMethodInvoker(getterMethod);But I seem to be at a dead end here. :( Any ideas why this is failing?On Nov 1, 2006, at 7:04 PM, David Jencks wrote:I came up with a proposed solution and put it in GERONIMO-2539. I think I'm about to need this facility also :-)Take a look, see if it can be improved, see if it works :-)jdillon, does this look OK to you?thanksdavid jencksOn Nov 1, 2006, at 11:15 AM, Sachin Patel wrote:I'm trying to get the offline deployer back working in trunk, the problem is when starting the kernel with the using j2ee-system as the bootstrap configuration, when locating "META-INF"/config.ser" resources only deployer.jar is located having this resource and thus the j2ee-system config cannot be found and the bootstrap fails. When debugging through 1.1.1, both server.jar and deployer.jar were found. So comparing the online-deployer configuration in trunk against 1.1.1, the culprit seems to be that server.jar is missing in the configuration's manifest as a classpath entry. This was specified in the project.properties in 1.1.1. Since it looks as if in trunk we are relying purely on the car-maven-plugin to build the manifest's classpath, since server.jar is not technically an artifact, if failed to add as an entry.Is there a way I don't know about to add this? Or do we need to update the car-maven-plugin to allow it?thx-sachin -sachin
Re: important: License issues in Geronimo 1.0 Samples
Hi Hernan, Actually here I am missed something here. So first of all apologies for that. Regarding this issue I have contacted somebody who knows open source than me. He explained me that I can edit this source code without any issue, since you have granted me that ability as the author. In that case Kevin's argument is more of theoretical than practical one. Am I correct? If you need I can go ahead with the editing for you :-) . Sorry for dragging this issue so much. Now I am learning about open source licenses. ;-) Thanks, Lasantha Ranaweera Hernan Cunico wrote: As I said, I worked with other folks on those samples and I submitted the patch into JIRA granting ASL, that's why I asked you if you could fix the headers in the docs you were updating. I wasn't asking for anything weird as you suggested in a previous email, but you're right, I should probably go fix all those src myself. I will work on a doc about granting license to ASF for all the docs and attachments and put a link on Geronimo's cwiki homepage. The license issue does not apply only to the samples but to the doc and images altogether. Cheers! Hernan [EMAIL PROTECTED] wrote: If those sample are added with JIRA then it won't be that much of big problem because contributor knows it goes under ASL. I thought it might have added as the current way of confluence itself. Even though it might not add the license information to the source code I think it is very important to let the contributor know that they are donating their materials under ASL. JIRA handles that issue atleast ;). Thanks, Lasantha Ranaweera Lasantha, I either wrote or co-authored all those docs and the headers in question skipped my attention at that time. I know for sure they were not there in the first releases of those samples as we were developing them. Apparently those headers were added at a later time. Either way those samples as well as the entire documentation were made available in JIRA GERONIMO-1357 granting ASL to all the content. But clicking the ASL check box in JIRA does not add any license info to the attached files. As for Confluence itself, in the autoexported version you can read at the bottom of each page Copyright © 2003-2006, The Apache Software Foundation. Maybe this is not enough. Confluence is just a wiki and there is no way (without major surgery) to modify the attachments page so we can click an ASL check box. Even if there is one there would be no chance to add any ASL related info to the actual files. I don't know what the solution would be so I'm open to suggestions. Cheers! Hernan [EMAIL PROTECTED] wrote: Hi Hernan, I can't add those modifications to the samples with propriety licenses, you know it is not illegal and ethical :(. Sure I can add this Apache licence to the samples I had written. Also one more question. Can I add this license to other existing samples? Somewhere I heard we can't change the distributed license to any other license. Confluence is bit different than JIRA, nobody accepts ASF licences before their commiting. I haven't come across this situation at all. Please help. Thanks, Lasantha Ranaweera Lasantha, those samples were donated to the project ergo they should only display ASF2 license. This is the text we have in trunk today !-- Copyright 2006 The Apache Software Foundation Licensed 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. -- Could you please remove the unnecessary (old) data and comments and add the appropriate lines to each of the files for all the samples you are updating. http://www.apache.org/licenses may give you some additional tips. Thanks for taking care of this. Cheers! Hernan Lasantha Ranaweera wrote: Sorry to send it again. This is an important issue. Have a look at the attached file. I have stuck here whether to reuse this sample or not. :-\ Lasantha Ranaweera wrote: Hi All, Past few days I have been upgrading JBoss to Apache Geronimo samples from v1.0 of the documentation to v1.1. As part of the upgrade procedure, when I was looking at one of the samples I found something that grabbed my attention in the existing JBoss to Geronimo sample applications. Have a look at JBoss to Geronimo - Security Migration in following url: http://cwiki.apache.org/confluence/display/GMOxDOC10/JBoss+to+Geronimo+-+Security+Migration Source code of this sample contains some proprietary license. So we can't do any editing this sample. Isn't
G-style for Nabble forums?
Anyone want to take a stab at making the G forums on Nabble look like the main G site? Kinda like the Maven forums: http://www.nabble.com/Maven---Users-f178.html Else... I will look into this once I have some free time away from build muck. --jason
[jira] Created: (GERONIMO-2542) Writing XML schema documentation for geronimo-web in distribution
Writing XML schema documentation for geronimo-web in distribution - Key: GERONIMO-2542 URL: http://issues.apache.org/jira/browse/GERONIMO-2542 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: documentation Affects Versions: 1.x Environment: Debian Reporter: Kanchana Welagedara Assigned To: Kanchana Welagedara Fix For: Verification Required XML Schema documentation has been updated in the web but not in the schema in the geronimo distribution.This has the patch which improved the documentation geronimo-web.xsd . -- 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-2537) All Geronimo source files must be brought in line with the new ASF source header and copyright notice policy
[ http://issues.apache.org/jira/browse/GERONIMO-2537?page=comments#action_12446897 ] Jacek Laskowski commented on GERONIMO-2537: --- Al sources migrated. Needs verifying. All Geronimo source files must be brought in line with the new ASF source header and copyright notice policy Key: GERONIMO-2537 URL: http://issues.apache.org/jira/browse/GERONIMO-2537 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Affects Versions: 1.1.2, 1.2 Reporter: Kevan Miller Assigned To: Jacek Laskowski Priority: Blocker Fix For: 1.1.2, 1.2 The ASF has new requirements for Source headers and copyright notices. See http://www.apache.org/legal/src-headers.html for details. All releases after November 1, 2006 must comply with this policy. It seems that 1.2 will be post November 1... :-) All Geronimo source files in trunk must be brought in line with this new policy... If we create a 1.1.2 release, we need to insure that all src files in branches/1.1 are brought inline with this new policy, also. There seem to be some scripts that will aid with these updates (see the FAQ in the above url). However, I can't access them at the moment... -- 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-2318) Database path validation not present
[ http://issues.apache.org/jira/browse/GERONIMO-2318?page=comments#action_12446918 ] Vamsavardhana Reddy commented on GERONIMO-2318: --- The problem is in java.lang.String.replaceAll(regex, value) method. When there is a back-slash (\) in the value parameter, this method does not work as expected. One workaround is to first url-encode value parameter and then url-decode the final output as given below: value= URLEncode.encode(value) out = out.replaceAll(regex, value); out = URLDecode.decode(out); Comments? Database path validation not present Key: GERONIMO-2318 URL: http://issues.apache.org/jira/browse/GERONIMO-2318 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.2, 1.1, 1.1.1, 1.1.2 Environment: All Supported Platforms Reporter: Manu T George Fix For: 1.2, 1.1.2 Attachments: G2318-1.1.1.patch On deploying pools referring to derby databases. Deployment is shown to be sucessful but the pool does not start. Steps are given below (1)Logged into Administrative Console. (2)Clicked Database Pools. (3) Next, clicked Create a new database pool: Using the Geronimo database pool wizard. (4)Entered Name of Database Pool: CPRO and Database Type: Derby Embedded. Then clicked Next. (5)Thereafter entered the following:- JDBC Driver Class: org.apache.derby.jdbc.EmbeddedDriver Driver JAR: org.apache.derby/derby/10.1.2.ibm/jar DB Username: cpro DB Password: cpro Database: c:\cprodb\cprodb_COSMO\csdb Then clicked Next. (5)The next screen showed:- JDBC Connection URL: jdbc:derby:c:cprodbcprodb_COSMOcsdb (This being incorrect, it was changed to jdbc:derby:c:\cprodb\cprodb_COSMO\csdb). (6)Driver Status: Loaded successfully (7)Now clicked Test Connection. This showed:- Test Result: Connected to Apache Derby 10.1.2.4 (8)Finally clicked Deploy It appears that this step was successful because:- (i)The DOS window showed Deployment completed successfully! Even though this happens when we refer to this DB Pool in an application error occurs. Thus there is no handling of '\' character in these two fields Giving '/' instead of '\' solves this issue -- 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: svn commit: r470597 [1/6] - in /geronimo/server/trunk/modules: geronimo-activemq-gbean/src/main/java/org/apache/activemq/gbean/ geronimo-activemq-gbean/src/main/java/org/apache/activemq/gbean/mana
On 11/3/06, Jason Dillon [EMAIL PROTECTED] wrote: It should would be nice to get ride of the extra *\n in the header: snip /** * * Licensed to the Apache Software Foundation (ASF) under one or more /snip This what I have been putting in headers that I have changed: snip /** * Licensed to the Apache Software Foundation (ASF) under one or more /snip Well, if I knew Perl as much as it's required to do so, I'd go for it ;-) The script I'm using is committers/tools/copy2license.pl. Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
[jira] Commented: (GERONIMO-2192) Jetty can't handle encoded urls that contain a jsessionid
[ http://issues.apache.org/jira/browse/GERONIMO-2192?page=comments#action_12446924 ] Nikla Ratinen commented on GERONIMO-2192: - Seems like a Jetty bug; maybe related to this one: http://jira.codehaus.org/browse/JETTY-38 BTW for me the issue occurred with AJP. Replacing Jetty with version 5.1.11 works for me - not sure about any other side effects though. Cheers, -- Nikla Jetty can't handle encoded urls that contain a jsessionid - Key: GERONIMO-2192 URL: http://issues.apache.org/jira/browse/GERONIMO-2192 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.1 Environment: Geronimo 1.1, Jetty version; Sun JDK 1.5_4, OpenSuSE 10.1, 712 MB RAM Reporter: D. Strauss Priority: Critical Hello, another testing here was to check if a webapp would still be usable when the user blocks any cookies from us. JEE typically uses a cookie named JSESSIONID (I think this is specified somewhere) to identify a user at a web request time. Now, if cookies are blocked, the developers are instructed to encode the urls using the HttpServletResponse.encode() method. Even the JSTL and c:url use this behaviour (fortunately :P). Anyway, today, Jetty had some problems when cookies are blocked. The urls are encoded at request time, so, a url like /register.jspx becomes /register.jspx;jsessionid=long hexadecimal value Using Tomcat, everything works as expected (i.e. the user gets identified as long as he/she uses the session identifier). Jetty, on the other hand, drops the request with a HTTP 404 error telling that it can't find a file named register.jspx;jsessionid=long value. This is, of course, right. However, it's not the expected behaviour. Seems that Jetty can't figure out that this request is encoded ... -- 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-2542) Writing XML schema documentation for geronimo-web in distribution
[ http://issues.apache.org/jira/browse/GERONIMO-2542?page=all ] Kanchana Welagedara updated GERONIMO-2542: -- Attachment: geronimo-web-1.1.xsd geronimo-web.xsd documentation in the distribution improved for version 1.1 Writing XML schema documentation for geronimo-web in distribution - Key: GERONIMO-2542 URL: http://issues.apache.org/jira/browse/GERONIMO-2542 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: documentation Affects Versions: 1.x Environment: Debian Reporter: Kanchana Welagedara Assigned To: Kanchana Welagedara Fix For: Verification Required Attachments: geronimo-web-1.1.xsd XML Schema documentation has been updated in the web but not in the schema in the geronimo distribution.This has the patch which improved the documentation geronimo-web.xsd . -- 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
Issues with Scout in Geronimo
I have been trying to use JAXR for doing registry operations in jUDDI that comes with geronimo. The version of Scout in geronimo 1.1.1 scout-0.5.jar seems to have issues related to ServiceBinding. These are reported as JIRA issues in Scout and are fixed in 0.7-RC1 version of Scout. https://issues.apache.org/jira/browse/SCOUT-22 https://issues.apache.org/jira/browse/SCOUT-10 As some basic operations do not work with Scout need to use UDDI4J for registry operations in Geronimo. Is there some plan to upgrade the version of Scout in Geronimo? Regards Krish
[jira] Resolved: (SM-527) Source restructuration
[ https://issues.apache.org/activemq/browse/SM-527?page=all ] Guillaume Nodet resolved SM-527. Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Fri Nov 3 05:47:25 2006 New Revision: 470813 URL: http://svn.apache.org/viewvc?view=revrev=470813 Log: SM-527: Source restructuration Source restructuration -- Key: SM-527 URL: https://issues.apache.org/activemq/browse/SM-527 Project: ServiceMix Issue Type: Task Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1 See http://goopen.org/confluence/display/SM/Source+Structure -- 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
Improve 'Geronimo' Development
So since I've been working on Geronimo, one of the most annoying things developing Geronimo in an IDE is the overhead involved between modifing code and being able to test the code. For a single line change you have to rebuild and install the module, rebuild the assembly, and re-extract and relaunch the server image. This is needed since Geronimo loads classes from the server repository and currently cannot from the local m2 repo or from the "target/classes" directory itself.Well to ease the developer experience I think we need to change that. As a first step, I'd like to see if we can hook into geronimo a "developers module" that the repository code can delegate over to to load from the m2 repo. That itself would be an improvement and developers could simply rebuild the module without having to regen a new assembly. A step beyond that would be the ability to treat the source tree as a repo, and geronimo load directly from target/classes, this is tricker since the modules in the source tree don't follow a groupId/artifact/version/type convention so some sort of intelligent mapping would have to be done. In theory, this would give us the ability to simply compile a module (with an IDE compiler and not maven) and simply re-start the server.Would this be an effort that would be valuable to the community?If so, if there are suggestions on how to go about implementing either the first or second solution, please give your input.thx -sachin
Re: Improve 'Geronimo' Development
Have you considered using the in-place deployment features to load classes from target/classes or something like that? I know for example IDEA can generate an exploded WAR on each build which you could deploy as an in-place deployment... Thanks, Aaron On 11/3/06, Sachin Patel [EMAIL PROTECTED] wrote: So since I've been working on Geronimo, one of the most annoying things developing Geronimo in an IDE is the overhead involved between modifing code and being able to test the code. For a single line change you have to rebuild and install the module, rebuild the assembly, and re-extract and relaunch the server image. This is needed since Geronimo loads classes from the server repository and currently cannot from the local m2 repo or from the target/classes directory itself. Well to ease the developer experience I think we need to change that. As a first step, I'd like to see if we can hook into geronimo a developers module that the repository code can delegate over to to load from the m2 repo. That itself would be an improvement and developers could simply rebuild the module without having to regen a new assembly. A step beyond that would be the ability to treat the source tree as a repo, and geronimo load directly from target/classes, this is tricker since the modules in the source tree don't follow a groupId/artifact/version/type convention so some sort of intelligent mapping would have to be done. In theory, this would give us the ability to simply compile a module (with an IDE compiler and not maven) and simply re-start the server. Would this be an effort that would be valuable to the community? If so, if there are suggestions on how to go about implementing either the first or second solution, please give your input. thx -sachin
Re: Improve 'Geronimo' Development
Hi Aaron,I think this is different. I'm not talking about developing applications for Geronimo, but developing Geronimo itself. Yes, I'm planning to use the in-place support in conjunction with what I plan for GERONIMO-1526 to improve application development for Geronimo.On Nov 3, 2006, at 10:00 AM, Aaron Mulder wrote:Have you considered using the in-place deployment features to loadclasses from target/classes or something like that? I know forexample IDEA can generate an exploded WAR on each build which youcould deploy as an in-place deployment...Thanks, AaronOn 11/3/06, Sachin Patel [EMAIL PROTECTED] wrote: So since I've been working on Geronimo, one of the most annoying thingsdeveloping Geronimo in an IDE is the overhead involved between modifing codeand being able to test the code. For a single line change you have torebuild and install the module, rebuild the assembly, and re-extract andrelaunch the server image. This is needed since Geronimo loads classes fromthe server repository and currently cannot from the local m2 repo or fromthe "target/classes" directory itself.Well to ease the developer experience I think we need to change that. As afirst step, I'd like to see if we can hook into geronimo a "developersmodule" that the repository code can delegate over to to load from the m2repo. That itself would be an improvement and developers could simplyrebuild the module without having to regen a new assembly. A step beyondthat would be the ability to treat the source tree as a repo, and geronimoload directly from target/classes, this is tricker since the modules in thesource tree don't follow a groupId/artifact/version/type convention so somesort of intelligent mapping would have to be done. In theory, this wouldgive us the ability to simply compile a module (with an IDE compiler and notmaven) and simply re-start the server.Would this be an effort that would be valuable to the community?If so, if there are suggestions on how to go about implementing either thefirst or second solution, please give your input.thx-sachin -sachin
[jira] Commented: (AMQ-999) Message dispatcher issues (use dedicated dispatching thread for each session)
[ https://issues.apache.org/activemq/browse/AMQ-999?page=comments#action_37348 ] Stuart Bain commented on AMQ-999: - DispatcherThread.cs also needs to be added to vs2005-activemq-cf20.csproj Addition of the Close method to the ISession, IConnection, and IMessageConsumer interfaces in this patch breaks the corresponding MSMQ Session, Connection and MessageConsumer implementation classes. Message dispatcher issues (use dedicated dispatching thread for each session) - Key: AMQ-999 URL: https://issues.apache.org/activemq/browse/AMQ-999 Project: ActiveMQ Issue Type: Improvement Components: NMS (C# client) Affects Versions: 4.0.2 Environment: Windows Reporter: Rob Lugt Assigned To: james strachan Fix For: 4.1 Attachments: amq999-patch.txt, AtomicBoolean.cs, DispatchingThread.cs There are a number of issues with the dispatching of inbound messages. - A slow consumer will potentially use and block all ThreadPool threads - Use of a ThreadPool thread to dispatch a single message is inefficient due to context switching - No mechanism to suspend asynchronous delivery to a session (i.e. Connection.Stop() is currently a no-op) - Retroactive consumer is currently broken because retoractive messages are delivered before the listener delegate is assigned. - [minor] Application cannot predict which thread messages will be dispatched on All of these problems can simply be resolved by creating a dedicated dispatcher thread for a session -- 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
Re: Improve 'Geronimo' Development
To add there are two audiences here. (1) Our users, and improving the IDE integration with the runtime, so that they have a better IDE experience when deploying their J2EE applications and or Geronimo services to geronimo.(2) The commmiters and contributes for Geronimo, to improve their experience developing 'Geronimo' within an IDE.This targets #2. On Nov 3, 2006, at 9:29 AM, Sachin Patel wrote:So since I've been working on Geronimo, one of the most annoying things developing Geronimo in an IDE is the overhead involved between modifing code and being able to test the code. For a single line change you have to rebuild and install the module, rebuild the assembly, and re-extract and relaunch the server image. This is needed since Geronimo loads classes from the server repository and currently cannot from the local m2 repo or from the "target/classes" directory itself.Well to ease the developer experience I think we need to change that. As a first step, I'd like to see if we can hook into geronimo a "developers module" that the repository code can delegate over to to load from the m2 repo. That itself would be an improvement and developers could simply rebuild the module without having to regen a new assembly. A step beyond that would be the ability to treat the source tree as a repo, and geronimo load directly from target/classes, this is tricker since the modules in the source tree don't follow a groupId/artifact/version/type convention so some sort of intelligent mapping would have to be done. In theory, this would give us the ability to simply compile a module (with an IDE compiler and not maven) and simply re-start the server.Would this be an effort that would be valuable to the community?If so, if there are suggestions on how to go about implementing either the first or second solution, please give your input.thx -sachin -sachin
Re: geronimo-online-deploy configuration classpath missing server.jar... offline deployer broken
Hmm ok. When I inspected the classloader when loading the class for the attribute type, I remember seeing that the parent classloader contained XMLObject. Do you know why the other gbean's loaded successfully? Would setting the context classloader help the situation?On Nov 3, 2006, at 4:18 AM, David Jencks wrote: I think either removing geronimo-deployment from the manifest cp or adding xmlbeans jar will solve this problem. I don't think the former will work and I really don't like the latter. Maybe we can split up geronimo-deployment jar into a remote piece and a local piece? This may take some more investigation meanwhile temporarily adding xmlbeans to lib and the cp might get this going for now.thanksdavid jencksOn Nov 2, 2006, at 4:58 PM, Sachin Patel wrote:So after being able to bootstrap the j2ee-system configuration, we are running into a NoClassDef exception on XMLObject when attempting to start the gbean-deployer configuration. Comparing the gbean-deployer config to 1.1.1, it looks like a GBeanBuilder bean was introduced in the plan, and this happens to be the gbean that fails to load and causes the exception. The Deployer and ServiceConfigBuilder gbeans prior to it seem to load successfully (which is strange since ServiceConfigBuilder imports XMLObject as well). So on GBeanBuilder when attempting to construct the GBeanInstance and the GBeanAttribute for GBeanInfo for (Iterator iterator = gbeanInfo.getAttributes().iterator(); iterator.hasNext();) { GAttributeInfo attributeInfo = (GAttributeInfo) iterator.next(); attributesMap.put(attributeInfo.getName(), new GBeanAttribute(this, attributeInfo, constructorArgs.contains(attributeInfo.getName(; }The exception is thrown on line 249 in the constructor of GBeanAttribute getInvoker = new FastMethodInvoker(getterMethod);But I seem to be at a dead end here. :( Any ideas why this is failing?On Nov 1, 2006, at 7:04 PM, David Jencks wrote:I came up with a proposed solution and put it in GERONIMO-2539. I think I'm about to need this facility also :-)Take a look, see if it can be improved, see if it works :-)jdillon, does this look OK to you?thanksdavid jencksOn Nov 1, 2006, at 11:15 AM, Sachin Patel wrote:I'm trying to get the offline deployer back working in trunk, the problem is when starting the kernel with the using j2ee-system as the bootstrap configuration, when locating "META-INF"/config.ser" resources only deployer.jar is located having this resource and thus the j2ee-system config cannot be found and the bootstrap fails. When debugging through 1.1.1, both server.jar and deployer.jar were found. So comparing the online-deployer configuration in trunk against 1.1.1, the culprit seems to be that server.jar is missing in the configuration's manifest as a classpath entry. This was specified in the project.properties in 1.1.1. Since it looks as if in trunk we are relying purely on the car-maven-plugin to build the manifest's classpath, since server.jar is not technically an artifact, if failed to add as an entry.Is there a way I don't know about to add this? Or do we need to update the car-maven-plugin to allow it?thx-sachin -sachin -sachin
[jira] Commented: (GERONIMO-2542) Writing XML schema documentation for geronimo-web in distribution
[ http://issues.apache.org/jira/browse/GERONIMO-2542?page=comments#action_12446993 ] Jacek Laskowski commented on GERONIMO-2542: --- May I ask for a patch, please? Give it a name like GERONIMO-2542.patch and attach to the issue. Writing XML schema documentation for geronimo-web in distribution - Key: GERONIMO-2542 URL: http://issues.apache.org/jira/browse/GERONIMO-2542 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: documentation Affects Versions: 1.x Environment: Debian Reporter: Kanchana Welagedara Assigned To: Kanchana Welagedara Fix For: Verification Required Attachments: geronimo-web-1.1.xsd XML Schema documentation has been updated in the web but not in the schema in the geronimo distribution.This has the patch which improved the documentation geronimo-web.xsd . -- 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: Issues with Scout in Geronimo
On 11/3/06, Krishnakumar B [EMAIL PROTECTED] wrote: Is there some plan to upgrade the version of Scout in Geronimo? Not that I've heard about. Anyway, would be able to bump up the version in pom.xml, (re)build Geronimo and give it a try again? I'll rise an jira issue for you if you don't mind? I dont' know whether you've been doing such work before, but if you haven't, it's not that hard as it seems ;-) Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: Improve 'Geronimo' Development
On 11/3/06, Sachin Patel [EMAIL PROTECTED] wrote: So since I've been working on Geronimo, one of the most annoying things developing Geronimo in an IDE is the overhead involved between modifing code and being able to test the code. For a single line change you have to rebuild and install the module, rebuild the assembly, and re-extract and relaunch the server image. This is needed since Geronimo loads classes from the server repository and currently cannot from the local m2 repo or from the target/classes directory itself. Testing changes to some parts of the server like the admin console don't require quite so many steps since a redeploy suffices. But that's still a multistep process and I agree that testing changes to most parts of the server can be tedious. Sometimes I get around this by just rebuilding the affected jar, copying it into repo, and recycling server. Well to ease the developer experience I think we need to change that. As a first step, I'd like to see if we can hook into geronimo a developers module that the repository code can delegate over to to load from the m2 repo. That itself would be an improvement and developers could simply rebuild the module without having to regen a new assembly. A step beyond that would be the ability to treat the source tree as a repo, and geronimo load directly from target/classes, this is tricker since the modules in the source tree don't follow a groupId/artifact/version/type convention so some sort of intelligent mapping would have to be done. In theory, this would give us the ability to simply compile a module (with an IDE compiler and not maven) and simply re-start the server. Both of these ideas sound good and IMO could improve productivity dramatically for geronimo developers. I think I would prefer using the m2 repo instead of the target/classes directory because the location and contents of my m2 repo tend to be more stable than my src tree. Plus there's lots of stuff in my m2 repo that I don't actually have the source/classes for, and I want geronimo to be able to load that stuff too. Like when a pom changes and maven slurps over a new jar. Also, it just seems like a simpler and cleaner design to me. However, I can appreciate the fact that using target/classes would allow the IDE to update the geronimo runtime directly without requiring maven. But maybe maven's eclipse plugin could help with that? In my mind one questionable aspect of either design is how file locking might affect development on windows. Would this be an effort that would be valuable to the community? Yes, I think so! If so, if there are suggestions on how to go about implementing either the first or second solution, please give your input. org.apache.geronimo.management.geronimo.J2EEServer has an API that the console sometimes uses to look for stuff in the repo : /** * Gets the Repositories associated with this J2EEServer. */ public ListableRepository[] getRepositories(); Notice that it returns an *array* of repositories, but AFAIK we usually only ever expect a single element in that array. I didn't look into how one might go about adding to that array, nor how the rest of the server might respond if that happens. Maybe someone watching this thread might know. If I can help by digging into this a little further then just let me know. Best wishes, Paul
[jira] Commented: (DAYTRADER-17) Dojo-based interface for Daytrader
[ http://issues.apache.org/jira/browse/DAYTRADER-17?page=comments#action_12447016 ] Paul McMahan commented on DAYTRADER-17: --- If there's interest in using Geronimo's shared version of Dojo then FYI it was recently upgraded to version 0.4.0 via GERONIMO-2538 so it should now be compatible with your application. I think it would be interesting to see how well the daytrader UI performs using a privately optimized copy of Dojo vs. the unoptimized version resident in the server. Dojo-based interface for Daytrader -- Key: DAYTRADER-17 URL: http://issues.apache.org/jira/browse/DAYTRADER-17 Project: DayTrader Issue Type: New Feature Components: Web Tier Affects Versions: 1.2 Reporter: Christopher James Blythe Attachments: daytrader-17.zip Have opened this to track work on the Dojo-based UI for Daytrader that I have been playing around with. -- 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: 1.2 Fit and Finish
I'm not surprised. Can you merge them? Also, Aaron has many merges left in the dead-1.2 branch that may affect the console. You can see them by running the following command in the server/trunk directory: grep Not Merged all_changes.log -dain On Nov 2, 2006, at 6:20 PM, Paul McMahan wrote: I checked out the weekly build and found some problems that were fixed in the 1.1 branch. One is the tomcat logging that was fixed in rev 415233 and another was the database portlet problem fixed in rev 412804. I'm also suspicious that the problem Jason found in the JMS server portlet could be fixed by a pending merge. Paul On 11/2/06, Dain Sundstrom [EMAIL PROTECTED] wrote: I just uploaded a new weekly release here: http://people.apache.org/dist/geronimo/unstable/1.2-r470164/ Please spend a few minutes trying it out. -dain
Re: Issues with Scout in Geronimo
Does the new version fix their log4j.properties to not enable log4j.debug? --jason On Nov 3, 2006, at 5:25 AM, Krishnakumar B wrote: I have been trying to use JAXR for doing registry operations in jUDDI that comes with geronimo. The version of Scout in geronimo 1.1.1 scout-0.5.jar seems to have issues related to ServiceBinding. These are reported as JIRA issues in Scout and are fixed in 0.7-RC1 version of Scout. https://issues.apache.org/jira/browse/SCOUT-22 https://issues.apache.org/jira/browse/SCOUT-10 As some basic operations do not work with Scout need to use UDDI4J for registry operations in Geronimo. Is there some plan to upgrade the version of Scout in Geronimo? Regards Krish
Re: [discussion] openejb-itests in testsuite
On Nov 2, 2006, at 6:30 PM, Prasad Kashyap wrote:
OK. Sounds good. o.a.openejb it would be.
The reasons I want to leave the tests in one single module are
manifold.
1) That is how they are today.
2) To split them, it would have to be someone from openejb. I have no
idea how they are structured.
3) My top priority now is to get the testsuite framework integrated
with the G build.
That's fine. We can do that part later.
-David
Cheers
Prasad
On 11/1/06, David Blevins [EMAIL PROTECTED] wrote:
On Oct 31, 2006, at 10:07 AM, Prasad Kashyap wrote:
On 10/30/06, David Blevins [EMAIL PROTECTED] wrote:
On Oct 30, 2006, at 7:51 AM, Prasad Kashyap wrote:
Thanx. Please see comments inline -
Couple thoughts on the poms:
- the parent would lineage would be
org.apache.openejb:itests -
org.apache.openejb:openejb
- the groupId would be org.apache.openejb
The groupId and the parent lineage looks good. As stated above,
there
would be many child modules for the beans under the itests
parent
module
groupId: o.a.openejb
openejb - itests - itests-security-xxx
openejb - itests - itests-cmp2-xxx
Exactly.
After having built the itest beans as per our discussion above, the
contents of the openejb directory in m2 local repo are -
${settings.localRepository}/org/apache/openejb/
itests-cmp2-cmrmapping
itests-cmp2-petstore
itests-cmp2-prefetch
itests-cmp2-storage
itests-itests-core
itests-security-001
itests-security-002
itests-security-003
openejb
openejb-builder
openejb-corba
openejb-corba-builder
openejb-core
openejb-itests
openejb-pkgen-builder
openejb-sunorb
openejb-yoko
Does this look good ? Or should we move the itests artifacts one
level down to groupId o.a.openejb.itests ?
Let's keep it in o.a.openejb for now as that's the way it is in 3.x.
For now, I shall put all the tests into 1 artifact module. We
should
look at breaking them and putting them with their respective bean
modules later on.
What's the issue with doing that now?
-David
Re: [VOTE] Release Eclipse Plugin 1.2.0
Kevan brought http://www.apache.org/legal/src-headers.html to our attention the other day in context of geronimo 1.2. Does the eclipse plugin release need to be updated as well? Paul On 10/31/06, Sachin Patel [EMAIL PROTECTED] wrote: The Eclipse Plugin v1.2.0 is ready for release. The plugin has been updated and re-written to move away from the WTP Generic Server Framework, and no longer relies on the Generic Server implementation in WTP. Other bug fixes and feature updates are indicated in the release notes. http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.2.0-v20061037-deployable.zip http://people.apache.org/~sppatel/PLUGIN_RELEASE-NOTES-1.2.0.txt The driver requires the 1.5.1 release of WTP and is available for download here... http://download.eclipse.org/webtools/downloads/drops/R1.5/R-1.5.1-200609230508/ Note: Unfortunately, we will no longer be able to maintain equal versions between the server and the plugin, as the plugins where incremented from either 1.0.0 or 1.0.1 to 1.1.0 due to the fact that the changes where not minor. The feature version was then bumped from 1.1.0 to 1.2.0 to indicate the non-maintenance release and thus no longer matches the server version. [+1] Release [0] No opinion [-1] Do not release I'll plan on concluding the vote on Monday, November 6th at 9 AM EDT -sachin
Re: Issues with Scout in Geronimo
Yes! -- dims On 11/3/06, Jason Dillon [EMAIL PROTECTED] wrote: Does the new version fix their log4j.properties to not enable log4j.debug? --jason On Nov 3, 2006, at 5:25 AM, Krishnakumar B wrote: I have been trying to use JAXR for doing registry operations in jUDDI that comes with geronimo. The version of Scout in geronimo 1.1.1 scout-0.5.jar seems to have issues related to ServiceBinding. These are reported as JIRA issues in Scout and are fixed in 0.7-RC1 version of Scout. https://issues.apache.org/jira/browse/SCOUT-22 https://issues.apache.org/jira/browse/SCOUT-10 As some basic operations do not work with Scout need to use UDDI4J for registry operations in Geronimo. Is there some plan to upgrade the version of Scout in Geronimo? Regards Krish -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
Re: Issues with Scout in Geronimo
Sweet! Is there a release (or snapshot) artifact somewhere? I took a brief look and did not find anything. --jason On Nov 3, 2006, at 10:18 AM, Davanum Srinivas wrote: Yes! -- dims On 11/3/06, Jason Dillon [EMAIL PROTECTED] wrote: Does the new version fix their log4j.properties to not enable log4j.debug? --jason On Nov 3, 2006, at 5:25 AM, Krishnakumar B wrote: I have been trying to use JAXR for doing registry operations in jUDDI that comes with geronimo. The version of Scout in geronimo 1.1.1 scout-0.5.jar seems to have issues related to ServiceBinding. These are reported as JIRA issues in Scout and are fixed in 0.7-RC1 version of Scout. https://issues.apache.org/jira/browse/SCOUT-22 https://issues.apache.org/jira/browse/SCOUT-10 As some basic operations do not work with Scout need to use UDDI4J for registry operations in Geronimo. Is there some plan to upgrade the version of Scout in Geronimo? Regards Krish -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
Re: [VOTE] Release Eclipse Plugin 1.2.0
Yes I assume it needs to change. Jacek can you run your perl script against trunk of devtools as well?On Nov 3, 2006, at 1:12 PM, Paul McMahan wrote:Kevan brought http://www.apache.org/legal/src-headers.html to ourattention the other day in context of geronimo 1.2. Does the eclipseplugin release need to be updated as well?PaulOn 10/31/06, Sachin Patel [EMAIL PROTECTED] wrote: The Eclipse Plugin v1.2.0 is ready for release. The plugin has been updatedand re-written to move away from the WTP Generic Server Framework, and nolonger relies on the Generic Server implementation in WTP. Other bug fixesand feature updates are indicated in the release notes.http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.2.0-v20061037-deployable.ziphttp://people.apache.org/~sppatel/PLUGIN_RELEASE-NOTES-1.2.0.txtThe driver requires the 1.5.1 release of WTP and is available for downloadhere...http://download.eclipse.org/webtools/downloads/drops/R1.5/R-1.5.1-200609230508/Note: Unfortunately, we will no longer be able to maintain equal versionsbetween the server and the plugin, as the plugins where incremented fromeither 1.0.0 or 1.0.1 to 1.1.0 due to the fact that the changes where not"minor". The feature version was then bumped from 1.1.0 to 1.2.0 toindicate the "non-maintenance" release and thus no longer matches the serverversion.[+1] Release[0] No opinion[-1] Do not releaseI'll plan on concluding the vote on Monday, November 6th at 9 AM EDT-sachin -sachin
[jira] Created: (DAYTRADER-19) Fix various HTML syntax issues and remove un-needed import statements
Fix various HTML syntax issues and remove un-needed import statements - Key: DAYTRADER-19 URL: http://issues.apache.org/jira/browse/DAYTRADER-19 Project: DayTrader Issue Type: Bug Components: Web Tier Affects Versions: 1.2 Reporter: Christopher James Blythe Priority: Trivial Just a few minor changes to the html and jsp files to fix any HTML syntax issues that are raised during eclipse validation. I have also removed a few un-needed import statement from some of the jsps. -- 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: (DAYTRADER-19) Fix various HTML syntax issues and remove un-needed import statements
[ http://issues.apache.org/jira/browse/DAYTRADER-19?page=all ] Christopher James Blythe updated DAYTRADER-19: -- Attachment: daytrader-19.patch Here is the associated patch file built off of the 1.2 branch. Fix various HTML syntax issues and remove un-needed import statements - Key: DAYTRADER-19 URL: http://issues.apache.org/jira/browse/DAYTRADER-19 Project: DayTrader Issue Type: Bug Components: Web Tier Affects Versions: 1.2 Reporter: Christopher James Blythe Priority: Trivial Attachments: daytrader-19.patch Just a few minor changes to the html and jsp files to fix any HTML syntax issues that are raised during eclipse validation. I have also removed a few un-needed import statement from some of the jsps. -- 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: (DAYTRADER-20) Daytrader ear includes lots of kitchen sinks
Daytrader ear includes lots of kitchen sinks Key: DAYTRADER-20 URL: http://issues.apache.org/jira/browse/DAYTRADER-20 Project: DayTrader Issue Type: Bug Components: buildsystem Affects Versions: 1.2 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2 Currently the ear includes about 10-15 dependent jars it shouldn't. The m2 dependency scopes need to be adjusted to fix this. I'll fix this in trunk (2.0), also an issue in 1.2 branch -- 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: (DAYTRADER-21) Indicate that MDB primitives are not intended for performance testing
Indicate that MDB primitives are not intended for performance testing - Key: DAYTRADER-21 URL: http://issues.apache.org/jira/browse/DAYTRADER-21 Project: DayTrader Issue Type: Improvement Components: Web Tier Affects Versions: 1.2 Reporter: Christopher James Blythe The MDB primitives, PingServlet2MDBQueue and PingServlet2MDBTopic, are not suited for testing MDB performance. The problem stems from a difference in how fast messages can be placed on the queue/topic by the JMS client versus how fast the MDBs can process them. Generally, the messages can be created much faster than they can be consumed. This in turn leads to problems when the maximum queue/topic sizes are reached. -- 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: (DAYTRADER-21) Indicate that MDB primitives are not intended for performance testing
[ http://issues.apache.org/jira/browse/DAYTRADER-21?page=all ] Christopher James Blythe updated DAYTRADER-21: -- Attachment: daytrader-21.patch This patch adds statements to the primitive list and individual primitives to indicate that they are not intended for performance testing Indicate that MDB primitives are not intended for performance testing - Key: DAYTRADER-21 URL: http://issues.apache.org/jira/browse/DAYTRADER-21 Project: DayTrader Issue Type: Improvement Components: Web Tier Affects Versions: 1.2 Reporter: Christopher James Blythe Attachments: daytrader-21.patch The MDB primitives, PingServlet2MDBQueue and PingServlet2MDBTopic, are not suited for testing MDB performance. The problem stems from a difference in how fast messages can be placed on the queue/topic by the JMS client versus how fast the MDBs can process them. Generally, the messages can be created much faster than they can be consumed. This in turn leads to problems when the maximum queue/topic sizes are reached. -- 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: (DAYTRADER-21) Indicate that MDB primitives are not intended for performance testing
[ http://issues.apache.org/jira/browse/DAYTRADER-21?page=all ] Christopher James Blythe updated DAYTRADER-21: -- Priority: Minor (was: Major) Indicate that MDB primitives are not intended for performance testing - Key: DAYTRADER-21 URL: http://issues.apache.org/jira/browse/DAYTRADER-21 Project: DayTrader Issue Type: Improvement Components: Web Tier Affects Versions: 1.2 Reporter: Christopher James Blythe Priority: Minor Attachments: daytrader-21.patch The MDB primitives, PingServlet2MDBQueue and PingServlet2MDBTopic, are not suited for testing MDB performance. The problem stems from a difference in how fast messages can be placed on the queue/topic by the JMS client versus how fast the MDBs can process them. Generally, the messages can be created much faster than they can be consumed. This in turn leads to problems when the maximum queue/topic sizes are reached. -- 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: [VOTE] Release Eclipse Plugin 1.2.0
On 11/3/06, Sachin Patel [EMAIL PROTECTED] wrote: Yes I assume it needs to change. Jacek can you run your perl script against trunk of devtools as well? Sure. Doing now... Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: [VOTE] Release Eclipse Plugin 1.2.0
On 11/3/06, Jacek Laskowski [EMAIL PROTECTED] wrote: On 11/3/06, Sachin Patel [EMAIL PROTECTED] wrote: Yes I assume it needs to change. Jacek can you run your perl script against trunk of devtools as well? Sure. Doing now... Whoops - 350 files to process and only 30 met the script's criteria. The rest don't have license at all (!) It seems I need another script. Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: [VOTE] Release Eclipse Plugin 1.2.0
IDEA's Copyright plugin is handy to process files with or with out a copyright notice. There also used to be some other more general tool to manage headers... but I forget what it was called. --jason On Nov 3, 2006, at 1:01 PM, Jacek Laskowski wrote: On 11/3/06, Jacek Laskowski [EMAIL PROTECTED] wrote: On 11/3/06, Sachin Patel [EMAIL PROTECTED] wrote: Yes I assume it needs to change. Jacek can you run your perl script against trunk of devtools as well? Sure. Doing now... Whoops - 350 files to process and only 30 met the script's criteria. The rest don't have license at all (!) It seems I need another script. Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: [jira] Commented: (GERONIMO-2537) All Geronimo source files must be brought in line with the new ASF source header and copyright notice policy
On Nov 3, 2006, at 5:22 AM, Jacek Laskowski (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-2537? page=comments#action_12446897 ] Jacek Laskowski commented on GERONIMO-2537: --- Al sources migrated. Needs verifying. Jacek, That's fantastic! Thanks a bunch! I'm holding off on my svn up, but will have a look over the weekend... --kevan
Re: [VOTE] Release Eclipse Plugin 1.2.0
On 11/3/06, Jason Dillon [EMAIL PROTECTED] wrote: IDEA's Copyright plugin is handy to process files with or with out a copyright notice. Ah I see - http://www.intellij.org/twiki/bin/view/Main/CopyrightPlugin. I've got the open source license of IDEA recently so it's time to give it a shot. Thanks! I hope I won't get burned out very quickly trying all these tools and end up with nothing ;-) Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: [VOTE] Release Eclipse Plugin 1.2.0
Hi Sachin, I'm stuck with a deployment descriptor editor issue. I think you mentioned it's been reported already. Once I got it failing I am no longer able to edit geronimo-web.xml for instance. I deleted the file, recreated it, did some other stuffs but still I can not get that file opened again with the editor. Text based editors work fine. Any pointers? Cheers! Hernan Sachin Patel wrote: The Eclipse Plugin v1.2.0 is ready for release. The plugin has been updated and re-written to move away from the WTP Generic Server Framework, and no longer relies on the Generic Server implementation in WTP. Other bug fixes and feature updates are indicated in the release notes. http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.2.0-v20061037-deployable.zip http://people.apache.org/~sppatel/PLUGIN_RELEASE-NOTES-1.2.0.txt The driver requires the 1.5.1 release of WTP and is available for download here... http://download.eclipse.org/webtools/downloads/drops/R1.5/R-1.5.1-200609230508/ Note: Unfortunately, we will no longer be able to maintain equal versions between the server and the plugin, as the plugins where incremented from either 1.0.0 or 1.0.1 to 1.1.0 due to the fact that the changes where not minor. The feature version was then bumped from 1.1.0 to 1.2.0 to indicate the non-maintenance release and thus no longer matches the server version. [+1] Release [0] No opinion [-1] Do not release I'll plan on concluding the vote on Monday, November 6th at 9 AM EDT -sachin
Re: [jira] Commented: (GERONIMO-2537) All Geronimo source files must be brought in line with the new ASF source header and copyright notice policy
On 11/3/06, Kevan Miller [EMAIL PROTECTED] wrote: Jacek, That's fantastic! Thanks a bunch! I'm holding off on my svn up, but will have a look over the weekend... Not that much, but I'm glad you've found it useful ;-) I'm using IDEA to verify how well the migration's done. Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: [VOTE] Release Eclipse Plugin 1.2.0
I have used the Copyright plugin before... its mostly usable... best results if you override the defaults for each type with the exact text you want. Wish it was easier to enable the profile for each module, but you gotta do that by hand. --jason On Nov 3, 2006, at 1:31 PM, Jacek Laskowski wrote: On 11/3/06, Jason Dillon [EMAIL PROTECTED] wrote: IDEA's Copyright plugin is handy to process files with or with out a copyright notice. Ah I see - http://www.intellij.org/twiki/bin/view/Main/ CopyrightPlugin. I've got the open source license of IDEA recently so it's time to give it a shot. Thanks! I hope I won't get burned out very quickly trying all these tools and end up with nothing ;-) Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
[jira] Updated: (GERONIMO-2543) Upgrade Scout from version 0.5 to 0.7rc1
[ http://issues.apache.org/jira/browse/GERONIMO-2543?page=all ]
Jay D. McHugh updated GERONIMO-2543:
Attachment: geronimo-specs-2543.patch
Upgrade Scout from version 0.5 to 0.7rc1
Key: GERONIMO-2543
URL: http://issues.apache.org/jira/browse/GERONIMO-2543
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: webservices
Affects Versions: 1.2
Reporter: Jay D. McHugh
Priority: Minor
Attachments: geronimo-2543.patch, geronimo-specs-2543.patch
It looks like scout has been moved to ws-scout. But there apears to be only
the jar files published.
I have patches for both the geronimo-specs and geronimo trunk.
The patch changes the following:
- the dependency on scout/scout/0.5 to ws-scout/scout/0.7rc1
- the dependency on the geronimo-jaxr_spec up to the 1.1-SNAPSHOT version
(built locally)
I started with a clean repo and built specs first (disabling tests).
After the specs were build, I went back to do the tests. They failed here:
[INFO]
[INFO] Building JAXR 1.0
[INFO]task-segment: [install]
[INFO]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
Downloading:
http://repository.codehaus.org/ws-scout/scout/0.7rc1/scout-0.7rc1.pom
[WARNING] Unable to get resource from repository codehaus
(http://repository.codehaus.org)
Downloading:
http://repo1.maven.org/maven2/ws-scout/scout/0.7rc1/scout-0.7rc1.pom
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
Compiling 1 source file to
/usr/src/geronimo-specs/geronimo-jaxr_1.0_spec/target/test-classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/usr/src/geronimo-specs/geronimo-jaxr_1.0_spec/src/test/java/javax/xml/registry/ConnectionFactoryTest.java:[26,36]
package org.apache.ws.scout.registry does not exist
/usr/src/geronimo-specs/geronimo-jaxr_1.0_spec/src/test/java/javax/xml/registry/ConnectionFactoryTest.java:[39,21]
cannot resolve symbol
symbol : class ConnectionFactoryImpl
location: class javax.xml.registry.ConnectionFactoryTest
After building specs, I built trunk (again disabling tests).
The build finished fine. Once it was complete, I went back to run the tests.
They also finished fine.
--
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-2543) Upgrade Scout from version 0.5 to 0.7rc1
Upgrade Scout from version 0.5 to 0.7rc1
Key: GERONIMO-2543
URL: http://issues.apache.org/jira/browse/GERONIMO-2543
Project: Geronimo
Issue Type: Improvement
Security Level: public (Regular issues)
Components: webservices
Affects Versions: 1.2
Reporter: Jay D. McHugh
Priority: Minor
Attachments: geronimo-2543.patch, geronimo-specs-2543.patch
It looks like scout has been moved to ws-scout. But there apears to be only
the jar files published.
I have patches for both the geronimo-specs and geronimo trunk.
The patch changes the following:
- the dependency on scout/scout/0.5 to ws-scout/scout/0.7rc1
- the dependency on the geronimo-jaxr_spec up to the 1.1-SNAPSHOT version
(built locally)
I started with a clean repo and built specs first (disabling tests).
After the specs were build, I went back to do the tests. They failed here:
[INFO]
[INFO] Building JAXR 1.0
[INFO]task-segment: [install]
[INFO]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
Downloading:
http://repository.codehaus.org/ws-scout/scout/0.7rc1/scout-0.7rc1.pom
[WARNING] Unable to get resource from repository codehaus
(http://repository.codehaus.org)
Downloading:
http://repo1.maven.org/maven2/ws-scout/scout/0.7rc1/scout-0.7rc1.pom
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
Compiling 1 source file to
/usr/src/geronimo-specs/geronimo-jaxr_1.0_spec/target/test-classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/usr/src/geronimo-specs/geronimo-jaxr_1.0_spec/src/test/java/javax/xml/registry/ConnectionFactoryTest.java:[26,36]
package org.apache.ws.scout.registry does not exist
/usr/src/geronimo-specs/geronimo-jaxr_1.0_spec/src/test/java/javax/xml/registry/ConnectionFactoryTest.java:[39,21]
cannot resolve symbol
symbol : class ConnectionFactoryImpl
location: class javax.xml.registry.ConnectionFactoryTest
After building specs, I built trunk (again disabling tests).
The build finished fine. Once it was complete, I went back to run the tests.
They also finished fine.
--
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-2543) Upgrade Scout from version 0.5 to 0.7rc1
[ http://issues.apache.org/jira/browse/GERONIMO-2543?page=all ]
Jay D. McHugh updated GERONIMO-2543:
Attachment: geronimo-2543.patch
Upgrade Scout from version 0.5 to 0.7rc1
Key: GERONIMO-2543
URL: http://issues.apache.org/jira/browse/GERONIMO-2543
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: webservices
Affects Versions: 1.2
Reporter: Jay D. McHugh
Priority: Minor
Attachments: geronimo-2543.patch, geronimo-specs-2543.patch
It looks like scout has been moved to ws-scout. But there apears to be only
the jar files published.
I have patches for both the geronimo-specs and geronimo trunk.
The patch changes the following:
- the dependency on scout/scout/0.5 to ws-scout/scout/0.7rc1
- the dependency on the geronimo-jaxr_spec up to the 1.1-SNAPSHOT version
(built locally)
I started with a clean repo and built specs first (disabling tests).
After the specs were build, I went back to do the tests. They failed here:
[INFO]
[INFO] Building JAXR 1.0
[INFO]task-segment: [install]
[INFO]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
Downloading:
http://repository.codehaus.org/ws-scout/scout/0.7rc1/scout-0.7rc1.pom
[WARNING] Unable to get resource from repository codehaus
(http://repository.codehaus.org)
Downloading:
http://repo1.maven.org/maven2/ws-scout/scout/0.7rc1/scout-0.7rc1.pom
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
Compiling 1 source file to
/usr/src/geronimo-specs/geronimo-jaxr_1.0_spec/target/test-classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/usr/src/geronimo-specs/geronimo-jaxr_1.0_spec/src/test/java/javax/xml/registry/ConnectionFactoryTest.java:[26,36]
package org.apache.ws.scout.registry does not exist
/usr/src/geronimo-specs/geronimo-jaxr_1.0_spec/src/test/java/javax/xml/registry/ConnectionFactoryTest.java:[39,21]
cannot resolve symbol
symbol : class ConnectionFactoryImpl
location: class javax.xml.registry.ConnectionFactoryTest
After building specs, I built trunk (again disabling tests).
The build finished fine. Once it was complete, I went back to run the tests.
They also finished fine.
--
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-2543) Upgrade Scout from version 0.5 to 0.7rc1
[
http://issues.apache.org/jira/browse/GERONIMO-2543?page=comments#action_12447106
]
Jay D. McHugh commented on GERONIMO-2543:
-
Someone else should test that the functionality is still the same.
I do not know enough about jaxr to be able to test beyond the tests that maven
runs.
Upgrade Scout from version 0.5 to 0.7rc1
Key: GERONIMO-2543
URL: http://issues.apache.org/jira/browse/GERONIMO-2543
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: webservices
Affects Versions: 1.2
Reporter: Jay D. McHugh
Priority: Minor
Attachments: geronimo-2543.patch, geronimo-specs-2543.patch
It looks like scout has been moved to ws-scout. But there apears to be only
the jar files published.
I have patches for both the geronimo-specs and geronimo trunk.
The patch changes the following:
- the dependency on scout/scout/0.5 to ws-scout/scout/0.7rc1
- the dependency on the geronimo-jaxr_spec up to the 1.1-SNAPSHOT version
(built locally)
I started with a clean repo and built specs first (disabling tests).
After the specs were build, I went back to do the tests. They failed here:
[INFO]
[INFO] Building JAXR 1.0
[INFO]task-segment: [install]
[INFO]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
Downloading:
http://repository.codehaus.org/ws-scout/scout/0.7rc1/scout-0.7rc1.pom
[WARNING] Unable to get resource from repository codehaus
(http://repository.codehaus.org)
Downloading:
http://repo1.maven.org/maven2/ws-scout/scout/0.7rc1/scout-0.7rc1.pom
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
Compiling 1 source file to
/usr/src/geronimo-specs/geronimo-jaxr_1.0_spec/target/test-classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/usr/src/geronimo-specs/geronimo-jaxr_1.0_spec/src/test/java/javax/xml/registry/ConnectionFactoryTest.java:[26,36]
package org.apache.ws.scout.registry does not exist
/usr/src/geronimo-specs/geronimo-jaxr_1.0_spec/src/test/java/javax/xml/registry/ConnectionFactoryTest.java:[39,21]
cannot resolve symbol
symbol : class ConnectionFactoryImpl
location: class javax.xml.registry.ConnectionFactoryTest
After building specs, I built trunk (again disabling tests).
The build finished fine. Once it was complete, I went back to run the tests.
They also finished fine.
--
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-2543) Upgrade Scout from version 0.5 to 0.7rc1
[
http://issues.apache.org/jira/browse/GERONIMO-2543?page=comments#action_12447109
]
Jay D. McHugh commented on GERONIMO-2543:
-
I did some more checking and even though the server build completed and the
server started - I don't think that this is enough to switch to the new version
of scout.
I downloaded the source for scout and built it and the jar file that it created
is much bigger that the one that was downloaded from the maven repository.
So, the patches may be enough once there is a copy of scout uploaded to a
repository - But I don't think this is worth looking at (unless you want to
download and build scout yourself) until there is a release that is published.
Sorry for the noise.
Upgrade Scout from version 0.5 to 0.7rc1
Key: GERONIMO-2543
URL: http://issues.apache.org/jira/browse/GERONIMO-2543
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: webservices
Affects Versions: 1.2
Reporter: Jay D. McHugh
Priority: Minor
Attachments: geronimo-2543.patch, geronimo-specs-2543.patch
It looks like scout has been moved to ws-scout. But there apears to be only
the jar files published.
I have patches for both the geronimo-specs and geronimo trunk.
The patch changes the following:
- the dependency on scout/scout/0.5 to ws-scout/scout/0.7rc1
- the dependency on the geronimo-jaxr_spec up to the 1.1-SNAPSHOT version
(built locally)
I started with a clean repo and built specs first (disabling tests).
After the specs were build, I went back to do the tests. They failed here:
[INFO]
[INFO] Building JAXR 1.0
[INFO]task-segment: [install]
[INFO]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
Downloading:
http://repository.codehaus.org/ws-scout/scout/0.7rc1/scout-0.7rc1.pom
[WARNING] Unable to get resource from repository codehaus
(http://repository.codehaus.org)
Downloading:
http://repo1.maven.org/maven2/ws-scout/scout/0.7rc1/scout-0.7rc1.pom
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
Compiling 1 source file to
/usr/src/geronimo-specs/geronimo-jaxr_1.0_spec/target/test-classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/usr/src/geronimo-specs/geronimo-jaxr_1.0_spec/src/test/java/javax/xml/registry/ConnectionFactoryTest.java:[26,36]
package org.apache.ws.scout.registry does not exist
/usr/src/geronimo-specs/geronimo-jaxr_1.0_spec/src/test/java/javax/xml/registry/ConnectionFactoryTest.java:[39,21]
cannot resolve symbol
symbol : class ConnectionFactoryImpl
location: class javax.xml.registry.ConnectionFactoryTest
After building specs, I built trunk (again disabling tests).
The build finished fine. Once it was complete, I went back to run the tests.
They also finished fine.
--
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
Geronimo Performance Report - Input Requested
All, I've been spending some quality time with Geronimo over the past couple of weeks gathering some performance data for 1.1.1. I've posted a PDF that I'd like your input on in terms of content, questions, etc. I'd like to wrap this up quickly as I'd like to help with 1.2 so your prompt reply is appreciated. This is a rough draft so there are spelling errors and such so your keen eye is welcome. I have some additional work to do this weekend to validate my comparison metric. Also, I need a better name than HPG (Hogstrom Performance Goal). Thanks in advance for your help. http://people.apache.org/~hogstrom/Geronimo-1.1.1-Performance-Report.pdf Matt Hogstrom [EMAIL PROTECTED]
[jira] Closed: (DAYTRADER-21) Indicate that MDB primitives are not intended for performance testing
[ http://issues.apache.org/jira/browse/DAYTRADER-21?page=all ] Matt Hogstrom closed DAYTRADER-21. -- Fix Version/s: 1.1.1 1.2 Resolution: Fixed Assignee: Matt Hogstrom Applied...thanks Chris...this makes it clearer for those that are testing. Indicate that MDB primitives are not intended for performance testing - Key: DAYTRADER-21 URL: http://issues.apache.org/jira/browse/DAYTRADER-21 Project: DayTrader Issue Type: Improvement Components: Web Tier Affects Versions: 1.2 Reporter: Christopher James Blythe Assigned To: Matt Hogstrom Priority: Minor Fix For: 1.1.1, 1.2 Attachments: daytrader-21.patch The MDB primitives, PingServlet2MDBQueue and PingServlet2MDBTopic, are not suited for testing MDB performance. The problem stems from a difference in how fast messages can be placed on the queue/topic by the JMS client versus how fast the MDBs can process them. Generally, the messages can be created much faster than they can be consumed. This in turn leads to problems when the maximum queue/topic sizes are reached. -- 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
