1 2 Previous Next 15 Replies Latest reply on Jul 31, 2009 5:25 PM by Arsen Torbarina

    Heads up on possible deployment error (HTML.Version)

    Dan Allen Master

      I discovered what appears to be a widespread deployment error problem starting last night if you are using a Seam page flow in your application (at least on JBoss AS 4.2.x from my tests). The error will look something like:


      Caused by: org.jbpm.jpdl.JpdlException: [[FATAL] line 31: The declaration for the entity "HTML.Version" must end with '>'., [ERROR] couldn't parse process definition]
              at org.jbpm.jpdl.xml.JpdlXmlReader.readProcessDefinition(JpdlXmlReader.java:172)
              at org.jboss.seam.bpm.Jbpm.parseInputSource(Jbpm.java:317)
              ...



      Believe it or not, the problem is that the w3c.org appears to have uploaded a bad loose.dtd file. Jbpm (via the SAX parser) reaches out the internet, apparently, and attempts to parse this file. This results in a failed deployment when Seam attempts to load the page flow descriptor.


      The only way I could get around the problem in the short term is to disable my connection to the internet during deployment. Certainly not a solution, but proof that SAX is connecting to the internet and the problem is with the remote file.


      If anyone knows how to make SAX stop reaching out to the internet, it would help people work around this problem, possibly even a smart change in general.

        • 1. Re: Heads up on possible deployment error (HTML.Version)
          Dan Allen Master

          I figured out a real solution (since how can you realistically disable the internet for a web app?).


          The problem is that the SAXParserFactory used by the JpdlParser has validation enabled. Here's how to perform an emergency fix to disable this feature. Copy the file src/jpdl/org/jbpm/jpdl/xml/JpdlParser.java from the jbpm-jpdl 3.2.2 distribution into your project under the same package name (org.jbpm.jpdl.xml). Then, change the line number 148 to the following:


          saxParserFactory.setValidating(false);



          You are effectively putting a replacement file at the top of the classpath. Of course, you need to have the proper libraries on your build path to compile this file, but since you should already have the Jbpm library, it should be no trouble. When you redeploy your application, you should no longer see this error.

          • 2. Re: Heads up on possible deployment error (HTML.Version)
            Joseph Nusairat Newbie


            Thanks Dan ... we are having the same issue unfortunetly in a different set of files. Its our Spring-Seam xml definers.

            • 3. Re: Heads up on possible deployment error (HTML.Version)
              Dan Allen Master

              Yeah, it appears that anyone using SAX with validation is affected. Makes you wonder how many people in the world are currently experiencing deployment problems. And we thought depending on a Maven 2 repository was bad. Who knew we all depend so heavily on w3c.org.


              To solve it, you know what line you are looking for now, regardless of library.

              • 4. Re: Heads up on possible deployment error (HTML.Version)
                Joseph Nusairat Newbie

                yeah with the spring stuff i am trying to solve it without changing the source code itself.


                But yeah .... this has got to be effecting a lot of people/

                • 5. Re: Heads up on possible deployment error (HTML.Version)
                  Christian Bauer Master

                  The underlying problem is that developers of libraries and frameworks are often careless when they parse XML with validation. Any schema or DTD reference needs to be resolved for this. So, because most DTD and schema references are expressed using HTTP URLs, the developer never notices that the XML parser downloads the DTD or schema on every run.


                  You are supposed to resolve the DTD or schema of your XML file within your library. For DTDs this is a custom EntityResolver. For schemas it's more complicated but perfectly doable. So the blame is on the:


                  - the XML parser for being stupid enough to try to resolve a URN that is a URL just because it looks like it can be resolved that way, instead of throwing a missing resource exception


                  - the IT guys for actually putting these resources online under these URLs, so everybody just keeps on downloading them on every run


                  - the framework/library developers for not noticing and fixing any of these issues


                  To my knowledge, Seam and Hibernate configure the XML parser correctly with a custom resolver that searches for the DTD/schema inside the classpath. The only problem is when people forget to update the URNs in their XML files after an upgrade. We added a warning log message to Hibernate at some point, Seam AFAIK doesn't do that.


                  The problem is JBoss Embedded, so SeamTest runs usually fail if jboss.org is down (the ds-xml files often have DTD references in them). This has been reported but not fixed.


                  I thought that jBPM would be OK, although it doesn't look like that's the case. Please report to the project.


                  • 6. Re: Heads up on possible deployment error (HTML.Version)
                    Dan Allen Master

                    Excellent points.


                    I think Seam works fine because it simply doesn't validate the XML at runtime. I remember Norman making this point.


                    the XML parser for being stupid enough to try to resolve a URN that is a URL just because it looks like it can be resolved that way, instead of throwing a missing resource exception


                    I wholeheartedly agree. This an area where I've been critical of applications in the past, in particular Eclipse. Really, no library should ever use the internet unless you are doing a web service call (where using the internet is the desired behavior). You simply cannot rely on these websites being up or serve a valid document (which is the case today).

                    • 7. Re: Heads up on possible deployment error (HTML.Version)
                      Dan Allen Master

                      To my last point, if you are behind a firewall/proxy that gives you some splash page rather than the document you requested, you can really screw up your Maven 2 repository. Maven 2 doesn't validate that the POM it downloaded is really a POM file. Instead, it just shoves it in the repository. Happened to me on my last trip.

                      • 8. Re: Heads up on possible deployment error (HTML.Version)
                        Pete Muir Master

                        The real problem is not the w3c.org file, it's that:



                        • jBPM doesn't know to use a local copy of the xsd for validation if it's on the classpath (Seam does, as Chrstian describes)

                        • JBoss.org is suffering a major IT outage atm which means this file wasn't available online for some time (it is available agai now).



                        So, please file a jBPM issue and ask for an API for us to tell jBPM where that file is located locally.

                        • 10. Re: Heads up on possible deployment error (HTML.Version)
                          Pete Muir Master

                          jBPM issue


                          I think Seam works fine because it simply doesn't validate the XML at runtime. I remember Norman making this point.


                          No, Seam works properly because we coded it properly - so that it uses the local resource if present.

                          • 11. Re: Heads up on possible deployment error (HTML.Version)
                            Dan Allen Master

                            Sorry, I made an incorrect assumption. As Pete has pointed out, Seam provides a DTDEntityResolver that looks in the classpath for the descriptor:


                             if (systemId.startsWith("http://jboss.com/products/seam/")) {
                                log.debug("recognized Seam namespace; attempting to resolve on classpath under org/jboss/seam/");
                                String path = "org/jboss/seam/" + systemId.substring(SEAM_NAMESPACE.length());
                                            
                                InputStream dtdStream = resolveInSeamNamespace(path);
                                ...
                            }



                            That's how it should be done. So, if you are consuming XML, take a look at Seam for an example of how to do it properly ;)

                            • 12. Re: Heads up on possible deployment error (HTML.Version)
                              Kem Elbrader Newbie

                              I ran into this problem and found that removing the xsi:schemaLocation from my pageflow file seemed avoid the problem as well. A temp fix but an okay one.



                              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                              xsi:schemaLocation="http://jboss.com/products/seam/pageflow http://jboss.com/products/seam/pageflow-2.1.xsd"




                              • 13. Re: Heads up on possible deployment error (HTML.Version)
                                Harold Booth Newbie

                                We encountered a similar issue described in this thread with the seam-spring integration.  By default Spring was looking in the xsi:schemaLocation attribute to locate the xsd file for the Spring-Seam xsd file, and unfortunately the JBoss site appears to be down at the moment.  To work around this (and to remove the external dependency) create a file called spring.schemas and place in the META-INF folder adding the following line to the file:


                                http\://www.jboss.com/products/seam/spring-seam-2.1.xsd=org/jboss/seam/ioc/spring/spring-seam-2.1.xsd



                                For more information see Appendix B of the Spring Reference Documentation where they talk about Registering the handler and the schema

                                • 14. Re: Heads up on possible deployment error (HTML.Version)
                                  Francisco Jose Peredo Noguez Master

                                  I am getting an error in eclipse XML validation (but the project seems to be working fine):


                                  Description     Resource     Path     Location     Type
                                  Referenced file contains errors (jar:file:C:/devstudio/eclipse/plugins/org.eclipse.wst.standard.schemas_1.0.102.v200807220733.jar!/dtds/loose.dtd).  For more information, right click on the message and select "Show Details..."     components.xml     webappsbmi/WebContent/WEB-INF     line 1     XML Problem
                                  



                                  If I right click it and select details I get a dialog with:


                                  
                                  HTML.Version" must end with '>' at line 31
                                  
                                  




                                  this happens when I add:


                                  http://jboss.com/products/seam/excel http://jboss.com/products/seam/excel-2.1.xsd
                                  



                                  to the xsi:schemaLocation in my components.xml file.

                                  1 2 Previous Next