[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1271) Scout/jUDDI based JAXR Implementation
[ http://jira.jboss.com/jira/browse/JBAS-1271?page=history ] Anil Saldhana closed JBAS-1271: --- Resolution: Done Fix Version: JBossAS-4.0.2 Final Passes the CTS tests for JAXR. It will be released as part of JBoss 4.0.2 Scout/jUDDI based JAXR Implementation - Key: JBAS-1271 URL: http://jira.jboss.com/jira/browse/JBAS-1271 Project: JBoss Application Server Type: Task Components: JAXR service Reporter: Scott M Stark Assignee: Anil Saldhana Fix For: JBossAS-4.0.2 Final, JBossAS-5.0 Final Time Spent: 5 weeks Remaining: 20 weeks This is an integration task for replacement of the existing ebxmlrr JAXR implementation with one based on Scout/jUDDI http://www.jboss.org/wiki/Wiki.jsp?page=JAXR -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1575) Replace Old JAXR implementation (ebxmlrr) with Apache Scout/jUDDI
Replace Old JAXR implementation (ebxmlrr) with Apache Scout/jUDDI - Key: JBAS-1575 URL: http://jira.jboss.com/jira/browse/JBAS-1575 Project: JBoss Application Server Type: Task Components: JAXR service Versions: JBossAS-4.0.2RC1, JBossAS-4.0.2 Final Reporter: Anil Saldhana Assigned to: Anil Saldhana Fix For: JBossAS-4.0.2RC1 The 4.0.x released versions have been carrying a JAXR implementation based on the open source ebxmlrr. Need to replace it with the new JAXR stack based on Apache Scout and Apache jUDDI. The CTS tests for JAXR should pass. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1575) Replace Old JAXR implementation (ebxmlrr) with Apache Scout/jUDDI
[ http://jira.jboss.com/jira/browse/JBAS-1575?page=history ] Anil Saldhana closed JBAS-1575: --- Resolution: Done The CTS tests for JAXR are passing. The old JAXR implementation has been replaced with the new JAXR stack, based on Apache Scout and Apache jUDDI. Replace Old JAXR implementation (ebxmlrr) with Apache Scout/jUDDI - Key: JBAS-1575 URL: http://jira.jboss.com/jira/browse/JBAS-1575 Project: JBoss Application Server Type: Task Components: JAXR service Versions: JBossAS-4.0.2RC1, JBossAS-4.0.2 Final Reporter: Anil Saldhana Assignee: Anil Saldhana Fix For: JBossAS-4.0.2RC1 The 4.0.x released versions have been carrying a JAXR implementation based on the open source ebxmlrr. Need to replace it with the new JAXR stack based on Apache Scout and Apache jUDDI. The CTS tests for JAXR should pass. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1295) Pass the CTS Tests
[ http://jira.jboss.com/jira/browse/JBAS-1295?page=history ] Anil Saldhana closed JBAS-1295: --- Resolution: Done Passes the CTS tests!!! Pass the CTS Tests -- Key: JBAS-1295 URL: http://jira.jboss.com/jira/browse/JBAS-1295 Project: JBoss Application Server Type: Sub-task Components: JAXR service Versions: JBossAS-5.0 Final Reporter: Anil Saldhana Assignee: Anil Saldhana The Jaxr Integration in JBAS using Apache jUDDI and Apache Scout should pass the CTS Tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1344) ebxml messaging
[ http://jira.jboss.com/jira/browse/JBAS-1344?page=history ] Anil Saldhana closed JBAS-1344: --- Resolution: Won't Fix We are basing our JAXR implementation on UDDI. Integration of ebxml is complicated. There are other forms of messaging that can be looked at : Java Message Service, WS-Notification etc. ebxml messaging --- Key: JBAS-1344 URL: http://jira.jboss.com/jira/browse/JBAS-1344 Project: JBoss Application Server Type: Feature Request Components: JAXR service Versions: JBossAS-4.0.1 Final Reporter: SourceForge User SourceForge Submitter: pucky . The new standard for Business to Business is around the corner! ebXML backed by OASIS and the United Nations, is the next best thing to sliced bread. I believe that if jboss could become the first app server to deploy ebXML messaging and ebXML repositories(out of the box) JBOSS would become not only the defacto standard in apps servers but the deployment of JBOSS is the B2B World would sky rocket. I hope someone could look into this from the JBOSS front! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1503) J2EE 1.4 Compliance
[ http://jira.jboss.com/jira/browse/JBAS-1503?page=comments#action_12316099 ] Anil Saldhana commented on JBAS-1503: - are u scoping ur war to use its own libraries? If yes, can you insure that you do not package commons-logging.jar in your war? J2EE 1.4 Compliance --- Key: JBAS-1503 URL: http://jira.jboss.com/jira/browse/JBAS-1503 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final Environment: Windows XP. Jboss 4.0.1 / 4.0.1 SP1 Reporter: Gilli Atkinson Attachments: server.log Unable to properly deploy .war file when configured to be J2EE 1.4 compliant (configuration based on section 2.1 in http://docs.jboss.org/jbossas/whatsnew40/html/). When running as default config, it deploys fine but because of unified classloader, multiple .wars with conflicting class names are a problem. Hence the attempt using compilance config. I've looked everywhere for a solution, or to see if someone else has come up against this, and I'm at a dead end. If I've missed the answer somewhere I apologise for wasting your time. I get 2 main errors (I've attached the log file) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1480) Web Console: Monitors: Errors in the log
[ http://jira.jboss.com/jira/browse/JBAS-1480?page=history ] Anil Saldhana updated JBAS-1480: Attachment: FreeMemoryMonitor-service.xml Web Console: Monitors: Errors in the log Key: JBAS-1480 URL: http://jira.jboss.com/jira/browse/JBAS-1480 Project: JBoss Application Server Type: Bug Versions: JBossAS-4.0.2 Final Environment: JBoss 4.0.1 Reporter: Anil Saldhana Priority: Minor Fix For: JBossAS-4.0.2 Final Attachments: FreeMemoryMonitor-service.xml I see an error in the server log when using web console which is shown below. Step 1: Create a monitor on Free Memory and call it FreeMemoryMonitor. Step 2: You will have a file called FreeMemoryMonitor-service.xml in deploy/management/monitors. [Attached to the case]. See error in the server log as follows: 16:35:10,364 ERROR [MainDeployer] Could not make local copy for file:/Users/anil/jboss-4.0.1/server/default/deploy/management/monitors/FreeMemoryMonitor-service.xml.tmp java.io.FileNotFoundException: /Users/anil/jboss-4.0.1/server/default/deploy/management/monitors/FreeMemoryMonitor-service.xml.tmp at org.jboss.net.protocol.file.FileURLConnection.connect(FileURLConnection.java:71) at org.jboss.net.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:80) at java.net.URL.openStream(URL.java:913) at org.jboss.deployment.MainDeployer.copy(MainDeployer.java:1174) at org.jboss.deployment.MainDeployer.makeLocalCopy(MainDeployer.java:112 No big deal. The error should not be thrown in a production environment with multiple monitors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1480) Web Console: Monitors: Errors in the log
Web Console: Monitors: Errors in the log Key: JBAS-1480 URL: http://jira.jboss.com/jira/browse/JBAS-1480 Project: JBoss Application Server Type: Bug Versions: JBossAS-4.0.2 Final Environment: JBoss 4.0.1 Reporter: Anil Saldhana Priority: Minor Fix For: JBossAS-4.0.2 Final Attachments: FreeMemoryMonitor-service.xml I see an error in the server log when using web console which is shown below. Step 1: Create a monitor on Free Memory and call it FreeMemoryMonitor. Step 2: You will have a file called FreeMemoryMonitor-service.xml in deploy/management/monitors. [Attached to the case]. See error in the server log as follows: 16:35:10,364 ERROR [MainDeployer] Could not make local copy for file:/Users/anil/jboss-4.0.1/server/default/deploy/management/monitors/FreeMemoryMonitor-service.xml.tmp java.io.FileNotFoundException: /Users/anil/jboss-4.0.1/server/default/deploy/management/monitors/FreeMemoryMonitor-service.xml.tmp at org.jboss.net.protocol.file.FileURLConnection.connect(FileURLConnection.java:71) at org.jboss.net.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:80) at java.net.URL.openStream(URL.java:913) at org.jboss.deployment.MainDeployer.copy(MainDeployer.java:1174) at org.jboss.deployment.MainDeployer.makeLocalCopy(MainDeployer.java:112 No big deal. The error should not be thrown in a production environment with multiple monitors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1447) Cluster aware services should not depend on DefaultPartition MBean directly
Cluster aware services should not depend on DefaultPartition MBean directly --- Key: JBAS-1447 URL: http://jira.jboss.com/jira/browse/JBAS-1447 Project: JBoss Application Server Type: Task Components: Clustering Versions: JBossAS-4.0.2 Final, JBossAS-5.0 Final, JBossAS-3.2.8 Final Reporter: Anil Saldhana Assigned to: Anil Saldhana Priority: Minor Lets say the user wants to give a seperate name for his partition from 'DefaultPartition' to something else. He will change the following description in his cluster-service.xml !-- -- !-- Cluster Partition: defines cluster -- !-- -- mbean code=org.jboss.ha.framework.server.ClusterPartition name=jboss:service=DefaultPartition !-- Name of the partition being built -- attribute name=PartitionNameDefaultPartition/attribute But the problem is that many other cluster-aware services depend directly on this mbean with name jboss:service=DefaultPartition. Eg: deploy-hasingleton-service.xml mbean code=org.jboss.ha.singleton.HASingletonController name=jboss.ha:service=HASingletonDeployer dependsjboss:service=DefaultPartition/depends attribute name=PartitionNameDefaultPartition/attribute Suggestion: Make a seperate MBean which stores the cluster partition MBean name and let all other services depend on it. This MBean can be created by the cluster service. My Example: I changed all/deploy/cluster-service.xml to mbean code=org.jboss.ha.framework.server.ClusterPartition name=jboss:service=AnilPartition !-- Name of the partition being built -- attribute name=PartitionNameAnilPartition/attribute When I run jboss, I get: 14:41:12,533 ERROR [URLDeploymentScanner] Incomplete Deployment listing: MBeans waiting for other MBeans: ObjectName: jboss.j2ee:jndiName=clustering/HTTPSession,service=EJB state: NOTYETINSTALLED I Depend On: jboss:service=DefaultPartition jboss:service=invoker,type=jrmp Depends On Me: jboss:service=ClusteredHttpSession ObjectName: jboss:service=ClusteredHttpSession state: CONFIGURED I Depend On: jboss.j2ee:jndiName=clustering/HTTPSession,service=EJB Depends On Me: ObjectName: jboss:service=HASessionState state: CONFIGURED I Depend On: jboss:service=DefaultPartition Depends On Me: ObjectName: jboss:service=HAJNDI state: CONFIGURED I Depend On: jboss:service=DefaultPartition Depends On Me: ObjectName: jboss.cache:service=InvalidationBridge,type=JavaGroups state: CONFIGURED I Depend On: jboss:service=DefaultPartition jboss.cache:service=InvalidationManager Depends On Me: ObjectName: jboss.ha:service=HASingletonDeployer state: CONFIGURED I Depend On: jboss:service=DefaultPartition jboss.system:service=MainDeployer Depends On Me: ObjectName: jboss:partition=DefaultPartition,service=FarmMember state: CONFIGURED I Depend On: jboss:service=DefaultPartition jboss.web:service=WebServer jboss.system:service=MainDeployer Depends On Me: MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM: ObjectName: jboss:service=DefaultPartition state: NOTYETINSTALLED I Depend On: Depends On Me: jboss.j2ee:jndiName=clustering/HTTPSession,service=EJB jboss:service=HASessionState jboss:service=HAJNDI jboss.cache:service=InvalidationBridge,type=JavaGroups jboss.ha:service=HASingletonDeployer jboss:partition=DefaultPartition,service=FarmMember I tested this on 4.0.1 Ofcourse the user can have no probs by changing the attribute PartitionName in cluster-service.xml But the solution I propose is better. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1370) Provide a persistent layer to jUDDI
Provide a persistent layer to jUDDI --- Key: JBAS-1370 URL: http://jira.jboss.com/jira/browse/JBAS-1370 Project: JBoss Application Server Type: Sub-task Components: JAXR service Reporter: Anil Saldhana Assigned to: Anil Saldhana Priority: Minor Provide a persistent layer to jUDDI based on Hibernate. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1371) Use JBossWS as the webservices stack for jUDDI
Use JBossWS as the webservices stack for jUDDI -- Key: JBAS-1371 URL: http://jira.jboss.com/jira/browse/JBAS-1371 Project: JBoss Application Server Type: Sub-task Versions: JBossAS-5.0 Final Reporter: Anil Saldhana Assigned to: Anil Saldhana Fix For: JBossAS-5.0 Final Currently jUDDI uses Axis as the Web Services Stack. Since JBossWS is developing its own stack and will be J2EE 1.4 compliant, it will be necessary to implement jUDDI as a Java Service EndPoint. A task has been created in jUDDI JIRA on Apache (http://issues.apache.org/jira/browse/JUDDI-47) If jUDDI is implemented as J2EE compliant web services, it will be pluggable on any compliant stack. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1295) Pass the CTS Tests
Pass the CTS Tests -- Key: JBAS-1295 URL: http://jira.jboss.com/jira/browse/JBAS-1295 Project: JBoss Application Server Type: Sub-task Components: JAXR service Versions: JBossAS-5.0 Final Reporter: Anil Saldhana Assigned to: Anil Saldhana The Jaxr Integration in JBAS using Apache jUDDI and Apache Scout should pass the CTS Tests. Total tests: 1384. Filtered: 12 Sub Total: 1372. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1295) Pass the CTS Tests
[ http://jira.jboss.com/jira/browse/JBAS-1295?page=history ] Anil Saldhana updated JBAS-1295: Description: The Jaxr Integration in JBAS using Apache jUDDI and Apache Scout should pass the CTS Tests. (was: The Jaxr Integration in JBAS using Apache jUDDI and Apache Scout should pass the CTS Tests. Total tests: 1384. Filtered: 12 Sub Total: 1372.) Pass the CTS Tests -- Key: JBAS-1295 URL: http://jira.jboss.com/jira/browse/JBAS-1295 Project: JBoss Application Server Type: Sub-task Components: JAXR service Versions: JBossAS-5.0 Final Reporter: Anil Saldhana Assignee: Anil Saldhana The Jaxr Integration in JBAS using Apache jUDDI and Apache Scout should pass the CTS Tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1283) Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp
[ http://jira.jboss.com/jira/browse/JBAS-1283?page=comments#action_12314647 ] Anil Saldhana commented on JBAS-1283: - http://www.jboss.org/wiki/Wiki.jsp?page=JBossClassLoadingUseCases This describes classloading. Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp - Key: JBAS-1283 URL: http://jira.jboss.com/jira/browse/JBAS-1283 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-3.2.6 Final Environment: Stock JBoss 3.2.6 running on Linux (kernel 2.4.26), Sun JDK and JRE version 1.4.2_04 Reporter: Jeremy Brown Assignee: Anil Saldhana Priority: Minor Attachments: test.war See my initial forum post at http://www.jboss.org/index.html?module=bbop=viewtopicp=3861452#3861452;. The dom4j libs provided by JBoss do not work correctly with my web application, so I attempted to configure my webapp's jboss-web.xml--as per the wiki page at http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration--so that my webapp would essentially be in a different classloader namspace and would be able to override the server dom4j implementation with its own. Now, Tomcat bails out during JSP compilation with a dom4j-related ClassCastException, leading me to believe there might some problem with the sort of setup I'm trying to attempt...for example, Tomcat's JSP compiler might be trying to link with the dom4j in my application's namespace while its classes have been loaded next to (and probably are already using) dom4j in the server namespace. I'll attach a .war file exhibiting this behavior to this bug report. Here's the specific exception for this .war file: java.lang.ClassCastException at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:93) at org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:91) at org.apache.jasper.compiler.JspConfig.processWebDotXml(JspConfig.java:70) at org.apache.jasper.compiler.JspConfig.init(JspConfig.java:188) at org.apache.jasper.compiler.JspConfig.findJspProperty(JspConfig.java:240) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:160) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:470) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:451) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:511) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:295) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:158) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1283) Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp
[ http://jira.jboss.com/jira/browse/JBAS-1283?page=comments#action_12314656 ] Anil Saldhana commented on JBAS-1283: - Make java2ParentDelegation=trueand give it a shot. Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp - Key: JBAS-1283 URL: http://jira.jboss.com/jira/browse/JBAS-1283 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-3.2.6 Final Environment: Stock JBoss 3.2.6 running on Linux (kernel 2.4.26), Sun JDK and JRE version 1.4.2_04 Reporter: Jeremy Brown Assignee: Anil Saldhana Priority: Minor Attachments: test.war See my initial forum post at http://www.jboss.org/index.html?module=bbop=viewtopicp=3861452#3861452;. The dom4j libs provided by JBoss do not work correctly with my web application, so I attempted to configure my webapp's jboss-web.xml--as per the wiki page at http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration--so that my webapp would essentially be in a different classloader namspace and would be able to override the server dom4j implementation with its own. Now, Tomcat bails out during JSP compilation with a dom4j-related ClassCastException, leading me to believe there might some problem with the sort of setup I'm trying to attempt...for example, Tomcat's JSP compiler might be trying to link with the dom4j in my application's namespace while its classes have been loaded next to (and probably are already using) dom4j in the server namespace. I'll attach a .war file exhibiting this behavior to this bug report. Here's the specific exception for this .war file: java.lang.ClassCastException at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:93) at org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:91) at org.apache.jasper.compiler.JspConfig.processWebDotXml(JspConfig.java:70) at org.apache.jasper.compiler.JspConfig.init(JspConfig.java:188) at org.apache.jasper.compiler.JspConfig.findJspProperty(JspConfig.java:240) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:160) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:470) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:451) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:511) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:295) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:158) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1284) SOAP SAAJ JBOSS implementation attachments bug
[ http://jira.jboss.com/jira/browse/JBAS-1284?page=comments#action_12314624 ] Anil Saldhana commented on JBAS-1284: - WS-I Basic Profile does not endorse Soap with Attachments. Since the goal of v4.0 in JBoss was J2EE 1.4 compliance, we had to comply with WS-I BP. Hence there is currrently no support for SwA in JBoss v4.0.1. But given that, we are working on providing SwA in the near future. Please check http://jira.jboss.com/jira/browse/JBWS-46 SOAP SAAJ JBOSS implementation attachments bug -- Key: JBAS-1284 URL: http://jira.jboss.com/jira/browse/JBAS-1284 Project: JBoss Application Server Type: Bug Components: Web Services service Versions: JBossAS-4.0.1 Final Environment: Windows-XP SP2 Reporter: Frank Balba Assignee: Scott M Stark Using JBOSS-SAAJ implementation, no attachments could get through within a SOAP message. Creating attachments and adding them to a SOAP message will result a fine SOAP message on the client side however once it arrives to a dedicated servlet the received attachmentpart returns 'null' for attachmentPart.getContentType(). Using another SAAJ package (not the one included with JBOSS 4.0.1) eliminates this problem. Frank -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1283) Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp
[ http://jira.jboss.com/jira/browse/JBAS-1283?page=history ] Anil Saldhana updated JBAS-1283: Priority: Minor (was: Major) This is not a major issue. Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp - Key: JBAS-1283 URL: http://jira.jboss.com/jira/browse/JBAS-1283 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-3.2.6 Final Environment: Stock JBoss 3.2.6 running on Linux (kernel 2.4.26), Sun JDK and JRE version 1.4.2_04 Reporter: Jeremy Brown Assignee: Scott M Stark Priority: Minor Attachments: test.war See my initial forum post at http://www.jboss.org/index.html?module=bbop=viewtopicp=3861452#3861452;. The dom4j libs provided by JBoss do not work correctly with my web application, so I attempted to configure my webapp's jboss-web.xml--as per the wiki page at http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration--so that my webapp would essentially be in a different classloader namspace and would be able to override the server dom4j implementation with its own. Now, Tomcat bails out during JSP compilation with a dom4j-related ClassCastException, leading me to believe there might some problem with the sort of setup I'm trying to attempt...for example, Tomcat's JSP compiler might be trying to link with the dom4j in my application's namespace while its classes have been loaded next to (and probably are already using) dom4j in the server namespace. I'll attach a .war file exhibiting this behavior to this bug report. Here's the specific exception for this .war file: java.lang.ClassCastException at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:93) at org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:91) at org.apache.jasper.compiler.JspConfig.processWebDotXml(JspConfig.java:70) at org.apache.jasper.compiler.JspConfig.init(JspConfig.java:188) at org.apache.jasper.compiler.JspConfig.findJspProperty(JspConfig.java:240) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:160) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:470) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:451) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:511) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:295) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:158) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at
[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-1283) Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp
[ http://jira.jboss.com/jira/browse/JBAS-1283?page=history ] Anil Saldhana reassigned JBAS-1283: --- Assign To: Anil Saldhana (was: Scott M Stark) Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp - Key: JBAS-1283 URL: http://jira.jboss.com/jira/browse/JBAS-1283 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-3.2.6 Final Environment: Stock JBoss 3.2.6 running on Linux (kernel 2.4.26), Sun JDK and JRE version 1.4.2_04 Reporter: Jeremy Brown Assignee: Anil Saldhana Priority: Minor Attachments: test.war See my initial forum post at http://www.jboss.org/index.html?module=bbop=viewtopicp=3861452#3861452;. The dom4j libs provided by JBoss do not work correctly with my web application, so I attempted to configure my webapp's jboss-web.xml--as per the wiki page at http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration--so that my webapp would essentially be in a different classloader namspace and would be able to override the server dom4j implementation with its own. Now, Tomcat bails out during JSP compilation with a dom4j-related ClassCastException, leading me to believe there might some problem with the sort of setup I'm trying to attempt...for example, Tomcat's JSP compiler might be trying to link with the dom4j in my application's namespace while its classes have been loaded next to (and probably are already using) dom4j in the server namespace. I'll attach a .war file exhibiting this behavior to this bug report. Here's the specific exception for this .war file: java.lang.ClassCastException at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:93) at org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:91) at org.apache.jasper.compiler.JspConfig.processWebDotXml(JspConfig.java:70) at org.apache.jasper.compiler.JspConfig.init(JspConfig.java:188) at org.apache.jasper.compiler.JspConfig.findJspProperty(JspConfig.java:240) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:160) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:470) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:451) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:511) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:295) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:158) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1283) Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp
[ http://jira.jboss.com/jira/browse/JBAS-1283?page=comments#action_12314640 ] Anil Saldhana commented on JBAS-1283: - If I make the java2ClassLoadingCompliance to true, the webapp deploys properly and I can access the index.jsp with no errors. = ?xml version='1.0' encoding='UTF-8' ? !DOCTYPE jboss-web PUBLIC -//JBoss//DTD Web Application 2.3//EN http://www.jboss.org/j2ee/dtd/jboss-web_3_0.dtd; jboss-web class-loading java2ClassLoadingCompliance=true loader-repositorydot.com:loader=app1 loader-repository-configjava2ParentDelegation=true/loader-repository-config /loader-repository /class-loading /jboss-web I notice that your lib directory has dom4j-full.jar (which contains jaxen) and a seperate jaxen-full.jar. Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp - Key: JBAS-1283 URL: http://jira.jboss.com/jira/browse/JBAS-1283 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-3.2.6 Final Environment: Stock JBoss 3.2.6 running on Linux (kernel 2.4.26), Sun JDK and JRE version 1.4.2_04 Reporter: Jeremy Brown Assignee: Anil Saldhana Priority: Minor Attachments: test.war See my initial forum post at http://www.jboss.org/index.html?module=bbop=viewtopicp=3861452#3861452;. The dom4j libs provided by JBoss do not work correctly with my web application, so I attempted to configure my webapp's jboss-web.xml--as per the wiki page at http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration--so that my webapp would essentially be in a different classloader namspace and would be able to override the server dom4j implementation with its own. Now, Tomcat bails out during JSP compilation with a dom4j-related ClassCastException, leading me to believe there might some problem with the sort of setup I'm trying to attempt...for example, Tomcat's JSP compiler might be trying to link with the dom4j in my application's namespace while its classes have been loaded next to (and probably are already using) dom4j in the server namespace. I'll attach a .war file exhibiting this behavior to this bug report. Here's the specific exception for this .war file: java.lang.ClassCastException at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:93) at org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:91) at org.apache.jasper.compiler.JspConfig.processWebDotXml(JspConfig.java:70) at org.apache.jasper.compiler.JspConfig.init(JspConfig.java:188) at org.apache.jasper.compiler.JspConfig.findJspProperty(JspConfig.java:240) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:160) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:470) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:451) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:511) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:295) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66) at
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1271) Scout/jUDDI based JAXR Implementation
[ http://jira.jboss.com/jira/browse/JBAS-1271?page=history ] Anil Saldhana updated JBAS-1271: Description: This is an integration task for replacement of the existing ebxmlrr JAXR implementation with one based on Scout/jUDDI http://www.jboss.org/wiki/Wiki.jsp?page=JAXR was:This is an integration task for replacement of the existing ebxmlrr JAXR implementation with one based on Scout/jUDDI Scout/jUDDI based JAXR Implementation - Key: JBAS-1271 URL: http://jira.jboss.com/jira/browse/JBAS-1271 Project: JBoss Application Server Type: Task Reporter: Scott M Stark Assignee: Anil Saldhana Fix For: JBossAS-5.0 Final This is an integration task for replacement of the existing ebxmlrr JAXR implementation with one based on Scout/jUDDI http://www.jboss.org/wiki/Wiki.jsp?page=JAXR -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1117) invalid schemaLocation generated for imported schema
[ http://jira.jboss.com/jira/browse/JBAS-1117?page=history ] Anil Saldhana closed JBAS-1117: --- Resolution: Done Fix Version: JBossAS-4.0.1 Final invalid schemaLocation generated for imported schema Key: JBAS-1117 URL: http://jira.jboss.com/jira/browse/JBAS-1117 Project: JBoss Application Server Type: Bug Versions: JBossAS-4.0.0 Final Reporter: SourceForge User Assignee: Anil Saldhana Fix For: JBossAS-4.0.1 Final SourceForge Submitter: mazzgolf . Somewhat related to 1041495 - see that issue for the hello.war attachment - the same war used to replicate the problem in that issue is the same war that can be used to replicate the problem for this issue. Same platforms as well were used to replicate. JBoss performs the cool feature of auto-modifying a web service's WSDLs (including its imported/included WSDLs and schemas). However, in one instance that modification produces a URL that does not point to the resource - I get a HTTP 500 instead. Deploy the hello.war (rather than duplicate attachments, see issue 1041495 for the attachment there). This assumes issue 1041495 has been corrected or worked around (I worked around it by fixing issue 1041495 inside a JPDA session and continuing). Once the web service is deployed, look at the hello service's WSDL. You will see an import of another WSDL (this is correct): wsdl:import location=/hello/hello/? wsdlresource=../spec/wsrf/WS-ResourceProperties- 1_1.wsdl ... If you point your browser to that location, you can see that WS-ResourceProperties-1_1.wsdl file. Looking at that WSDL, you will notice that it, itself, imports another file - this time a .xsd schema inside its wsdl:types/wsd:schema element: wsdl:import namespace=... schemaLocation=/hello/hello? wsdlresource=../../wsa/WS-Addressing-2003_03.xsd That schemaLocation is incorrect - if you point your browser to that URL, you will get a HTTP 500 and the JBoss logs tells me cannot obtain wsdl resource from: WEB-INF/wsdl/wsa/WS-Addressing-2003_03.xsd. Notice the .. appears twice - I _think_ that is incorrect. I think it only needs to go up to the immediate parent directory only - it should not have gone up twice to its grandparent directory. This wsa directory is located as a peer directory to wsmf (under the spec parent - just like the WS-ResouceProperties- 1_1.wsdl is under wsrf which is under spec). I think it should be: schemaLocation=/hello/hello?wsdlresource=../wsa/WS- Addressing-2003_03.xsd However, when I put that URL in my browser, I still did not get the .xsd served up - I again got a 500. Funny thing is that the JBoss error log says it was still looking for WEB-INF/wsdl/wsa/WS-Addressing-2003_03.xsd - the same relative path it told me when I used the ../.. form. Using just ../ to go up one level instead of two didn't change the relative path JBoss was looking for. I did not have a chance to debug this to find out how to fix this - I just noticed that I was unable to get to that .xsd file from my browser (so, therefore, I assume any client of this web service will not be able to successfully parse its WSDL due to the inability to have the server serve up this schema). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1115) bad path to included xsd gets built in WSDLFilePublisher
[ http://jira.jboss.com/jira/browse/JBAS-1115?page=history ] Anil Saldhana closed JBAS-1115: --- Resolution: Done Fix Version: JBossAS-4.0.1 Final bad path to included xsd gets built in WSDLFilePublisher Key: JBAS-1115 URL: http://jira.jboss.com/jira/browse/JBAS-1115 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-4.0.0 Final Reporter: SourceForge User Assignee: Anil Saldhana Fix For: JBossAS-4.0.1 Final SourceForge Submitter: mazzgolf . Problem when deploying a web service whose WSDL imports/includes other WSDL/schemas. See attached for a simple hello.war that illustrates this problem. To replicate, simply place the war file in the JBoss deploy directory and start. I don't think this has anything to do with platforms, but just in case - this is on JBoss 4.0, JDK 1.4.2, Windows XP SP1. Description: My web service WSDL imports another WSDL which in turn includes a schema (these are WSRF specification files). It looks like WSDLFilePublisher is not building the path correctly to that included schema. It's missing a / in one spot and has a double slash // in another spot. While debugging in WSDLFilePublisher, line 206 results in this as value for resourcePath: WEB-INF/wsdl//services/../spec/wsrfWS- ResourceProperties-1_1.xsd Note that there is a / missing between the last directory wsrf and the schema filename WS- ResourceProperties-1_1.xsd. There is also a double slash // in there as well. The double-slash is probably OK and most file systems will parse it fine, however, obviously the missing slash is going to cause problems (which it does on my box). The value of this.expLocation was WEB-INF/wsdl/ and the value of schemaLocation was WS- ResourceProperties-1_1.xsd. baseURI had a value of file:/C:/mazz/jboss/jboss- 4.0.0/server/default/data/wsdl/jboss- wsdm.war/services/../spec/wsrf/WS-ResourceProperties- 1_1.wsdl. this.di.shortName is jboss-wsdm.war. index is 57. All of those values are correct. The WSDL includes the .xsd like this: wsd:typesxsd:schema xsd:include schemaLocation=WS-ResourceProperties- 1_1.xsd/ ... The resulting exception is (which is actually thrown in line 210): 16:13:24,774 ERROR [ServiceDeployer] Cannot startup webservice for: jboss-wsdm.war org.jboss.deployment.DeploymentException: Cannot publish wsdl to: C:\mazz\jboss\jboss-4.0.0 \server\default\data\wsdl\jboss- wsdm.war\services\sensor.wsdl; - nested throwable: (java.lang.IllegalArgumentException: Cannot find schema import in deployment: WEB-INF/wsdl//services/../spec/wsrfWS- ResourceProperties-1_1.xsd) at org.jboss.webservice.WSDLFilePublisher.publishWsdlFile (WSDLFilePublisher.java:106) If, in my debugger, I fix the resourcePath evaluated on line 205 such that the path has the proper slashes, my web service deploys fine. In this example, its as if I made this fix on line 205 of WSDLFilePublisher.java from: resourcePath = resourcePath.substring(0, resourcePath.lastIndexOf(/)); to: resourcePath = resourcePath.substring(1, resourcePath.lastIndexOf(/) + 1); Obviously, it would be best if no assumptions were made about the location of / (that is to say, don't assume resourcePath has a leading / - I do above and hence the 1 in the first argument to substring). Probably would be better if we do something like this for the first parameter to that substring: resourcePath.charAt(0) == / ? 1 : 0 Same holds true with that second argument. We should not do the +1 if we know the schemaLocation is an absolute path. Otherwise, we'd introduce another double slash. So, perhaps, line 205 should be the following: resourcePath = resourcePath.substring (resourcePath.chatAt(0) == / ? 1 : 0, resourcePath.lastIndexOf(/) + (schemaLocation.charAt (0) == / ? 0 : 1)); I'll leave it up to the commiter to decide the best course of action. John Mazz -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
