[jira] Commented: (GERONIMODEVTOOLS-346) Adding security roles in the Geronimo Deployment Plan Editor does not work
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12599413#action_12599413 ] Cedric Hurst commented on GERONIMODEVTOOLS-346: --- Awesome. Thanks so much for following up on this, B.J. I will try this patch out next week and let you know if it works for me. Also, if you need any help or feedback on that second issue, please let me know. Adding security roles in the Geronimo Deployment Plan Editor does not work -- Key: GERONIMODEVTOOLS-346 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-346 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.0 Environment: Eclipse Europa Winter (WTP 2.0.2), Windows XP SP2, Geronimo 2.1.1, GEP 2.1.0, Reporter: Cedric Hurst Assignee: B.J. Reed Fix For: 2.1.1 Attachments: GERONIMODEVTOOLS-346.patch, GERONIMODEVTOOLS-346a.patch Original Estimate: 0h Remaining Estimate: 0h Steps to reproduce === 1. Create a new Enterprise Application Project 2. Open the geronimo-application.xml file in the graphical editor 3. Select the security tab 4. Click the add button in the Security Roles section 5. Provide any value for name and/or description and click Finish Expected behavior === New role will show up in the Security Role list and in the source view of geronimo-application.xml Actual behavior === Role does not show up, nor is it added the the actual xml file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-346) Adding security roles in the Geronimo Deployment Plan Editor does not work
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cedric Hurst updated GERONIMODEVTOOLS-346: -- After running through a few more use cases today, it appears this issue is larger than just the Security tab. I noticed that the General tab is not picking up the Group Id, Artifact Id, Version, or Artifact Type for EJB projects (even when it is defined in the project wizard). Conversely, if I make a change to the values in the General tab, they are not reflected in the Source view (even after saving). Curiously, this problem does not affect geronimo-application.xml files, where the functionality is provided as expected. In addition, I am unable to define any project dependencies in the Deployment tab of any plan (including geronimo-application.xml). The dependencies table does not update, nor does the Source tab does not reflect the changes. In at least some respects, it seems that all graphical tabs (General, Security, Deployment) are non-functional at the moment. Adding security roles in the Geronimo Deployment Plan Editor does not work -- Key: GERONIMODEVTOOLS-346 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-346 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.0 Environment: Eclipse Europa Winter (WTP 2.0.2), Windows XP SP2, Geronimo 2.1.1, GEP 2.1.0, Reporter: Cedric Hurst Assignee: B.J. Reed Fix For: 2.1.1 Attachments: GERONIMODEVTOOLS-346.patch Original Estimate: 0h Remaining Estimate: 0h Steps to reproduce === 1. Create a new Enterprise Application Project 2. Open the geronimo-application.xml file in the graphical editor 3. Select the security tab 4. Click the add button in the Security Roles section 5. Provide any value for name and/or description and click Finish Expected behavior === New role will show up in the Security Role list and in the source view of geronimo-application.xml Actual behavior === Role does not show up, nor is it added the the actual xml file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-350) Update Source view with unsaved changes in Deployment Plan Editor, or prompt user to save before switching to Source view
Update Source view with unsaved changes in Deployment Plan Editor, or prompt user to save before switching to Source view - Key: GERONIMODEVTOOLS-350 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-350 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 2.1.0 Environment: Eclipse Europa Winter, Geronimo 2.1.1, GEP 2.1.0 Reporter: Cedric Hurst Assignee: Tim McConnell Attachments: deploymentPlanUnsavedChanges.avi When editing metadata in one of the graphical views of the Deployment Plan Editor (e.g. General, Security, Deployment), any unsaved changes are not reflected after switching to the Source view. This might be confusing for the user, because the expectation is that they are editing a working copy the values of the fields would be consistently reflected in the Source view. I am proposing two possible options (in order of preference): 1. Update the Source view to reflect unsaved changes 2. Prompt the user to save the Deployment Plan before switching from a graphical view to the Source view I will attach a screencast to better demonstrate the issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-350) Update Source view with unsaved changes in Deployment Plan Editor, or prompt user to save before switching to Source view
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cedric Hurst updated GERONIMODEVTOOLS-350: -- Attachment: deploymentPlanUnsavedChanges.avi Update Source view with unsaved changes in Deployment Plan Editor, or prompt user to save before switching to Source view - Key: GERONIMODEVTOOLS-350 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-350 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 2.1.0 Environment: Eclipse Europa Winter, Geronimo 2.1.1, GEP 2.1.0 Reporter: Cedric Hurst Assignee: Tim McConnell Attachments: deploymentPlanUnsavedChanges.avi When editing metadata in one of the graphical views of the Deployment Plan Editor (e.g. General, Security, Deployment), any unsaved changes are not reflected after switching to the Source view. This might be confusing for the user, because the expectation is that they are editing a working copy the values of the fields would be consistently reflected in the Source view. I am proposing two possible options (in order of preference): 1. Update the Source view to reflect unsaved changes 2. Prompt the user to save the Deployment Plan before switching from a graphical view to the Source view I will attach a screencast to better demonstrate the issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4023) Provide Column Names in the Database Table View of the Admin Console
Provide Column Names in the Database Table View of the Admin Console Key: GERONIMO-4023 URL: https://issues.apache.org/jira/browse/GERONIMO-4023 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console, databases Affects Versions: 2.1.1 Environment: Windows XP SP2, Geronimo 2.1.1 Reporter: Cedric Hurst Priority: Minor In the database table view of the Admin Console, it might be worth adding some column headers in specifying that the first column correlates to the SCHEMA and the second column correlates to the table name. This might avoid confusion for databases where tables exist in multiple schemas. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-348) JSF Tags Not Displayed in Eclipse Web Page Editor
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cedric Hurst updated GERONIMODEVTOOLS-348: -- Attachment: jsf palettes visible.jpg JSF Tags Not Displayed in Eclipse Web Page Editor - Key: GERONIMODEVTOOLS-348 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-348 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.0 Environment: Windows XP SP2, Eclipse Europa Winter Maintenance Release, Geronimo 2.1.1, GEP 2.1.0 Reporter: Cedric Hurst Assignee: Tim McConnell Attachments: jsf palettes visible.jpg Eclipse WTP tooling provides a drag-and-drop palette for various taglibs in its Web Page Editor. When the JSF Project Facet is attached to a Dynamic Web Project, JSF Core and JSF HTML taglibs should be added to the palette (see screenshot). However, this is not the case when using Geronimo/GEP. Steps to Reproduce === 1. Create a new Dynamic Web Project using Geronimo 2.1 as the Targeted Runtime, click Next 2. Add the JavaServer Faces 1.2 Facet to the Project, click Next 3. Accept the default web module settings, click Next 4. In the JSF Capabilities page, select the Server Supplied JSF Implementation option and click Finish 5. Create a new JSP page in the WebContent directory 6. Right click on the new JSP page and open it with the Web Page Editor 7. Expand the Palette in the WYSIWYG pane Expected Behavior === JSF Core and JSF HTML taglibs should be visible in the palette (as per attached screenshot) Actual Behavior === JSF Core and JSF HTML taglibs are not displayed Possible Explanation === It seems that the taglibs are not loading properly somewhere within WTP. Curiously enough, the following scenario works: 1. Copy the myfaces-api and myfaces-impl jar files from the repository into some other directory on the file system. 2. Explicitly define a JSF library in the Window - Preferences - Web and XML - JavaServerFaces Tools - Libraries page 3. Add the copied JAR files to this new library definition and check the Is JSF Implementation box. 4. Repeat steps 1-7 described above, but specify this new JSF library instead of the Server Supplied JSF Implementation in step 4. Directly linking to the files myfaces-api and myfaces-impl files in the repository when explicitly defining the JSF implementation doesn't work either. The JSF tags only display when the files sit outside the repository. So there must be something in the Geronimo runtime definition that is preventing these files from being referenced. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-348) JSF Tags Not Displayed in Eclipse Web Page Editor
JSF Tags Not Displayed in Eclipse Web Page Editor - Key: GERONIMODEVTOOLS-348 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-348 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.0 Environment: Windows XP SP2, Eclipse Europa Winter Maintenance Release, Geronimo 2.1.1, GEP 2.1.0 Reporter: Cedric Hurst Assignee: Tim McConnell Attachments: jsf palettes visible.jpg Eclipse WTP tooling provides a drag-and-drop palette for various taglibs in its Web Page Editor. When the JSF Project Facet is attached to a Dynamic Web Project, JSF Core and JSF HTML taglibs should be added to the palette (see screenshot). However, this is not the case when using Geronimo/GEP. Steps to Reproduce === 1. Create a new Dynamic Web Project using Geronimo 2.1 as the Targeted Runtime, click Next 2. Add the JavaServer Faces 1.2 Facet to the Project, click Next 3. Accept the default web module settings, click Next 4. In the JSF Capabilities page, select the Server Supplied JSF Implementation option and click Finish 5. Create a new JSP page in the WebContent directory 6. Right click on the new JSP page and open it with the Web Page Editor 7. Expand the Palette in the WYSIWYG pane Expected Behavior === JSF Core and JSF HTML taglibs should be visible in the palette (as per attached screenshot) Actual Behavior === JSF Core and JSF HTML taglibs are not displayed Possible Explanation === It seems that the taglibs are not loading properly somewhere within WTP. Curiously enough, the following scenario works: 1. Copy the myfaces-api and myfaces-impl jar files from the repository into some other directory on the file system. 2. Explicitly define a JSF library in the Window - Preferences - Web and XML - JavaServerFaces Tools - Libraries page 3. Add the copied JAR files to this new library definition and check the Is JSF Implementation box. 4. Repeat steps 1-7 described above, but specify this new JSF library instead of the Server Supplied JSF Implementation in step 4. Directly linking to the files myfaces-api and myfaces-impl files in the repository when explicitly defining the JSF implementation doesn't work either. The JSF tags only display when the files sit outside the repository. So there must be something in the Geronimo runtime definition that is preventing these files from being referenced. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-348) JSF Tags Not Displayed in Eclipse Web Page Editor
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cedric Hurst updated GERONIMODEVTOOLS-348: -- Attachment: jsfPalette.JPG JSF Tags Not Displayed in Eclipse Web Page Editor - Key: GERONIMODEVTOOLS-348 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-348 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.0 Environment: Windows XP SP2, Eclipse Europa Winter Maintenance Release, Geronimo 2.1.1, GEP 2.1.0 Reporter: Cedric Hurst Assignee: Tim McConnell Attachments: jsfPalette.JPG Eclipse WTP tooling provides a drag-and-drop palette for various taglibs in its Web Page Editor. When the JSF Project Facet is attached to a Dynamic Web Project, JSF Core and JSF HTML taglibs should be added to the palette (see screenshot). However, this is not the case when using Geronimo/GEP. Steps to Reproduce === 1. Create a new Dynamic Web Project using Geronimo 2.1 as the Targeted Runtime, click Next 2. Add the JavaServer Faces 1.2 Facet to the Project, click Next 3. Accept the default web module settings, click Next 4. In the JSF Capabilities page, select the Server Supplied JSF Implementation option and click Finish 5. Create a new JSP page in the WebContent directory 6. Right click on the new JSP page and open it with the Web Page Editor 7. Expand the Palette in the WYSIWYG pane Expected Behavior === JSF Core and JSF HTML taglibs should be visible in the palette (as per attached screenshot) Actual Behavior === JSF Core and JSF HTML taglibs are not displayed Possible Explanation === It seems that the taglibs are not loading properly somewhere within WTP. Curiously enough, the following scenario works: 1. Copy the myfaces-api and myfaces-impl jar files from the repository into some other directory on the file system. 2. Explicitly define a JSF library in the Window - Preferences - Web and XML - JavaServerFaces Tools - Libraries page 3. Add the copied JAR files to this new library definition and check the Is JSF Implementation box. 4. Repeat steps 1-7 described above, but specify this new JSF library instead of the Server Supplied JSF Implementation in step 4. Directly linking to the files myfaces-api and myfaces-impl files in the repository when explicitly defining the JSF implementation doesn't work either. The JSF tags only display when the files sit outside the repository. So there must be something in the Geronimo runtime definition that is preventing these files from being referenced. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-348) JSF Tags Not Displayed in Eclipse Web Page Editor
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cedric Hurst updated GERONIMODEVTOOLS-348: -- Attachment: (was: jsf palettes visible.jpg) JSF Tags Not Displayed in Eclipse Web Page Editor - Key: GERONIMODEVTOOLS-348 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-348 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.0 Environment: Windows XP SP2, Eclipse Europa Winter Maintenance Release, Geronimo 2.1.1, GEP 2.1.0 Reporter: Cedric Hurst Assignee: Tim McConnell Attachments: jsfPalette.JPG Eclipse WTP tooling provides a drag-and-drop palette for various taglibs in its Web Page Editor. When the JSF Project Facet is attached to a Dynamic Web Project, JSF Core and JSF HTML taglibs should be added to the palette (see screenshot). However, this is not the case when using Geronimo/GEP. Steps to Reproduce === 1. Create a new Dynamic Web Project using Geronimo 2.1 as the Targeted Runtime, click Next 2. Add the JavaServer Faces 1.2 Facet to the Project, click Next 3. Accept the default web module settings, click Next 4. In the JSF Capabilities page, select the Server Supplied JSF Implementation option and click Finish 5. Create a new JSP page in the WebContent directory 6. Right click on the new JSP page and open it with the Web Page Editor 7. Expand the Palette in the WYSIWYG pane Expected Behavior === JSF Core and JSF HTML taglibs should be visible in the palette (as per attached screenshot) Actual Behavior === JSF Core and JSF HTML taglibs are not displayed Possible Explanation === It seems that the taglibs are not loading properly somewhere within WTP. Curiously enough, the following scenario works: 1. Copy the myfaces-api and myfaces-impl jar files from the repository into some other directory on the file system. 2. Explicitly define a JSF library in the Window - Preferences - Web and XML - JavaServerFaces Tools - Libraries page 3. Add the copied JAR files to this new library definition and check the Is JSF Implementation box. 4. Repeat steps 1-7 described above, but specify this new JSF library instead of the Server Supplied JSF Implementation in step 4. Directly linking to the files myfaces-api and myfaces-impl files in the repository when explicitly defining the JSF implementation doesn't work either. The JSF tags only display when the files sit outside the repository. So there must be something in the Geronimo runtime definition that is preventing these files from being referenced. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-345) Reported server state falls out-of-sync after Windows Hibernate
Reported server state falls out-of-sync after Windows Hibernate --- Key: GERONIMODEVTOOLS-345 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-345 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.0, 2.0.0 Environment: Windows XP SP2, Eclipse Europa for Java EE Developers [Winter Maintenance Release], Geronimo Eclipse Plugin 2.1.0 Reporter: Cedric Hurst Assignee: Tim McConnell Fix For: 2.1.1 After doing a system hibernate with a running geronimo server, Eclipse reports the server state as Stopped when the system resumes. However, the server process is still active and http://localhost:8080 is accessible from a browser. Attempting to do a Start or Clean operation against the server in Eclipse produces a Port 8080 required by Web Connector is already in use. The server may already be running in another process, or a system process may be using the port. To start this server you will need to stop the other process or change the port number(s). At present, you must manually shut down the server from the admin console or command line and start it again from the Eclipse IDE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-346) Adding security roles in the Geronimo Deployment Plan Editor does not work
Adding security roles in the Geronimo Deployment Plan Editor does not work -- Key: GERONIMODEVTOOLS-346 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-346 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.0 Environment: Eclipse Europa Winter (WTP 2.0.2), Windows XP SP2, Geronimo 2.1.1, GEP 2.1.0, Reporter: Cedric Hurst Assignee: Tim McConnell Steps to reproduce === 1. Create a new Enterprise Application Project 2. Open the geronimo-application.xml file in the graphical editor 3. Select the security tab 4. Click the add button in the Security Roles section 5. Provide any value for name and/or description and click Finish Expected behavior === New role will show up in the Security Role list and in the source view of geronimo-application.xml Actual behavior === Role does not show up, nor is it added the the actual xml file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4010) Detect port conflicts before starting application server
Detect port conflicts before starting application server Key: GERONIMO-4010 URL: https://issues.apache.org/jira/browse/GERONIMO-4010 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: core Reporter: Cedric Hurst Like many Geronimo users, I've often experienced port conflicts when starting my app server. These conflicts result in the dreaded NET_BIND error. While most of us have learned to hunt down the error by running netstat and comparing the ports against those defined in the config-substitutions.properties file, it would be much more user-friendly to have the app server do this automatically. Ideally, the server would detect the port conflict on startup, do a netstat in the background, and provide an error message with the port and conflicting system process. At the very least, the NET_BIND errors should be caught and replaced with friendlier error message containing the conflicting port number. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3793) Not Known To This Context JAXBException when attempting to return complex data type from a @WebMethod
[ https://issues.apache.org/jira/browse/GERONIMO-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cedric Hurst updated GERONIMO-3793: --- Priority: Critical (was: Major) Affects Version/s: 2.1 2.0.x Fix Version/s: (was: 2.0.x) Remaining Estimate: 0h Original Estimate: 0h I've tried to deploy the sample EAR on Geronimo 2.1.1 from trunk and the issue appears to still exist. Not Known To This Context JAXBException when attempting to return complex data type from a @WebMethod --- Key: GERONIMO-3793 URL: https://issues.apache.org/jira/browse/GERONIMO-3793 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0.x, 2.1 Environment: Windows XP x86-32, IBM J9 1.5.0 SR5, Geronimo w/ Tomcat+OpenEJB+Axis2 Reporter: Cedric Hurst Assignee: Jarek Gawor Priority: Critical Attachments: ComplexDataTypeWSExampleEAR.ear, geronimo.log Original Estimate: 0h Remaining Estimate: 0h I'm attempting to return a @XmlRootElement annotated object called Customer from a @WebMethod. When calling the service, I get the following error in the server log: javax.xml.bind.JAXBException: [Lcom.gmail.at.cedrichurst.complexDataTypeWSExampleEJB.domain.Customer; is not known to this context at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:223) at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:238) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:85) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:127) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementBeanInfoImpl.java:244) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:251) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:33) at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:461) at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:292) ... 48 more From what I understand, the return type should be added to the JaxB context automatically. Just to make sure I wasn't doing something wrong in my Customer class, I added another method to my bean that returned a java.util.List of Strings. When calling this method, I also got the same sort of error: [javax.xml.bind.JAXBException: java.util.List is not known to this context] javax.xml.ws.WebServiceException: javax.xml.bind.MarshalException - with linked exception: [javax.xml.bind.JAXBException: java.util.List is not known to this context] at org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:174) at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:69) at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:127) at org.apache.axis2.jaxws.message.databinding.impl.JAXBBlockImpl$2.run(JAXBBlockImpl.java:405) at org.apache.axis2.java.security.AccessController.doPrivileged(AccessController.java:76) at org.apache.axis2.jaxws.message.databinding.impl.JAXBBlockImpl.marshalByType(JAXBBlockImpl.java:321) at org.apache.axis2.jaxws.message.databinding.impl.JAXBBlockImpl._outputFromBO(JAXBBlockImpl.java:209) at org.apache.axis2.jaxws.message.impl.BlockImpl.outputTo(BlockImpl.java:327) at org.apache.axis2.jaxws.message.impl.BlockImpl.serialize(BlockImpl.java:252) at org.apache.axiom.om.impl.llom.OMSourcedElementImpl.internalSerializeAndConsume(OMSourcedElementImpl.java:599) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:785) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:814) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:785) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:814) at org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.serializeInternally(SOAPEnvelopeImpl.java:237) at org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.internalSerialize(SOAPEnvelopeImpl.java:225) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:814) at org.apache.axiom.om.impl.llom.OMNodeImpl.serializeAndConsume(OMNodeImpl.java:421) at
[jira] Created: (GERONIMO-3828) Provide jaxws-tools stack traces to the server.log
Provide jaxws-tools stack traces to the server.log -- Key: GERONIMO-3828 URL: https://issues.apache.org/jira/browse/GERONIMO-3828 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: webservices, Wish List Reporter: Cedric Hurst Even with the logging level set to DEBUG, if jaxws-tools throws an Exception, it does not seem to show up in the server log or console output. This seems to be the case even if -Dorg.apache.geronimo.jaxws.wsgen.fork=false is set. Logging the output of wsgen is critical to debug issues with @WebService classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3792) Requesting result from a @WebService fails with NoClassDefFoundError using CXF
Requesting result from a @WebService fails with NoClassDefFoundError using CXF -- Key: GERONIMO-3792 URL: https://issues.apache.org/jira/browse/GERONIMO-3792 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: webservices Affects Versions: 2.0.2, 2.0.x Environment: Windows XP x86-32, IBM J9 1.5.0 SR5, Geronimo w/ Tomcat+OpenEJB+CXF Reporter: Cedric Hurst Attachments: HelloWorldServiceEAR.ear I'm attempting to create a very simple Hello World web service using CXF as the JAX-WS provider. Whenever I make a call to the web service, I get the following error in the server log: 20:01:15,906 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.NoClassDefFoundError: com.sun.org.apache.xerces.internal.dom.DocumentImpl at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:228) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:148) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.access$200(JarFileClassLoader.java:52) at org.apache.geronimo.kernel.classloader.JarFileClassLoader$6.run(JarFileClassLoader.java:308) at java.security.AccessController.doPrivileged(AccessController.java:275) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.findClass(JarFileClassLoader.java:260) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadOptimizedClass(MultiParentClassLoader.java:422) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:278) at java.lang.ClassLoader.loadClass(ClassLoader.java:573) at com.sun.xml.messaging.saaj.soap.SOAPPartImpl.init(SOAPPartImpl.java:88) at com.sun.xml.messaging.saaj.soap.ver1_1.Message1_1Impl.getSOAPPart(Message1_1Impl.java:78) at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:85) at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:63) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:207) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:73) at org.apache.geronimo.cxf.GeronimoDestination.invoke(GeronimoDestination.java:115) at org.apache.geronimo.cxf.CXFWebServiceContainer.processPOST(CXFWebServiceContainer.java:107) at org.apache.geronimo.cxf.CXFWebServiceContainer.invoke(CXFWebServiceContainer.java:83) at org.apache.geronimo.tomcat.TomcatEJBWebServiceContext$EJBWebServiceValve.invoke(TomcatEJBWebServiceContext.java:180) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:801) I will attach both the EAR and geronimo.log. I've tested against both the latest 2.0.3-SNAPSHOT and the TCK-certified build for jee5-2.0-M6-rc1. Also, I don't seem to encounter this problem when using Axis2 as the JAX-WS provider. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3792) Requesting result from a @WebService fails with NoClassDefFoundError using CXF
[ https://issues.apache.org/jira/browse/GERONIMO-3792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cedric Hurst updated GERONIMO-3792: --- Attachment: HelloWorldServiceEAR.ear The EAR I'm deploying. Requesting result from a @WebService fails with NoClassDefFoundError using CXF -- Key: GERONIMO-3792 URL: https://issues.apache.org/jira/browse/GERONIMO-3792 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0.2, 2.0.x Environment: Windows XP x86-32, IBM J9 1.5.0 SR5, Geronimo w/ Tomcat+OpenEJB+CXF Reporter: Cedric Hurst Attachments: HelloWorldServiceEAR.ear I'm attempting to create a very simple Hello World web service using CXF as the JAX-WS provider. Whenever I make a call to the web service, I get the following error in the server log: 20:01:15,906 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.NoClassDefFoundError: com.sun.org.apache.xerces.internal.dom.DocumentImpl at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:228) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:148) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.access$200(JarFileClassLoader.java:52) at org.apache.geronimo.kernel.classloader.JarFileClassLoader$6.run(JarFileClassLoader.java:308) at java.security.AccessController.doPrivileged(AccessController.java:275) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.findClass(JarFileClassLoader.java:260) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadOptimizedClass(MultiParentClassLoader.java:422) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:278) at java.lang.ClassLoader.loadClass(ClassLoader.java:573) at com.sun.xml.messaging.saaj.soap.SOAPPartImpl.init(SOAPPartImpl.java:88) at com.sun.xml.messaging.saaj.soap.ver1_1.Message1_1Impl.getSOAPPart(Message1_1Impl.java:78) at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:85) at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:63) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:207) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:73) at org.apache.geronimo.cxf.GeronimoDestination.invoke(GeronimoDestination.java:115) at org.apache.geronimo.cxf.CXFWebServiceContainer.processPOST(CXFWebServiceContainer.java:107) at org.apache.geronimo.cxf.CXFWebServiceContainer.invoke(CXFWebServiceContainer.java:83) at org.apache.geronimo.tomcat.TomcatEJBWebServiceContext$EJBWebServiceValve.invoke(TomcatEJBWebServiceContext.java:180) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:801) I will attach both the EAR and geronimo.log. I've tested against both the latest 2.0.3-SNAPSHOT and the TCK-certified build for jee5-2.0-M6-rc1. Also, I don't seem to encounter this problem when using Axis2 as the JAX-WS provider. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3792) Requesting result from a @WebService fails with NoClassDefFoundError using CXF
[ https://issues.apache.org/jira/browse/GERONIMO-3792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cedric Hurst updated GERONIMO-3792: --- Attachment: geronimo.log Log file. Requesting result from a @WebService fails with NoClassDefFoundError using CXF -- Key: GERONIMO-3792 URL: https://issues.apache.org/jira/browse/GERONIMO-3792 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0.2, 2.0.x Environment: Windows XP x86-32, IBM J9 1.5.0 SR5, Geronimo w/ Tomcat+OpenEJB+CXF Reporter: Cedric Hurst Attachments: geronimo.log, HelloWorldServiceEAR.ear I'm attempting to create a very simple Hello World web service using CXF as the JAX-WS provider. Whenever I make a call to the web service, I get the following error in the server log: 20:01:15,906 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.NoClassDefFoundError: com.sun.org.apache.xerces.internal.dom.DocumentImpl at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:228) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:148) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.access$200(JarFileClassLoader.java:52) at org.apache.geronimo.kernel.classloader.JarFileClassLoader$6.run(JarFileClassLoader.java:308) at java.security.AccessController.doPrivileged(AccessController.java:275) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.findClass(JarFileClassLoader.java:260) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadOptimizedClass(MultiParentClassLoader.java:422) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:278) at java.lang.ClassLoader.loadClass(ClassLoader.java:573) at com.sun.xml.messaging.saaj.soap.SOAPPartImpl.init(SOAPPartImpl.java:88) at com.sun.xml.messaging.saaj.soap.ver1_1.Message1_1Impl.getSOAPPart(Message1_1Impl.java:78) at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:85) at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:63) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:207) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:73) at org.apache.geronimo.cxf.GeronimoDestination.invoke(GeronimoDestination.java:115) at org.apache.geronimo.cxf.CXFWebServiceContainer.processPOST(CXFWebServiceContainer.java:107) at org.apache.geronimo.cxf.CXFWebServiceContainer.invoke(CXFWebServiceContainer.java:83) at org.apache.geronimo.tomcat.TomcatEJBWebServiceContext$EJBWebServiceValve.invoke(TomcatEJBWebServiceContext.java:180) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:801) I will attach both the EAR and geronimo.log. I've tested against both the latest 2.0.3-SNAPSHOT and the TCK-certified build for jee5-2.0-M6-rc1. Also, I don't seem to encounter this problem when using Axis2 as the JAX-WS provider. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3793) Not Known To This Context JAXBException when attempting to return complex data type from a @WebMethod
[ https://issues.apache.org/jira/browse/GERONIMO-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cedric Hurst updated GERONIMO-3793: --- Attachment: geronimo.log ComplexDataTypeWSExampleEAR.ear EAR file and geronimo.log Not Known To This Context JAXBException when attempting to return complex data type from a @WebMethod --- Key: GERONIMO-3793 URL: https://issues.apache.org/jira/browse/GERONIMO-3793 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Environment: Windows XP x86-32, IBM J9 1.5.0 SR5, Geronimo w/ Tomcat+OpenEJB+Axis2 Reporter: Cedric Hurst Fix For: 2.0.x Attachments: ComplexDataTypeWSExampleEAR.ear, geronimo.log I'm attempting to return a @XmlRootElement annotated object called Customer from a @WebMethod. When calling the service, I get the following error in the server log: javax.xml.bind.JAXBException: [Lcom.gmail.at.cedrichurst.complexDataTypeWSExampleEJB.domain.Customer; is not known to this context at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:223) at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:238) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:85) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:127) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementBeanInfoImpl.java:244) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:251) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:33) at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:461) at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:292) ... 48 more From what I understand, the return type should be added to the JaxB context automatically. Just to make sure I wasn't doing something wrong in my Customer class, I added another method to my bean that returned a java.util.List of Strings. When calling this method, I also got the same sort of error: [javax.xml.bind.JAXBException: java.util.List is not known to this context] javax.xml.ws.WebServiceException: javax.xml.bind.MarshalException - with linked exception: [javax.xml.bind.JAXBException: java.util.List is not known to this context] at org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:174) at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:69) at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:127) at org.apache.axis2.jaxws.message.databinding.impl.JAXBBlockImpl$2.run(JAXBBlockImpl.java:405) at org.apache.axis2.java.security.AccessController.doPrivileged(AccessController.java:76) at org.apache.axis2.jaxws.message.databinding.impl.JAXBBlockImpl.marshalByType(JAXBBlockImpl.java:321) at org.apache.axis2.jaxws.message.databinding.impl.JAXBBlockImpl._outputFromBO(JAXBBlockImpl.java:209) at org.apache.axis2.jaxws.message.impl.BlockImpl.outputTo(BlockImpl.java:327) at org.apache.axis2.jaxws.message.impl.BlockImpl.serialize(BlockImpl.java:252) at org.apache.axiom.om.impl.llom.OMSourcedElementImpl.internalSerializeAndConsume(OMSourcedElementImpl.java:599) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:785) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:814) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:785) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:814) at org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.serializeInternally(SOAPEnvelopeImpl.java:237) at org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.internalSerialize(SOAPEnvelopeImpl.java:225) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:814) at org.apache.axiom.om.impl.llom.OMNodeImpl.serializeAndConsume(OMNodeImpl.java:421) at org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:68) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.sendUsingOutputStream(CommonsHTTPTransportSender.java:294) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:211) at
[jira] Created: (GERONIMO-3793) Not Known To This Context JAXBException when attempting to return complex data type from a @WebMethod
Not Known To This Context JAXBException when attempting to return complex data type from a @WebMethod --- Key: GERONIMO-3793 URL: https://issues.apache.org/jira/browse/GERONIMO-3793 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: webservices Environment: Windows XP x86-32, IBM J9 1.5.0 SR5, Geronimo w/ Tomcat+OpenEJB+Axis2 Reporter: Cedric Hurst Fix For: 2.0.x I'm attempting to return a @XmlRootElement annotated object called Customer from a @WebMethod. When calling the service, I get the following error in the server log: javax.xml.bind.JAXBException: [Lcom.gmail.at.cedrichurst.complexDataTypeWSExampleEJB.domain.Customer; is not known to this context at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:223) at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:238) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:85) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:127) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementBeanInfoImpl.java:244) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:251) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:33) at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:461) at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:292) ... 48 more From what I understand, the return type should be added to the JaxB context automatically. Just to make sure I wasn't doing something wrong in my Customer class, I added another method to my bean that returned a java.util.List of Strings. When calling this method, I also got the same sort of error: [javax.xml.bind.JAXBException: java.util.List is not known to this context] javax.xml.ws.WebServiceException: javax.xml.bind.MarshalException - with linked exception: [javax.xml.bind.JAXBException: java.util.List is not known to this context] at org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:174) at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:69) at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:127) at org.apache.axis2.jaxws.message.databinding.impl.JAXBBlockImpl$2.run(JAXBBlockImpl.java:405) at org.apache.axis2.java.security.AccessController.doPrivileged(AccessController.java:76) at org.apache.axis2.jaxws.message.databinding.impl.JAXBBlockImpl.marshalByType(JAXBBlockImpl.java:321) at org.apache.axis2.jaxws.message.databinding.impl.JAXBBlockImpl._outputFromBO(JAXBBlockImpl.java:209) at org.apache.axis2.jaxws.message.impl.BlockImpl.outputTo(BlockImpl.java:327) at org.apache.axis2.jaxws.message.impl.BlockImpl.serialize(BlockImpl.java:252) at org.apache.axiom.om.impl.llom.OMSourcedElementImpl.internalSerializeAndConsume(OMSourcedElementImpl.java:599) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:785) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:814) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:785) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:814) at org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.serializeInternally(SOAPEnvelopeImpl.java:237) at org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.internalSerialize(SOAPEnvelopeImpl.java:225) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:814) at org.apache.axiom.om.impl.llom.OMNodeImpl.serializeAndConsume(OMNodeImpl.java:421) at org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:68) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.sendUsingOutputStream(CommonsHTTPTransportSender.java:294) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:211) at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:396) at org.apache.geronimo.axis2.ejb.EJBInterceptor.intercept(EJBInterceptor.java:94) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[jira] Commented: (GERONIMO-3793) Not Known To This Context JAXBException when attempting to return complex data type from a @WebMethod
[ https://issues.apache.org/jira/browse/GERONIMO-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563051#action_12563051 ] Cedric Hurst commented on GERONIMO-3793: Running with the Sun JDK allowed me to text CXF. CXF successfully returned ListString, but also throws a javax.xml.bind.JAXBException when attempting to return an array of objects annotated with @XmlRootElement. Not Known To This Context JAXBException when attempting to return complex data type from a @WebMethod --- Key: GERONIMO-3793 URL: https://issues.apache.org/jira/browse/GERONIMO-3793 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Environment: Windows XP x86-32, IBM J9 1.5.0 SR5, Geronimo w/ Tomcat+OpenEJB+Axis2 Reporter: Cedric Hurst Fix For: 2.0.x Attachments: ComplexDataTypeWSExampleEAR.ear, geronimo.log I'm attempting to return a @XmlRootElement annotated object called Customer from a @WebMethod. When calling the service, I get the following error in the server log: javax.xml.bind.JAXBException: [Lcom.gmail.at.cedrichurst.complexDataTypeWSExampleEJB.domain.Customer; is not known to this context at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:223) at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:238) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:85) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:127) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementBeanInfoImpl.java:244) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:251) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:33) at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:461) at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:292) ... 48 more From what I understand, the return type should be added to the JaxB context automatically. Just to make sure I wasn't doing something wrong in my Customer class, I added another method to my bean that returned a java.util.List of Strings. When calling this method, I also got the same sort of error: [javax.xml.bind.JAXBException: java.util.List is not known to this context] javax.xml.ws.WebServiceException: javax.xml.bind.MarshalException - with linked exception: [javax.xml.bind.JAXBException: java.util.List is not known to this context] at org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:174) at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:69) at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:127) at org.apache.axis2.jaxws.message.databinding.impl.JAXBBlockImpl$2.run(JAXBBlockImpl.java:405) at org.apache.axis2.java.security.AccessController.doPrivileged(AccessController.java:76) at org.apache.axis2.jaxws.message.databinding.impl.JAXBBlockImpl.marshalByType(JAXBBlockImpl.java:321) at org.apache.axis2.jaxws.message.databinding.impl.JAXBBlockImpl._outputFromBO(JAXBBlockImpl.java:209) at org.apache.axis2.jaxws.message.impl.BlockImpl.outputTo(BlockImpl.java:327) at org.apache.axis2.jaxws.message.impl.BlockImpl.serialize(BlockImpl.java:252) at org.apache.axiom.om.impl.llom.OMSourcedElementImpl.internalSerializeAndConsume(OMSourcedElementImpl.java:599) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:785) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:814) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:785) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:814) at org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.serializeInternally(SOAPEnvelopeImpl.java:237) at org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.internalSerialize(SOAPEnvelopeImpl.java:225) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:814) at org.apache.axiom.om.impl.llom.OMNodeImpl.serializeAndConsume(OMNodeImpl.java:421) at org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:68) at
[jira] Commented: (GERONIMO-3792) Requesting result from a @WebService fails with NoClassDefFoundError using CXF
[ https://issues.apache.org/jira/browse/GERONIMO-3792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563050#action_12563050 ] Cedric Hurst commented on GERONIMO-3792: Thanks for the suggestion, Daniel. Running on the Sun JDK seemed to fix this problem. I'd imagine that other non-Sun JDKs, such as Apple or Blackdown, would have similar issues. Perhaps Sun's xml parser should be added to the common libs? Requesting result from a @WebService fails with NoClassDefFoundError using CXF -- Key: GERONIMO-3792 URL: https://issues.apache.org/jira/browse/GERONIMO-3792 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0.2, 2.0.x Environment: Windows XP x86-32, IBM J9 1.5.0 SR5, Geronimo w/ Tomcat+OpenEJB+CXF Reporter: Cedric Hurst Attachments: geronimo.log, HelloWorldServiceEAR.ear I'm attempting to create a very simple Hello World web service using CXF as the JAX-WS provider. Whenever I make a call to the web service, I get the following error in the server log: 20:01:15,906 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.NoClassDefFoundError: com.sun.org.apache.xerces.internal.dom.DocumentImpl at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:228) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:148) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.access$200(JarFileClassLoader.java:52) at org.apache.geronimo.kernel.classloader.JarFileClassLoader$6.run(JarFileClassLoader.java:308) at java.security.AccessController.doPrivileged(AccessController.java:275) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.findClass(JarFileClassLoader.java:260) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadOptimizedClass(MultiParentClassLoader.java:422) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:278) at java.lang.ClassLoader.loadClass(ClassLoader.java:573) at com.sun.xml.messaging.saaj.soap.SOAPPartImpl.init(SOAPPartImpl.java:88) at com.sun.xml.messaging.saaj.soap.ver1_1.Message1_1Impl.getSOAPPart(Message1_1Impl.java:78) at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:85) at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:63) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:207) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:73) at org.apache.geronimo.cxf.GeronimoDestination.invoke(GeronimoDestination.java:115) at org.apache.geronimo.cxf.CXFWebServiceContainer.processPOST(CXFWebServiceContainer.java:107) at org.apache.geronimo.cxf.CXFWebServiceContainer.invoke(CXFWebServiceContainer.java:83) at org.apache.geronimo.tomcat.TomcatEJBWebServiceContext$EJBWebServiceValve.invoke(TomcatEJBWebServiceContext.java:180) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:801) I will attach both the EAR and geronimo.log. I've tested against both the latest 2.0.3-SNAPSHOT and the TCK-certified build for jee5-2.0-M6-rc1. Also, I don't seem to encounter this problem when using Axis2 as the JAX-WS provider. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMO-3793) Not Known To This Context JAXBException when attempting to return complex data type from a @WebMethod
[ https://issues.apache.org/jira/browse/GERONIMO-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563051#action_12563051 ] cedric.hurst edited comment on GERONIMO-3793 at 1/27/08 8:05 PM: - Running with the Sun JDK allowed me to test CXF. CXF successfully returned ListString, but also throws a javax.xml.bind.JAXBException when attempting to return an array of objects annotated with @XmlRootElement. was (Author: cedric.hurst): Running with the Sun JDK allowed me to text CXF. CXF successfully returned ListString, but also throws a javax.xml.bind.JAXBException when attempting to return an array of objects annotated with @XmlRootElement. Not Known To This Context JAXBException when attempting to return complex data type from a @WebMethod --- Key: GERONIMO-3793 URL: https://issues.apache.org/jira/browse/GERONIMO-3793 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Environment: Windows XP x86-32, IBM J9 1.5.0 SR5, Geronimo w/ Tomcat+OpenEJB+Axis2 Reporter: Cedric Hurst Fix For: 2.0.x Attachments: ComplexDataTypeWSExampleEAR.ear, geronimo.log I'm attempting to return a @XmlRootElement annotated object called Customer from a @WebMethod. When calling the service, I get the following error in the server log: javax.xml.bind.JAXBException: [Lcom.gmail.at.cedrichurst.complexDataTypeWSExampleEJB.domain.Customer; is not known to this context at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:223) at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:238) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:85) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:127) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementBeanInfoImpl.java:244) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:251) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:33) at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:461) at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:292) ... 48 more From what I understand, the return type should be added to the JaxB context automatically. Just to make sure I wasn't doing something wrong in my Customer class, I added another method to my bean that returned a java.util.List of Strings. When calling this method, I also got the same sort of error: [javax.xml.bind.JAXBException: java.util.List is not known to this context] javax.xml.ws.WebServiceException: javax.xml.bind.MarshalException - with linked exception: [javax.xml.bind.JAXBException: java.util.List is not known to this context] at org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:174) at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:69) at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:127) at org.apache.axis2.jaxws.message.databinding.impl.JAXBBlockImpl$2.run(JAXBBlockImpl.java:405) at org.apache.axis2.java.security.AccessController.doPrivileged(AccessController.java:76) at org.apache.axis2.jaxws.message.databinding.impl.JAXBBlockImpl.marshalByType(JAXBBlockImpl.java:321) at org.apache.axis2.jaxws.message.databinding.impl.JAXBBlockImpl._outputFromBO(JAXBBlockImpl.java:209) at org.apache.axis2.jaxws.message.impl.BlockImpl.outputTo(BlockImpl.java:327) at org.apache.axis2.jaxws.message.impl.BlockImpl.serialize(BlockImpl.java:252) at org.apache.axiom.om.impl.llom.OMSourcedElementImpl.internalSerializeAndConsume(OMSourcedElementImpl.java:599) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:785) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:814) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:785) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:814) at org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.serializeInternally(SOAPEnvelopeImpl.java:237) at org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.internalSerialize(SOAPEnvelopeImpl.java:225) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:814)
