[jira] Commented: (GERONIMO-4518) Can't shutdown the server when host was set to 127.0.0.1 in config-substitutions.properties
[ https://issues.apache.org/jira/browse/GERONIMO-4518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12665757#action_12665757 ] Shawn Jiang commented on GERONIMO-4518: --- I've verified that this defect was fixed in latest 2.1.4 snapshot build. Thanks. Can't shutdown the server when host was set to 127.0.0.1 in config-substitutions.properties --- Key: GERONIMO-4518 URL: https://issues.apache.org/jira/browse/GERONIMO-4518 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1.4, 2.2 Environment: Windows XP + Sun JDK 1.5 Reporter: Shawn Jiang Assignee: Donald Woods Priority: Blocker Fix For: 2.1.4, 2.2 Attachments: G4518_Shawn.patch 1, change the host in config-substitutions.properties to 127.0.0.1 2, start the server. 3, shutdown the server. *expected result*: the server could be shutdown. *actual result*: the sever can't be shutdown with exception: java.net.ConnectException: Connection refused: connect -- C:\geronimo-tomcat6-javaee5-2.2-SNAPSHOT\binshutdown --host 127.0.0.1 Using GERONIMO_HOME: C:\geronimo-tomcat6-javaee5-2.2-SNAPSHOT Using GERONIMO_TMPDIR: var\temp Using JRE_HOME:D:\dev\JDKs\sun_jdk1.5.0_15\jre log4j:WARN No appenders could be found for logger (org.apache.geronimo.kernel.basic.BasicKernel). log4j:WARN Please initialize the log4j system properly. Username: system Password: *** Locating server on 127.0.0.1:1099... Could not communicate with the server. The server may not be running or the port number may be inco rrect (Connection refused to host: 6.153.277.58; nested exception is: java.net.ConnectException: Connection refused: connect) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4475) Improve JMS portlet for Borker configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan updated GERONIMO-4475: --- Attachment: (was: G4475-activemq-broker.patch) Improve JMS portlet for Borker configuration Key: GERONIMO-4475 URL: https://issues.apache.org/jira/browse/GERONIMO-4475 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Reporter: Ivan Assignee: Donald Woods Fix For: 2.2 Attachments: G4475-activemq-broker.patch, G4475-activemq-portlet-update-02.patch, G4475-geronimo-management.patch Currently in the administrator console, the users could not add another embed broker. Also, they could not edit the broker through administrator console. I list the features that I could see : 1. While creating the broker, let the use upload a configuration file. 2. While editing the broker, show a text area, so that the user could edit the spring XML file in it. Shall we give the user a more friendly interface, so that they do not need the edit the XML file directly. I am not sure how it should look like. 3. Update the connector port let, so that while creating a new connector, the user could specify the broker that it belongs to. Please help to give some comments ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4475) Improve JMS portlet for Borker configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan updated GERONIMO-4475: --- Attachment: G4475-activemq-broker.patch Improve JMS portlet for Borker configuration Key: GERONIMO-4475 URL: https://issues.apache.org/jira/browse/GERONIMO-4475 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Reporter: Ivan Assignee: Donald Woods Fix For: 2.2 Attachments: G4475-activemq-broker.patch, G4475-activemq-portlet-update-02.patch, G4475-geronimo-management.patch Currently in the administrator console, the users could not add another embed broker. Also, they could not edit the broker through administrator console. I list the features that I could see : 1. While creating the broker, let the use upload a configuration file. 2. While editing the broker, show a text area, so that the user could edit the spring XML file in it. Shall we give the user a more friendly interface, so that they do not need the edit the XML file directly. I am not sure how it should look like. 3. Update the connector port let, so that while creating a new connector, the user could specify the broker that it belongs to. Please help to give some comments ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4475) Improve JMS portlet for Borker configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan updated GERONIMO-4475: --- Attachment: G4475-geronimo-activemq.patch Improve JMS portlet for Borker configuration Key: GERONIMO-4475 URL: https://issues.apache.org/jira/browse/GERONIMO-4475 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Reporter: Ivan Assignee: Donald Woods Fix For: 2.2 Attachments: G4475-activemq-broker.patch, G4475-activemq-portlet-update-02.patch, G4475-geronimo-activemq.patch, G4475-geronimo-management.patch Currently in the administrator console, the users could not add another embed broker. Also, they could not edit the broker through administrator console. I list the features that I could see : 1. While creating the broker, let the use upload a configuration file. 2. While editing the broker, show a text area, so that the user could edit the spring XML file in it. Shall we give the user a more friendly interface, so that they do not need the edit the XML file directly. I am not sure how it should look like. 3. Update the connector port let, so that while creating a new connector, the user could specify the broker that it belongs to. Please help to give some comments ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4475) Improve JMS portlet for Borker configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12665760#action_12665760 ] Ivan commented on GERONIMO-4475: Update patch to support PortOffset in the activemq configuration xml file, a customized spring placeholder is added. For discussion, please refer to http://www.nabble.com/Dual-ActiveMQ-configuration-style--WAS:-Add-tomcat-specific-configuration--tt21453929.html Thanks ! Improve JMS portlet for Borker configuration Key: GERONIMO-4475 URL: https://issues.apache.org/jira/browse/GERONIMO-4475 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Reporter: Ivan Assignee: Donald Woods Fix For: 2.2 Attachments: G4475-activemq-broker.patch, G4475-activemq-portlet-update-02.patch, G4475-geronimo-activemq.patch, G4475-geronimo-management.patch Currently in the administrator console, the users could not add another embed broker. Also, they could not edit the broker through administrator console. I list the features that I could see : 1. While creating the broker, let the use upload a configuration file. 2. While editing the broker, show a text area, so that the user could edit the spring XML file in it. Shall we give the user a more friendly interface, so that they do not need the edit the XML file directly. I am not sure how it should look like. 3. Update the connector port let, so that while creating a new connector, the user could specify the broker that it belongs to. Please help to give some comments ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4517: --- Attachment: (was: js-localization-sysdb.patch) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages. --- Key: GERONIMO-4517 URL: https://issues.apache.org/jira/browse/GERONIMO-4517 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Reporter: Gang Yin Assignee: Gang Yin Priority: Minor Fix For: 2.2 Attachments: js-localization-core.patch, js-localization-core_v2.patch, js-localization-openejb.patch, screenshot-1.jpg, screenshot-2.jpg Currently all the messages generated from backend is displayed in a unified manner(G-4484), but frontend javascript use alert boxes to display all kinds of messages without distinguishing their types(e.g. error, warn, info), and the UX of alert boxes is not so good, so I'm going to extend the unified message display style of backend messages to frontend messages. Also, the localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4517: --- Attachment: js-localization-sysdb.patch Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages. --- Key: GERONIMO-4517 URL: https://issues.apache.org/jira/browse/GERONIMO-4517 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Reporter: Gang Yin Assignee: Gang Yin Priority: Minor Fix For: 2.2 Attachments: js-localization-core.patch, js-localization-core_v2.patch, js-localization-openejb.patch, js-localization-sysdb.patch, screenshot-1.jpg, screenshot-2.jpg Currently all the messages generated from backend is displayed in a unified manner(G-4484), but frontend javascript use alert boxes to display all kinds of messages without distinguishing their types(e.g. error, warn, info), and the UX of alert boxes is not so good, so I'm going to extend the unified message display style of backend messages to frontend messages. Also, the localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4251) Class-Path entry in WAR manifest didn't work if entry is a directory
[ https://issues.apache.org/jira/browse/GERONIMO-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12665764#action_12665764 ] Ivan commented on GERONIMO-4251: I would like work on it, for some reason, I have no access right to the JEE 1.5 specification. So the right behavior is to add all the files ended with jar in the directory to the classpath, right ? Thanks ! Class-Path entry in WAR manifest didn't work if entry is a directory Key: GERONIMO-4251 URL: https://issues.apache.org/jira/browse/GERONIMO-4251 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2 Environment: Geronimo 2.1.2 on Windows XP Reporter: Frank Meilinger Fix For: 2.1.4, 2.2 Hi, it's not possible to define an Class-Path element in the WARs manifest, if it's a directory. I try to access jar files packed in the EARs lib/ directory from within a WAR module. e.g. this will work: Class-Path: a.jar b.jar but this doesn't work: Class-Path: lib/ If a directory is specifyed, I receive the following error: 15:20:13,170 ERROR [DirectoryHotDeployer] Unable to deploy: Manifest class path entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../ org.apache.geronimo.common.DeploymentException: Manifest class path entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../ at org.apache.geronimo.deployment.DeploymentContext.addManifestClassPath (DeploymentContext.java:419) ... I think this is definitely an error because the JEE5 specification section 8.2.1 explicitely allows directories in manifest Class-Path entries. See discussion: http://www.nabble.com/EAR-bundle-dir-classpath-issue-tt18982334s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4517: --- Attachment: js-localization-logmanager.patch adaption of logmanager portlet Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages. --- Key: GERONIMO-4517 URL: https://issues.apache.org/jira/browse/GERONIMO-4517 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Reporter: Gang Yin Assignee: Gang Yin Priority: Minor Fix For: 2.2 Attachments: js-localization-core.patch, js-localization-core_v2.patch, js-localization-logmanager.patch, js-localization-openejb.patch, js-localization-sysdb.patch, screenshot-1.jpg, screenshot-2.jpg Currently all the messages generated from backend is displayed in a unified manner(G-4484), but frontend javascript use alert boxes to display all kinds of messages without distinguishing their types(e.g. error, warn, info), and the UX of alert boxes is not so good, so I'm going to extend the unified message display style of backend messages to frontend messages. Also, the localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12665766#action_12665766 ] Gang Yin commented on GERONIMO-4517: Hi Donald, please help to review and commit these patches, thanks. Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages. --- Key: GERONIMO-4517 URL: https://issues.apache.org/jira/browse/GERONIMO-4517 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Reporter: Gang Yin Assignee: Gang Yin Priority: Minor Fix For: 2.2 Attachments: js-localization-core.patch, js-localization-core_v2.patch, js-localization-logmanager.patch, js-localization-openejb.patch, js-localization-sysdb.patch, screenshot-1.jpg, screenshot-2.jpg Currently all the messages generated from backend is displayed in a unified manner(G-4484), but frontend javascript use alert boxes to display all kinds of messages without distinguishing their types(e.g. error, warn, info), and the UX of alert boxes is not so good, so I'm going to extend the unified message display style of backend messages to frontend messages. Also, the localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4251) Class-Path entry in WAR manifest didn't work if entry is a directory
[ https://issues.apache.org/jira/browse/GERONIMO-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12665779#action_12665779 ] Ivan commented on GERONIMO-4251: Thanks, actually I know the link to the JEE5 specification, but due to the special reason, I can not read that doc ;-( So I have to confirm with you what the correct behavior is. Class-Path entry in WAR manifest didn't work if entry is a directory Key: GERONIMO-4251 URL: https://issues.apache.org/jira/browse/GERONIMO-4251 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2 Environment: Geronimo 2.1.2 on Windows XP Reporter: Frank Meilinger Fix For: 2.1.4, 2.2 Hi, it's not possible to define an Class-Path element in the WARs manifest, if it's a directory. I try to access jar files packed in the EARs lib/ directory from within a WAR module. e.g. this will work: Class-Path: a.jar b.jar but this doesn't work: Class-Path: lib/ If a directory is specifyed, I receive the following error: 15:20:13,170 ERROR [DirectoryHotDeployer] Unable to deploy: Manifest class path entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../ org.apache.geronimo.common.DeploymentException: Manifest class path entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../ at org.apache.geronimo.deployment.DeploymentContext.addManifestClassPath (DeploymentContext.java:419) ... I think this is definitely an error because the JEE5 specification section 8.2.1 explicitely allows directories in manifest Class-Path entries. See discussion: http://www.nabble.com/EAR-bundle-dir-classpath-issue-tt18982334s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4251) Class-Path entry in WAR manifest didn't work if entry is a directory
[ https://issues.apache.org/jira/browse/GERONIMO-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12665775#action_12665775 ] Frank Meilinger commented on GERONIMO-4251: --- Hi Ivan, right! This should be the right beavior. You may download the JEE 5 specification at http://jcp.org/aboutJava/communityprocess/final/jsr244/index.html The name of the document is: javaee-5_0-fr-spec.pdf But here is a copy of the relevant section (of special interest here is point 2.): EE.8.2.1Bundled Libraries Libraries bundled with an application may be referenced in the following ways: 1. A JAR format file (such as a .jar file, .war file, or .rar file) may reference a .jar file or directory by naming the referenced .jar file or directory in a Class-Path header in the referencing JAR file's Manifest file. The referenced .jar file or directory is named using a URL relative to the URL of the refer- encing JAR file. The Manifest file is named META-INF/MANIFEST.MF in the JAR file. The Class-Path entry in the Manifest file is of the form Class-Path: list-of-jar-files-or-directories-separated-by-spaces The Java EE deployment tools must process all such referenced files and directories when processing a Java EE module. Any deployment descriptors in referenced .jar files must be ignored when processing the referencing .jar file. The deployment tool must install the .jar files and directories in a way that preserves the relative references between the files. Typically this is done by installing the .jar files into a directory hierarchy that matches the original application directory hierarchy. All referenced .jar files or directories must appear in the logical class path of the referencing JAR files at runtime. Only JAR format files or directories containing class files or resources to be loaded directly by a standard class loader should be the target of a Class-Path reference; such files are always named with a .jar extension. Top level JAR files that are processed by a deployment tool should not contain Class-Path entries; such entries would, by definition, reference other files external to the deployment unit. A deployment tool is not required to process such external references. 2. A .ear file may contain a directory that contains libraries packaged in JAR files. The library-directory element of the .ear file's deployment descriptor contains the name of this directory. If a library-directory element isn't spec- ified, or if the .ear file does not contain a deployment descriptor, the directory named lib is used. An empty library-directory element may be used to spec- ify that there is no library directory. All files in this directory (but not subdirectories) with a .jar extension must be made available to all components packaged in the EAR file, including application clients. These libraries may reference other libraries, either bun- dled with the application or installed separately, using any of the techniques described herein. 3. A web application may include libraries in the WEB-INF/lib directory. See the Servlet specification for details. These libraries may reference other libraries, either bundled with the application or installed separately, using any of the techniques described herein. hope this helps. Greetings and thanks for working on this issue, Frank Class-Path entry in WAR manifest didn't work if entry is a directory Key: GERONIMO-4251 URL: https://issues.apache.org/jira/browse/GERONIMO-4251 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2 Environment: Geronimo 2.1.2 on Windows XP Reporter: Frank Meilinger Fix For: 2.1.4, 2.2 Hi, it's not possible to define an Class-Path element in the WARs manifest, if it's a directory. I try to access jar files packed in the EARs lib/ directory from within a WAR module. e.g. this will work: Class-Path: a.jar b.jar but this doesn't work: Class-Path: lib/ If a directory is specifyed, I receive the following error: 15:20:13,170 ERROR [DirectoryHotDeployer] Unable to deploy: Manifest class path entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../ org.apache.geronimo.common.DeploymentException: Manifest class path entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../ at
[jira] Commented: (GERONIMO-4251) Class-Path entry in WAR manifest didn't work if entry is a directory
[ https://issues.apache.org/jira/browse/GERONIMO-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12665799#action_12665799 ] Frank Meilinger commented on GERONIMO-4251: --- Hi Ivan, I've insertet a copy of the specification section. But here is a summary of my understanding: a) If an .ear file has a /lib directory, all jar files in this directory (but not subdirectories) are AUTOMATICALLY added to the classpath of all components packaged in this .ear file (ejbs, wars, rars, application clients, ...). It's not necessary to specify this /lib directory in the modules descriptor via the classpath element. The /lib directory is the default name, but the name of the directory may be changed in the .ear deployment descriptor (the library-directory element). This is described in section 2. in 8.2.1. b) Additionally and independend of a) it should be possible to specify jar files AND DIRECTORIES in the classpath element of modules deployment descriptors. e.g. In a WAR manifest the ClassPath entry should allow the following: ClassPath: a.jar b.jar /myLibs c.jar /x/aDirectory/ Which result in a classpath with includes a.jar, b.jar, all jar files in the directory /myLibs, c.jar and all jar files in the directory /x/aDirectory. This behavior is described in section 1. in 8.2.1. in the following sentence: ...The Class-Path entry in the Manifest file is of the form Class-Path: list-of-jar-files-or-directories-separated-by-spaces The Java EE deployment tools must process all such referenced files and directories when processing a Java EE module. ... Greetings, Frank Class-Path entry in WAR manifest didn't work if entry is a directory Key: GERONIMO-4251 URL: https://issues.apache.org/jira/browse/GERONIMO-4251 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2 Environment: Geronimo 2.1.2 on Windows XP Reporter: Frank Meilinger Fix For: 2.1.4, 2.2 Hi, it's not possible to define an Class-Path element in the WARs manifest, if it's a directory. I try to access jar files packed in the EARs lib/ directory from within a WAR module. e.g. this will work: Class-Path: a.jar b.jar but this doesn't work: Class-Path: lib/ If a directory is specifyed, I receive the following error: 15:20:13,170 ERROR [DirectoryHotDeployer] Unable to deploy: Manifest class path entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../ org.apache.geronimo.common.DeploymentException: Manifest class path entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../ at org.apache.geronimo.deployment.DeploymentContext.addManifestClassPath (DeploymentContext.java:419) ... I think this is definitely an error because the JEE5 specification section 8.2.1 explicitely allows directories in manifest Class-Path entries. See discussion: http://www.nabble.com/EAR-bundle-dir-classpath-issue-tt18982334s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r736042 - in /geronimo/server/trunk/framework/modules: geronimo-jmx-remoting/src/main/java/org/apache/geronimo/jmxremoting/JMXConnector.java geronimo-kernel/src/main/java/org/apache/
So, should the createSocket() default to localhost? That way, if a user
has mapped the server to bind to a specific interface (like 192.168.1.x)
then they should expect to have to supply the IP address/hostname of the
server?
-Donald
Jarek Gawor wrote:
Donald,
I was looking at this patch but I didn't have a chance to test it and
comment on the bug but I think this fix is not right. It effectively
ignores the host parameter passed in the createSocket() call. So if
you have two running servers one local and one remote and both have
set sub. property hostname=127.0.0.1 and you issue shutdown -h remote
server host command on the local machine, the local server will be
shutdown!
Jarek
On Tue, Jan 20, 2009 at 12:19 PM, dwo...@apache.org wrote:
Author: dwoods
Date: Tue Jan 20 09:19:57 2009
New Revision: 736042
URL: http://svn.apache.org/viewvc?rev=736042view=rev
Log:
GERONIMO-4518 Can't shutdown the server when host was set to 127.0.0.1 in
config-substitutions.properties. Applied patch from Shawn Jiang.
Modified:
geronimo/server/trunk/framework/modules/geronimo-jmx-remoting/src/main/java/org/apache/geronimo/jmxremoting/JMXConnector.java
geronimo/server/trunk/framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/rmi/GeronimoRMIClientSocketFactory.java
Modified:
geronimo/server/trunk/framework/modules/geronimo-jmx-remoting/src/main/java/org/apache/geronimo/jmxremoting/JMXConnector.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/framework/modules/geronimo-jmx-remoting/src/main/java/org/apache/geronimo/jmxremoting/JMXConnector.java?rev=736042r1=736041r2=736042view=diff
==
---
geronimo/server/trunk/framework/modules/geronimo-jmx-remoting/src/main/java/org/apache/geronimo/jmxremoting/JMXConnector.java
(original)
+++
geronimo/server/trunk/framework/modules/geronimo-jmx-remoting/src/main/java/org/apache/geronimo/jmxremoting/JMXConnector.java
Tue Jan 20 09:19:57 2009
@@ -188,7 +188,7 @@
} else {
log.warn(Starting unauthenticating JMXConnector for +
jmxServiceURL);
}
-RMIClientSocketFactory socketFactory = new
GeronimoRMIClientSocketFactory(2 * 60 * 1000, 5 * 60 * 1000);
+RMIClientSocketFactory socketFactory = new
GeronimoRMIClientSocketFactory(host, 2 * 60 * 1000, 5 * 60 * 1000);
env.put(RMIConnectorServer.RMI_CLIENT_SOCKET_FACTORY_ATTRIBUTE,
socketFactory);
RMIServerSocketFactory serverSocketFactory = new
GeronimoRMIServerSocketFactory(host);
env.put(RMIConnectorServer.RMI_SERVER_SOCKET_FACTORY_ATTRIBUTE,
serverSocketFactory);
Modified:
geronimo/server/trunk/framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/rmi/GeronimoRMIClientSocketFactory.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/rmi/GeronimoRMIClientSocketFactory.java?rev=736042r1=736041r2=736042view=diff
==
---
geronimo/server/trunk/framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/rmi/GeronimoRMIClientSocketFactory.java
(original)
+++
geronimo/server/trunk/framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/rmi/GeronimoRMIClientSocketFactory.java
Tue Jan 20 09:19:57 2009
@@ -31,15 +31,20 @@
private int connectionTimeout = -1;
private int readTimeout = -1;
+private String host=null;
-public GeronimoRMIClientSocketFactory(int connectionTimeout, int
readTimeout) {
+public GeronimoRMIClientSocketFactory(String _host,int connectionTimeout,
int readTimeout) {
+this.host=_host;
this.connectionTimeout = connectionTimeout;
this.readTimeout = readTimeout;
}
-public Socket createSocket(String host, int port) throws IOException {
+public Socket createSocket(String _host, int port) throws IOException {
Socket socket = new Socket();
-socket.bind(null);
+socket.bind(null);
+if(host==null){
+host=_host;
+}
socket.connect(new InetSocketAddress(host, port), (this.connectionTimeout
0) ? this.connectionTimeout : 0);
if (this.readTimeout = 0) {
socket.setSoTimeout(this.readTimeout);
[jira] Reopened: (GERONIMO-4518) Can't shutdown the server when host was set to 127.0.0.1 in config-substitutions.properties
[ https://issues.apache.org/jira/browse/GERONIMO-4518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reopened GERONIMO-4518: Jarek pointed out a problem with the patch. Can't shutdown the server when host was set to 127.0.0.1 in config-substitutions.properties --- Key: GERONIMO-4518 URL: https://issues.apache.org/jira/browse/GERONIMO-4518 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1.4, 2.2 Environment: Windows XP + Sun JDK 1.5 Reporter: Shawn Jiang Assignee: Donald Woods Priority: Blocker Fix For: 2.1.4, 2.2 Attachments: G4518_Shawn.patch 1, change the host in config-substitutions.properties to 127.0.0.1 2, start the server. 3, shutdown the server. *expected result*: the server could be shutdown. *actual result*: the sever can't be shutdown with exception: java.net.ConnectException: Connection refused: connect -- C:\geronimo-tomcat6-javaee5-2.2-SNAPSHOT\binshutdown --host 127.0.0.1 Using GERONIMO_HOME: C:\geronimo-tomcat6-javaee5-2.2-SNAPSHOT Using GERONIMO_TMPDIR: var\temp Using JRE_HOME:D:\dev\JDKs\sun_jdk1.5.0_15\jre log4j:WARN No appenders could be found for logger (org.apache.geronimo.kernel.basic.BasicKernel). log4j:WARN Please initialize the log4j system properly. Username: system Password: *** Locating server on 127.0.0.1:1099... Could not communicate with the server. The server may not be running or the port number may be inco rrect (Connection refused to host: 6.153.277.58; nested exception is: java.net.ConnectException: Connection refused: connect) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4251) Class-Path entry in WAR manifest didn't work if entry is a directory
[ https://issues.apache.org/jira/browse/GERONIMO-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMO-4251: -- Assignee: Ivan Class-Path entry in WAR manifest didn't work if entry is a directory Key: GERONIMO-4251 URL: https://issues.apache.org/jira/browse/GERONIMO-4251 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2 Environment: Geronimo 2.1.2 on Windows XP Reporter: Frank Meilinger Assignee: Ivan Fix For: 2.1.4, 2.2 Hi, it's not possible to define an Class-Path element in the WARs manifest, if it's a directory. I try to access jar files packed in the EARs lib/ directory from within a WAR module. e.g. this will work: Class-Path: a.jar b.jar but this doesn't work: Class-Path: lib/ If a directory is specifyed, I receive the following error: 15:20:13,170 ERROR [DirectoryHotDeployer] Unable to deploy: Manifest class path entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../ org.apache.geronimo.common.DeploymentException: Manifest class path entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../ at org.apache.geronimo.deployment.DeploymentContext.addManifestClassPath (DeploymentContext.java:419) ... I think this is definitely an error because the JEE5 specification section 8.2.1 explicitely allows directories in manifest Class-Path entries. See discussion: http://www.nabble.com/EAR-bundle-dir-classpath-issue-tt18982334s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4508) Spring AOP AspectJ conflict when using Apache CXF
[ https://issues.apache.org/jira/browse/GERONIMO-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12665879#action_12665879 ] Jarek Gawor commented on GERONIMO-4508: --- I'm confused. Didn't Kevan's [suggestions | https://issues.apache.org/jira/browse/GERONIMO-4508?focusedCommentId=12663337#action_12663337] work? With that enabled and by including the spring jars with your application there should be no conflicts or problems with the spring version included in Geronimo. Spring AOP AspectJ conflict when using Apache CXF - Key: GERONIMO-4508 URL: https://issues.apache.org/jira/browse/GERONIMO-4508 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Environment: Spring 2.5.6, Geronimo JEE Tomcat 2.1.3, AspectJ 1.6.2 Reporter: Bruno César Brito Sant'Anna Attachments: jetty_trace.txt, trace.txt I'm trying to create a WebService Bean on Geronimo using Spring IoC container. Well, I followed this tutorial http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html My GERONIMO_OPTS var value is -Dorg.apache.geronimo.jaxws.provider=cxf -Dorg.apache.geronimo.saaj.provider=axis2 -Dorg.apache.cxf.jaxws.checkPublishEndpointPermission=false When server starts, when reading Spring AOC Config my server crashes... Summary stack trace: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.aop.support.DefaultBeanFactoryPointcutAdvisor': Instantiation of bean failed; nested exception is java.lang.AbstractMethodError: org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.determineConstructor(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/reflect/Constructor; It took me several hours to discover that cxf environment was messing around with Spring... reseting GERONIMO_OPTS and removing cxf webservice stuff from my applicationContext.xml made my server run again. Looks like I cannot use CXF with AOP... I'll attach full stack trace... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: xbean 3.5 release?
On Tue, Jan 20, 2009 at 6:24 PM, Joe Bohn joe.b...@earthlink.net wrote: What is the status of the asm shading issue? Can we pursue a release yet? Go with it. If I don't finish it before the release goes out it's to be included in the next one. Jacek -- Jacek Laskowski Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
[jira] Commented: (GERONIMO-4508) Spring AOP AspectJ conflict when using Apache CXF
[ https://issues.apache.org/jira/browse/GERONIMO-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12665911#action_12665911 ] Bruno César Brito Sant'Anna commented on GERONIMO-4508: --- Jarek, I've tried Kevan's first suggestion, which was downgrading spring to 2.0.5... it worked partially but as I said before (https://issues.apache.org/jira/browse/GERONIMO-4508?focusedCommentId=12665440#action_12665440) i had other problems... Now with your post I decided to modify geronimo-application.xml, (I confess you I hadn't modified it before)... I tried some workarounds but other problems appeared: 1st (attached file: dep_trace.txt) Added this to geronimo_application.xml (below dep:moduleId) dep:hidden-classes dep:filterorg.springframework./dep:filter /dep:hidden-classes and... got this error: org.springframework.beans.FatalBeanException: Class [org.apache.cxf.jaxws.spring.NamespaceHandler] for namespace [http://cxf.apache.org/jaxws] does not implement the [org.springframework.beans.factory.xml.NamespaceHandler] interface 2nd (attached file: dep_trace_2.txt) I downloaded cxf version 2.1.3, added cxf-2.1.3 to EarContent/lib and manifest.mf, modified geronimo_application.xml to dep:hidden-classes dep:filterorg.springframework./dep:filter dep:filterorg.apache.cxf./dep:filter /dep:hidden-classes and... got this error: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'accountWebServiceEndpoint': Invocation of init method failed; nested exception is java.lang.NoClassDefFoundError: javax/xml/ws/soap/MTOM 3rd (attached file: dep_trace_3.txt) added geronimo-jaxws_2.1_spec-1.0.jar and jaxb-api-2.1.jar to EarContent/lib and manifest.ml and tried again... got this error (when creating webservice endpoint): org.apache.cxf.service.factory.ServiceConstructionException: Could not resolve a binding for http://schemas.xmlsoap.org/soap/ ... I hope geronimo 2.2 can solve this issue since its related to library versions... Spring AOP AspectJ conflict when using Apache CXF - Key: GERONIMO-4508 URL: https://issues.apache.org/jira/browse/GERONIMO-4508 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Environment: Spring 2.5.6, Geronimo JEE Tomcat 2.1.3, AspectJ 1.6.2 Reporter: Bruno César Brito Sant'Anna Attachments: jetty_trace.txt, trace.txt I'm trying to create a WebService Bean on Geronimo using Spring IoC container. Well, I followed this tutorial http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html My GERONIMO_OPTS var value is -Dorg.apache.geronimo.jaxws.provider=cxf -Dorg.apache.geronimo.saaj.provider=axis2 -Dorg.apache.cxf.jaxws.checkPublishEndpointPermission=false When server starts, when reading Spring AOC Config my server crashes... Summary stack trace: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.aop.support.DefaultBeanFactoryPointcutAdvisor': Instantiation of bean failed; nested exception is java.lang.AbstractMethodError: org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.determineConstructor(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/reflect/Constructor; It took me several hours to discover that cxf environment was messing around with Spring... reseting GERONIMO_OPTS and removing cxf webservice stuff from my applicationContext.xml made my server run again. Looks like I cannot use CXF with AOP... I'll attach full stack trace... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4508) Spring AOP AspectJ conflict when using Apache CXF
[ https://issues.apache.org/jira/browse/GERONIMO-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno César Brito Sant'Anna updated GERONIMO-4508: -- Attachment: dep_trace_3.txt Spring AOP AspectJ conflict when using Apache CXF - Key: GERONIMO-4508 URL: https://issues.apache.org/jira/browse/GERONIMO-4508 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Environment: Spring 2.5.6, Geronimo JEE Tomcat 2.1.3, AspectJ 1.6.2 Reporter: Bruno César Brito Sant'Anna Attachments: dep_trace.txt, dep_trace_2.txt, dep_trace_3.txt, jetty_trace.txt, trace.txt I'm trying to create a WebService Bean on Geronimo using Spring IoC container. Well, I followed this tutorial http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html My GERONIMO_OPTS var value is -Dorg.apache.geronimo.jaxws.provider=cxf -Dorg.apache.geronimo.saaj.provider=axis2 -Dorg.apache.cxf.jaxws.checkPublishEndpointPermission=false When server starts, when reading Spring AOC Config my server crashes... Summary stack trace: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.aop.support.DefaultBeanFactoryPointcutAdvisor': Instantiation of bean failed; nested exception is java.lang.AbstractMethodError: org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.determineConstructor(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/reflect/Constructor; It took me several hours to discover that cxf environment was messing around with Spring... reseting GERONIMO_OPTS and removing cxf webservice stuff from my applicationContext.xml made my server run again. Looks like I cannot use CXF with AOP... I'll attach full stack trace... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4508) Spring AOP AspectJ conflict when using Apache CXF
[ https://issues.apache.org/jira/browse/GERONIMO-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno César Brito Sant'Anna updated GERONIMO-4508: -- Attachment: dep_trace_2.txt Spring AOP AspectJ conflict when using Apache CXF - Key: GERONIMO-4508 URL: https://issues.apache.org/jira/browse/GERONIMO-4508 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Environment: Spring 2.5.6, Geronimo JEE Tomcat 2.1.3, AspectJ 1.6.2 Reporter: Bruno César Brito Sant'Anna Attachments: dep_trace.txt, dep_trace_2.txt, dep_trace_3.txt, jetty_trace.txt, trace.txt I'm trying to create a WebService Bean on Geronimo using Spring IoC container. Well, I followed this tutorial http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html My GERONIMO_OPTS var value is -Dorg.apache.geronimo.jaxws.provider=cxf -Dorg.apache.geronimo.saaj.provider=axis2 -Dorg.apache.cxf.jaxws.checkPublishEndpointPermission=false When server starts, when reading Spring AOC Config my server crashes... Summary stack trace: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.aop.support.DefaultBeanFactoryPointcutAdvisor': Instantiation of bean failed; nested exception is java.lang.AbstractMethodError: org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.determineConstructor(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/reflect/Constructor; It took me several hours to discover that cxf environment was messing around with Spring... reseting GERONIMO_OPTS and removing cxf webservice stuff from my applicationContext.xml made my server run again. Looks like I cannot use CXF with AOP... I'll attach full stack trace... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4508) Spring AOP AspectJ conflict when using Apache CXF
[ https://issues.apache.org/jira/browse/GERONIMO-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno César Brito Sant'Anna updated GERONIMO-4508: -- Attachment: dep_trace.txt Spring AOP AspectJ conflict when using Apache CXF - Key: GERONIMO-4508 URL: https://issues.apache.org/jira/browse/GERONIMO-4508 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Environment: Spring 2.5.6, Geronimo JEE Tomcat 2.1.3, AspectJ 1.6.2 Reporter: Bruno César Brito Sant'Anna Attachments: dep_trace.txt, dep_trace_2.txt, dep_trace_3.txt, jetty_trace.txt, trace.txt I'm trying to create a WebService Bean on Geronimo using Spring IoC container. Well, I followed this tutorial http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html My GERONIMO_OPTS var value is -Dorg.apache.geronimo.jaxws.provider=cxf -Dorg.apache.geronimo.saaj.provider=axis2 -Dorg.apache.cxf.jaxws.checkPublishEndpointPermission=false When server starts, when reading Spring AOC Config my server crashes... Summary stack trace: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.aop.support.DefaultBeanFactoryPointcutAdvisor': Instantiation of bean failed; nested exception is java.lang.AbstractMethodError: org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.determineConstructor(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/reflect/Constructor; It took me several hours to discover that cxf environment was messing around with Spring... reseting GERONIMO_OPTS and removing cxf webservice stuff from my applicationContext.xml made my server run again. Looks like I cannot use CXF with AOP... I'll attach full stack trace... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4508) Spring AOP AspectJ conflict when using Apache CXF
[ https://issues.apache.org/jira/browse/GERONIMO-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12665912#action_12665912 ] Bruno César Brito Sant'Anna commented on GERONIMO-4508: --- by the way... are those dates intended to be postponed? http://cwiki.apache.org/GMOxPMGT/geronimo-22-release-status.html Spring AOP AspectJ conflict when using Apache CXF - Key: GERONIMO-4508 URL: https://issues.apache.org/jira/browse/GERONIMO-4508 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Environment: Spring 2.5.6, Geronimo JEE Tomcat 2.1.3, AspectJ 1.6.2 Reporter: Bruno César Brito Sant'Anna Attachments: dep_trace.txt, dep_trace_2.txt, dep_trace_3.txt, jetty_trace.txt, trace.txt I'm trying to create a WebService Bean on Geronimo using Spring IoC container. Well, I followed this tutorial http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html My GERONIMO_OPTS var value is -Dorg.apache.geronimo.jaxws.provider=cxf -Dorg.apache.geronimo.saaj.provider=axis2 -Dorg.apache.cxf.jaxws.checkPublishEndpointPermission=false When server starts, when reading Spring AOC Config my server crashes... Summary stack trace: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.aop.support.DefaultBeanFactoryPointcutAdvisor': Instantiation of bean failed; nested exception is java.lang.AbstractMethodError: org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.determineConstructor(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/reflect/Constructor; It took me several hours to discover that cxf environment was messing around with Spring... reseting GERONIMO_OPTS and removing cxf webservice stuff from my applicationContext.xml made my server run again. Looks like I cannot use CXF with AOP... I'll attach full stack trace... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4508) Spring AOP AspectJ conflict when using Apache CXF
[ https://issues.apache.org/jira/browse/GERONIMO-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno César Brito Sant'Anna updated GERONIMO-4508: -- Comment: was deleted Spring AOP AspectJ conflict when using Apache CXF - Key: GERONIMO-4508 URL: https://issues.apache.org/jira/browse/GERONIMO-4508 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Environment: Spring 2.5.6, Geronimo JEE Tomcat 2.1.3, AspectJ 1.6.2 Reporter: Bruno César Brito Sant'Anna Attachments: dep_trace.txt, dep_trace_2.txt, dep_trace_3.txt, jetty_trace.txt, trace.txt I'm trying to create a WebService Bean on Geronimo using Spring IoC container. Well, I followed this tutorial http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html My GERONIMO_OPTS var value is -Dorg.apache.geronimo.jaxws.provider=cxf -Dorg.apache.geronimo.saaj.provider=axis2 -Dorg.apache.cxf.jaxws.checkPublishEndpointPermission=false When server starts, when reading Spring AOC Config my server crashes... Summary stack trace: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.aop.support.DefaultBeanFactoryPointcutAdvisor': Instantiation of bean failed; nested exception is java.lang.AbstractMethodError: org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.determineConstructor(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/reflect/Constructor; It took me several hours to discover that cxf environment was messing around with Spring... reseting GERONIMO_OPTS and removing cxf webservice stuff from my applicationContext.xml made my server run again. Looks like I cannot use CXF with AOP... I'll attach full stack trace... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4508) Spring AOP AspectJ conflict when using Apache CXF
[ https://issues.apache.org/jira/browse/GERONIMO-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12665915#action_12665915 ] Bruno César Brito Sant'Anna commented on GERONIMO-4508: --- BTW, are those dates intended to be postponed? http://cwiki.apache.org/GMOxPMGT/geronimo-22-release-status.html I don't want to build geronimo 2.2 in my environment, I prefer to wait until it release if it really happens in 01/30/2009... Spring AOP AspectJ conflict when using Apache CXF - Key: GERONIMO-4508 URL: https://issues.apache.org/jira/browse/GERONIMO-4508 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Environment: Spring 2.5.6, Geronimo JEE Tomcat 2.1.3, AspectJ 1.6.2 Reporter: Bruno César Brito Sant'Anna Attachments: dep_trace.txt, dep_trace_2.txt, dep_trace_3.txt, jetty_trace.txt, trace.txt I'm trying to create a WebService Bean on Geronimo using Spring IoC container. Well, I followed this tutorial http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html My GERONIMO_OPTS var value is -Dorg.apache.geronimo.jaxws.provider=cxf -Dorg.apache.geronimo.saaj.provider=axis2 -Dorg.apache.cxf.jaxws.checkPublishEndpointPermission=false When server starts, when reading Spring AOC Config my server crashes... Summary stack trace: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.aop.support.DefaultBeanFactoryPointcutAdvisor': Instantiation of bean failed; nested exception is java.lang.AbstractMethodError: org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.determineConstructor(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/reflect/Constructor; It took me several hours to discover that cxf environment was messing around with Spring... reseting GERONIMO_OPTS and removing cxf webservice stuff from my applicationContext.xml made my server run again. Looks like I cannot use CXF with AOP... I'll attach full stack trace... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4508) Spring AOP AspectJ conflict when using Apache CXF
[ https://issues.apache.org/jira/browse/GERONIMO-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12665917#action_12665917 ] Jarek Gawor commented on GERONIMO-4508: --- Ok. First, make sure to add BOTH filters for spring (for classes and resources): dep:filterorg.springframework./dep:filter dep:filterMETA-INF/spring/dep:filter for CXF classes add: dep:filterorg.apache.cxf./dep:filter and since you want to use CXF 2.1.3 which is based on JAX-WS 2.1 and Geronimo 2.1.3 supports JAX-WS 2.0 you also have to filter additional classes (something like): dep:filterjavax.xml.ws/dep:filter dep:filterjavax.xml.bind/dep:filter dep:filtercom.sun.xml.bind/dep:filter Spring AOP AspectJ conflict when using Apache CXF - Key: GERONIMO-4508 URL: https://issues.apache.org/jira/browse/GERONIMO-4508 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Environment: Spring 2.5.6, Geronimo JEE Tomcat 2.1.3, AspectJ 1.6.2 Reporter: Bruno César Brito Sant'Anna Attachments: dep_trace.txt, dep_trace_2.txt, dep_trace_3.txt, jetty_trace.txt, trace.txt I'm trying to create a WebService Bean on Geronimo using Spring IoC container. Well, I followed this tutorial http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html My GERONIMO_OPTS var value is -Dorg.apache.geronimo.jaxws.provider=cxf -Dorg.apache.geronimo.saaj.provider=axis2 -Dorg.apache.cxf.jaxws.checkPublishEndpointPermission=false When server starts, when reading Spring AOC Config my server crashes... Summary stack trace: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.aop.support.DefaultBeanFactoryPointcutAdvisor': Instantiation of bean failed; nested exception is java.lang.AbstractMethodError: org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.determineConstructor(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/reflect/Constructor; It took me several hours to discover that cxf environment was messing around with Spring... reseting GERONIMO_OPTS and removing cxf webservice stuff from my applicationContext.xml made my server run again. Looks like I cannot use CXF with AOP... I'll attach full stack trace... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4508) Spring AOP AspectJ conflict when using Apache CXF
[ https://issues.apache.org/jira/browse/GERONIMO-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12665918#action_12665918 ] Jarek Gawor commented on GERONIMO-4508: --- Btw, you can experiment with 2.2-SNAPSHOT right now, just download a binary and see: http://people.apache.org/builds/geronimo/server/binaries/trunk/latest/ Spring AOP AspectJ conflict when using Apache CXF - Key: GERONIMO-4508 URL: https://issues.apache.org/jira/browse/GERONIMO-4508 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Environment: Spring 2.5.6, Geronimo JEE Tomcat 2.1.3, AspectJ 1.6.2 Reporter: Bruno César Brito Sant'Anna Attachments: dep_trace.txt, dep_trace_2.txt, dep_trace_3.txt, jetty_trace.txt, trace.txt I'm trying to create a WebService Bean on Geronimo using Spring IoC container. Well, I followed this tutorial http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html My GERONIMO_OPTS var value is -Dorg.apache.geronimo.jaxws.provider=cxf -Dorg.apache.geronimo.saaj.provider=axis2 -Dorg.apache.cxf.jaxws.checkPublishEndpointPermission=false When server starts, when reading Spring AOC Config my server crashes... Summary stack trace: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.aop.support.DefaultBeanFactoryPointcutAdvisor': Instantiation of bean failed; nested exception is java.lang.AbstractMethodError: org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.determineConstructor(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/reflect/Constructor; It took me several hours to discover that cxf environment was messing around with Spring... reseting GERONIMO_OPTS and removing cxf webservice stuff from my applicationContext.xml made my server run again. Looks like I cannot use CXF with AOP... I'll attach full stack trace... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4508) Spring AOP AspectJ conflict when using Apache CXF
[ https://issues.apache.org/jira/browse/GERONIMO-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12665923#action_12665923 ] Bruno César Brito Sant'Anna commented on GERONIMO-4508: --- CXF 2.1.3, I don't really want... I preffer to use geronimo cxf ws engine... but removing dep:filterorg.apache.cxf./dep:filter leads to : Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from class path resource [META-INF/common/applicationContext.xml]; nested exception is org.springframework.beans.FatalBeanException: Class [org.apache.cxf.jaxws.spring.NamespaceHandler] for namespace [http://cxf.apache.org/jaxws] does not implement the [org.springframework.beans.factory.xml.NamespaceHandler] interface ... thanks for the link, I haven't found it before... Spring AOP AspectJ conflict when using Apache CXF - Key: GERONIMO-4508 URL: https://issues.apache.org/jira/browse/GERONIMO-4508 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Environment: Spring 2.5.6, Geronimo JEE Tomcat 2.1.3, AspectJ 1.6.2 Reporter: Bruno César Brito Sant'Anna Attachments: dep_trace.txt, dep_trace_2.txt, dep_trace_3.txt, jetty_trace.txt, trace.txt I'm trying to create a WebService Bean on Geronimo using Spring IoC container. Well, I followed this tutorial http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html My GERONIMO_OPTS var value is -Dorg.apache.geronimo.jaxws.provider=cxf -Dorg.apache.geronimo.saaj.provider=axis2 -Dorg.apache.cxf.jaxws.checkPublishEndpointPermission=false When server starts, when reading Spring AOC Config my server crashes... Summary stack trace: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.aop.support.DefaultBeanFactoryPointcutAdvisor': Instantiation of bean failed; nested exception is java.lang.AbstractMethodError: org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.determineConstructor(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/reflect/Constructor; It took me several hours to discover that cxf environment was messing around with Spring... reseting GERONIMO_OPTS and removing cxf webservice stuff from my applicationContext.xml made my server run again. Looks like I cannot use CXF with AOP... I'll attach full stack trace... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4475) Improve JMS portlet for Borker configuration
[
https://issues.apache.org/jira/browse/GERONIMO-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donald Woods resolved GERONIMO-4475.
Resolution: Fixed
Applied the 4 patches to trunk (2.2-SNAPSHOT) as Rev736391. Ivan, thanks for
the patches.
Also, can we look at adding some portlet help or links to the 2.2 Docs on how
to update the activemq.xml content and some simple examples? The usage of
${activemq.*} has made it even harder to understand what to change or how
config-substitutions.properties will be used.
Improve JMS portlet for Borker configuration
Key: GERONIMO-4475
URL: https://issues.apache.org/jira/browse/GERONIMO-4475
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: console
Affects Versions: 2.2
Reporter: Ivan
Assignee: Donald Woods
Fix For: 2.2
Attachments: G4475-activemq-broker.patch,
G4475-activemq-portlet-update-02.patch, G4475-geronimo-activemq.patch,
G4475-geronimo-management.patch
Currently in the administrator console, the users could not add another embed
broker. Also, they could not edit the broker through administrator console.
I list the features that I could see :
1. While creating the broker, let the use upload a configuration file.
2. While editing the broker, show a text area, so that the user could edit
the spring XML file in it. Shall we give the user a more friendly interface,
so that they do not need the edit the XML file directly. I am not sure how it
should look like.
3. Update the connector port let, so that while creating a new connector,
the user could specify the broker that it belongs to.
Please help to give some comments !
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4475) Improve JMS portlet for AMQ 5.3 Borker configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-4475: --- Summary: Improve JMS portlet for AMQ 5.3 Borker configuration (was: Improve JMS portlet for Borker configuration) updating title to include ref to AMQ 5.3 Improve JMS portlet for AMQ 5.3 Borker configuration Key: GERONIMO-4475 URL: https://issues.apache.org/jira/browse/GERONIMO-4475 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Reporter: Ivan Assignee: Donald Woods Fix For: 2.2 Attachments: G4475-activemq-broker.patch, G4475-activemq-portlet-update-02.patch, G4475-geronimo-activemq.patch, G4475-geronimo-management.patch Currently in the administrator console, the users could not add another embed broker. Also, they could not edit the broker through administrator console. I list the features that I could see : 1. While creating the broker, let the use upload a configuration file. 2. While editing the broker, show a text area, so that the user could edit the spring XML file in it. Shall we give the user a more friendly interface, so that they do not need the edit the XML file directly. I am not sure how it should look like. 3. Update the connector port let, so that while creating a new connector, the user could specify the broker that it belongs to. Please help to give some comments ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4501) Tomcat/Axis ignores jax-ws-catalog.xml while resolving wsdlLocation URLs
[
https://issues.apache.org/jira/browse/GERONIMO-4501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12665948#action_12665948
]
Jarek Gawor commented on GERONIMO-4501:
---
Committed additional changes (to trunk) to make service-ref work with OASIS
catalogs with Axis2 (revision 736396).
Tomcat/Axis ignores jax-ws-catalog.xml while resolving wsdlLocation URLs
Key: GERONIMO-4501
URL: https://issues.apache.org/jira/browse/GERONIMO-4501
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.2
Environment: Geronimo 2.2-SNAPSHOT, Tomcat/Axis
Reporter: Janko Heilgeist
Assignee: Jarek Gawor
The problem description's context is identical to GERONIMO-4500 for the
Jetty/CXF assembly. This time the catalog is completely ignored while
resolving the wsdlLocation URL. The exception is:
{noformat}
2009-01-07 17:45:17,701 ERROR [GBeanInstanceState] Error while starting;
GBean is now in the FAILED state:
abstractName=default/geronimo-wsdllocation-jetty_cxf-1.0-SNAPSHOT.jar/1231346713744/car?EJBModule=default/geronimo-wsdllocation-jetty_cxf-1.0-SNAPSHOT.jar/1231346713744/car,J2EEApplication=null,StatelessSessionBean=HelloWorldServiceEJB,j2eeType=WSLink,name=HelloWorldServiceEJB
java.io.FileNotFoundException: http://example.com/HelloWorld.wsdl
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1172)
at java.net.URL.openStream(URL.java:1007)
at
org.apache.geronimo.axis2.AxisServiceGenerator.readWSDL(AxisServiceGenerator.java:302)
at
org.apache.geronimo.axis2.AxisServiceGenerator.getServiceFromWSDL(AxisServiceGenerator.java:141)
at
org.apache.geronimo.axis2.Axis2WebServiceContainer.init(Axis2WebServiceContainer.java:145)
at
org.apache.geronimo.axis2.ejb.EJBWebServiceContainer.init(EJBWebServiceContainer.java:56)
at
org.apache.geronimo.axis2.ejb.EJBWebServiceGBean.init(EJBWebServiceGBean.java:70)
...
{noformat}
The workaround that helped in the case of the Jetty/CXF assembly does not
work with Tomcat/Axis.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Tuscany Geronimo integration and the SCA JEE spec
The plugin works with JDK6 update 7. However we have issue, including dependent jars within the the sca service jar we create. We have developed sca service which depends on number of external jars. we can compile and build the jar using maven. but when we deploy to Geronimo, it cannot find the classes as those are in the dependent jars whcih are not part of sca composite jar. Any one has any idea how to resolve this issue. Kevan Miller wrote: On Dec 3, 2008, at 10:03 AM, ant elder wrote: Its working ok for me too. One thing to note though is that it currently only works when running Geronimo with JDK5 not JDK6. Hmm. Thanks. I'll give it another try... And see what's failing. --kevan -- View this message in context: http://www.nabble.com/Tuscany-Geronimo-integration-and-the-SCA-JEE-spec-tp19794900s134p21591514.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[jira] Resolved: (GERONIMODEVTOOLS-559) GEP signed feature jar(s) should not display nulls when asking the user if they trust the certificate(s)
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell resolved GERONIMODEVTOOLS-559. Resolution: Fixed Fix Version/s: 2.1.4 2.2.0 Thanks Delos, it now looks much better !! The organization and organization unit is now filled in (i.e., not displaying null), plus the expiration date is now 10 years. Thanks for the patch !! GEP signed feature jar(s) should not display nulls when asking the user if they trust the certificate(s) -- Key: GERONIMODEVTOOLS-559 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-559 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.2.0, 2.1.4 Reporter: Tim McConnell Assignee: Delos Dai Fix For: 2.2.0, 2.1.4 Attachments: 559.patch, screenshot-1.jpg, screenshot-2.jpg It seems that as a result of GERONIMODEVTOOLS-521 our jar(s) are signed. However as they are now they may likely cause more confusion with the end-user, rather then instill confidence. When the Eclipse installer discovers they are signed it asks the end-user if they trust the certificate(s). The one for the GEP feature displays too many nulls -- these values should be populated to mitigate possible confusion. I'll attach a screenshot to show what exactly I mean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4475) Improve JMS portlet for AMQ 5.3 Borker configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666037#action_12666037 ] Ivan commented on GERONIMO-4475: Thanks, Donald, I will prepare a doc for the JMS portlet soon. Improve JMS portlet for AMQ 5.3 Borker configuration Key: GERONIMO-4475 URL: https://issues.apache.org/jira/browse/GERONIMO-4475 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Reporter: Ivan Assignee: Donald Woods Fix For: 2.2 Attachments: G4475-activemq-broker.patch, G4475-activemq-portlet-update-02.patch, G4475-geronimo-activemq.patch, G4475-geronimo-management.patch Currently in the administrator console, the users could not add another embed broker. Also, they could not edit the broker through administrator console. I list the features that I could see : 1. While creating the broker, let the use upload a configuration file. 2. While editing the broker, show a text area, so that the user could edit the spring XML file in it. Shall we give the user a more friendly interface, so that they do not need the edit the XML file directly. I am not sure how it should look like. 3. Update the connector port let, so that while creating a new connector, the user could specify the broker that it belongs to. Please help to give some comments ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] trunk: Failed for Revision: 736531
Geronimo Revision: 736531 built with tests included
See the full build-2100.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090121/build-2100.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090121
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 37 minutes 25 seconds
[INFO] Finished at: Wed Jan 21 21:41:58 EST 2009
[INFO] Final Memory: 641M/980M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090121/logs-2100-tomcat/test.log
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:41.608
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 36 test builds
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deploy RUNNING
[INFO] commands-testsuite/deploy SUCCESS (0:01:00.078)
[INFO] commands-testsuite/gshell RUNNING
[INFO] commands-testsuite/gshell SUCCESS (0:00:28.564)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:33.554)
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:16.419)
[INFO] concurrent-testsuite/concurrent-basic RUNNING
[INFO] concurrent-testsuite/concurrent-basic SUCCESS (0:06:24.419)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:19.422)
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicSUCCESS (0:01:43.356)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:46.227)
[INFO] corba-testsuite/corba-marshal RUNNING
[INFO] corba-testsuite/corba-marshal SUCCESS (0:00:49.959)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:40.438)
[INFO] deployment-testsuite/deployment-tests RUNNING
[INFO] deployment-testsuite/deployment-tests SUCCESS (0:00:29.967)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:30.518)
[INFO] deployment-testsuite/manifestcp-tests RUNNING
[INFO] deployment-testsuite/manifestcp-tests SUCCESS (0:00:33.642)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:49.792)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:55.055)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:50.060)
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:26.800)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:48.115)
[INFO] security-testsuite/test-security RUNNING
[INFO] security-testsuite/test-security FAILURE (0:00:37.426) Java
returned: 1
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:30.063)
[INFO] web-testsuite/test-2.5-servletsRUNNING
[INFO] web-testsuite/test-2.5
[jira] Resolved: (GERONIMO-4481) GShell command jaxws/java2ws error: Syntax error, annotations are only available if source level is 5.0
[ https://issues.apache.org/jira/browse/GERONIMO-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-4481. --- Resolution: Fixed Fix Version/s: 2.2 Assignee: Forrest Xia Resolving as patch for CXF-1992 was committed to CXF trunk and 2.1.x branch and Geronimo will automatically pick up this fix. Thank you Forrest for the patch and your work on this! GShell command jaxws/java2ws error: Syntax error, annotations are only available if source level is 5.0 --- Key: GERONIMO-4481 URL: https://issues.apache.org/jira/browse/GERONIMO-4481 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.2 Environment: java version 1.6.0_10 Java(TM) SE Runtime Environment (build 1.6.0_10-b33) Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing) ubuntu 8.04.1 LTS Reporter: Forrest Xia Assignee: Forrest Xia Priority: Minor Fix For: 2.2 Attachments: G3665FeatureValidation.jar Steps to recurring: 1. start 2.2 snapshot server 2. enter gshell prompt 3. execute command like this: code jaxws/java2ws -wsdl -client -server -wrapperbean -ant -o test.wsdl -s /home/forrestxm/temp/gshell015 -d /home/forrestxm/temp/gshell015 -classdir /home/forrestxm/temp/gshell015 -cp /home/forrestxm/temp/gshell015/G3665FeatureValidation.jar org.apache.geronimo.test.fixver.g3665.SayHelloWebService /code then the errors say Syntax error, annotations are only available if source level is 5.0. Checked cxf 2.1.3 release, there are similar problems when executing a similar command. However, use the generated ant project to compile those generated source code, it's fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4500) Jetty/CXF fails to parse jax-ws-catalog.xml including a DOCTYPE declaration
[
https://issues.apache.org/jira/browse/GERONIMO-4500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarek Gawor updated GERONIMO-4500:
--
Component/s: webservices
Jetty/CXF fails to parse jax-ws-catalog.xml including a DOCTYPE declaration
---
Key: GERONIMO-4500
URL: https://issues.apache.org/jira/browse/GERONIMO-4500
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: webservices
Affects Versions: 2.2
Environment: Geronimo 2.2-SNAPSHOT, Jetty/CXF assembly
Reporter: Janko Heilgeist
Attachments: geronimo-wsdllocation-jetty_cxf-1.0-SNAPSHOT.jar,
geronimo-wsdllocation-jetty_cxf.tar.gz
I've built an EJB-JAR packaging a web service. The JAR contains all classes,
SEI and service stub generated from an existing WSDL (which is also inside
this JAR). Additionally, it contains the actual EJB implementing the web
service.
I tried to annotate the web service implementation with
{code:java}
@WebService( ..., wsdlLocation=http://example.com/myservice.wsdl;)
{code}
and add a META-INF/jax-ws-catalog.xml:
{code:xml}
?xml version=1.0 encoding=UTF-8?
!DOCTYPE catalog PUBLIC -//OASIS//DTD XML Catalogs V1.1//EN
http://www.oasis-open.org/committees/entity/release/1.1/catalog.dtd;
catalog xmlns=urn:oasis:names:tc:entity:xmlns:xml:catalog
system
systemId=http://example.com/myservice.wsdl;
uri=wsdl/myservice.wsdl/
/catalog
{code}
During deployment, the following exception is thrown:
{noformat}
2009-01-07 17:33:53,087 WARN [OASISCatalogManager] Error loading
META-INF/jax-ws-catalog.xml catalog files
java.io.FileNotFoundException:
http://www.oasis-open.org/committees/entity/release/1.1/catalog.dtd
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1172)
at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:973)
at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(XMLEntityManager.java:905)
at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startDTDEntity(XMLEntityManager.java:872)
at
com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImpl.java:282)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(XMLDocumentScannerImpl.java:1021)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:375)
at
org.apache.xml.resolver.readers.SAXCatalogReader.readCatalog(SAXCatalogReader.java:251)
at org.apache.xml.resolver.Catalog.parseCatalog(Catalog.java:681)
at
org.apache.cxf.catalog.OASISCatalogManager.loadCatalogs(OASISCatalogManager.java:108)
at
org.apache.cxf.catalog.OASISCatalogManager.loadContextCatalogs(OASISCatalogManager.java:93)
at
org.apache.cxf.catalog.OASISCatalogManager.loadContextCatalogs(OASISCatalogManager.java:89)
at
org.apache.cxf.catalog.OASISCatalogManager.register(OASISCatalogManager.java:81)
...
{noformat}
As a workaround the DOCTYPE declaration can be removed. Without the
declaration the exception is gone and the wsdlLocation URL is correctly
resolved.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4500) Jetty/CXF fails to parse jax-ws-catalog.xml including a DOCTYPE declaration
[
https://issues.apache.org/jira/browse/GERONIMO-4500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarek Gawor resolved GERONIMO-4500.
---
Resolution: Won't Fix
Assignee: Jarek Gawor
As Dan mentioned the catalog 1.1 dtd is not published at the OASIS web site.
There are a few easy work-arounds, 1) remove the DOCTYPE entry from the catalog
file or 2) change the url to point to some location that does have the 1.1 dtd,
or 3) change the url to point to the 1.0 dtd at the OASIS web site.
Jetty/CXF fails to parse jax-ws-catalog.xml including a DOCTYPE declaration
---
Key: GERONIMO-4500
URL: https://issues.apache.org/jira/browse/GERONIMO-4500
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: webservices
Affects Versions: 2.2
Environment: Geronimo 2.2-SNAPSHOT, Jetty/CXF assembly
Reporter: Janko Heilgeist
Assignee: Jarek Gawor
Attachments: geronimo-wsdllocation-jetty_cxf-1.0-SNAPSHOT.jar,
geronimo-wsdllocation-jetty_cxf.tar.gz
I've built an EJB-JAR packaging a web service. The JAR contains all classes,
SEI and service stub generated from an existing WSDL (which is also inside
this JAR). Additionally, it contains the actual EJB implementing the web
service.
I tried to annotate the web service implementation with
{code:java}
@WebService( ..., wsdlLocation=http://example.com/myservice.wsdl;)
{code}
and add a META-INF/jax-ws-catalog.xml:
{code:xml}
?xml version=1.0 encoding=UTF-8?
!DOCTYPE catalog PUBLIC -//OASIS//DTD XML Catalogs V1.1//EN
http://www.oasis-open.org/committees/entity/release/1.1/catalog.dtd;
catalog xmlns=urn:oasis:names:tc:entity:xmlns:xml:catalog
system
systemId=http://example.com/myservice.wsdl;
uri=wsdl/myservice.wsdl/
/catalog
{code}
During deployment, the following exception is thrown:
{noformat}
2009-01-07 17:33:53,087 WARN [OASISCatalogManager] Error loading
META-INF/jax-ws-catalog.xml catalog files
java.io.FileNotFoundException:
http://www.oasis-open.org/committees/entity/release/1.1/catalog.dtd
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1172)
at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:973)
at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(XMLEntityManager.java:905)
at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startDTDEntity(XMLEntityManager.java:872)
at
com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImpl.java:282)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(XMLDocumentScannerImpl.java:1021)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:375)
at
org.apache.xml.resolver.readers.SAXCatalogReader.readCatalog(SAXCatalogReader.java:251)
at org.apache.xml.resolver.Catalog.parseCatalog(Catalog.java:681)
at
org.apache.cxf.catalog.OASISCatalogManager.loadCatalogs(OASISCatalogManager.java:108)
at
org.apache.cxf.catalog.OASISCatalogManager.loadContextCatalogs(OASISCatalogManager.java:93)
at
org.apache.cxf.catalog.OASISCatalogManager.loadContextCatalogs(OASISCatalogManager.java:89)
at
org.apache.cxf.catalog.OASISCatalogManager.register(OASISCatalogManager.java:81)
...
{noformat}
As a workaround the DOCTYPE declaration can be removed. Without the
declaration the exception is gone and the wsdlLocation URL is correctly
resolved.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
