-
1. Re: metadata and AS7
jesper.pedersen Sep 15, 2010 9:39 AM (in response to jfclere)That is the problem -- JBossXB has a lot of transitive dependencies; one of them an explicit dependency on Xerces. Check the Tattletale report for the artifact.
Go with the StAX based model that is being used now...
-
2. Re: metadata and AS7
rmaucher Sep 15, 2010 9:40 AM (in response to jfclere)As some experimental code is now written using stax, I continue to believe that the result will be less robust than the equivalent metadata-for-xb code. 450ms of startup time [the exact amount is not known yet obviously] is not worth a decrease in quality.
Looking at the code, it would be possible to make the new classes more or less equivalent to the current metadata classes, which would allow reusing the code for augment/merge between fragments and annotations that is needed for Servlet 3. So that's a good, and the sticky point is now mostly with the hard core XML parsing.
-
3. Re: metadata and AS7
rmaucher Sep 15, 2010 9:44 AM (in response to jesper.pedersen)Crap is good, as long as it is fast
-
4. Re: metadata and AS7
jfclere Sep 15, 2010 10:38 AM (in response to rmaucher)proto shows it is ~ 100 time faster first time and ~10 the second time... But that is just a proto
-
5. Re: metadata and AS7
jason.greene Sep 15, 2010 11:17 AM (in response to jfclere)I think I have already explained this many times over the reasons not to do this, but I will just add that 450 ms to parse an xml file is certainly unacceptable. That is 1/10 our target boot time, 4 times what our "minimal" equivalent takes to start and several hundred times more than it can take if it was just a simple StAX parser. Note that there will always be at least one web.xml in common configurations of server boot.
-
6. Re: metadata and AS7
jason.greene Sep 15, 2010 11:27 AM (in response to jason.greene)BTW just for curiosity, how does this compare to standard tomcat? IIRC they use a stream oriented approach to parsing XML as well.
-
7. Re: metadata and AS7
rmaucher Sep 15, 2010 11:29 AM (in response to jason.greene)Ok, this wraps up properly the discussion I suppose.
-
8. Re: metadata and AS7
wolfc Sep 16, 2010 7:18 AM (in response to jason.greene)To hide all these details and requirements I've written up an API generator. The original jboss-metadata should have had this kind of interface hierarchy anyway, so that details like parser and merging (possibly other logic) would be hidden from anybody.
To get the generated API classes you would need to build the project.
http://github.com/wolfc/jboss-beach-metadata
The generator itself is one big ugly ball of code and not really relevant. (An as long it does the job thing.)
Note that currently it only does javaee_6.xsd, while each tech should have an independent release cycle.
-
9. Re: metadata and AS7
jfclere Sep 17, 2010 3:53 AM (in response to jason.greene)With a more realistic proto I have:
+++
09:40:24,662 INFO [server] JBoss AS started in 972ms. - Services [Total: 57, On-demand: 11. Started: 53]
+++Parsing ~ 16 ms first time and ~ 5 ms after.... So still faster.
-
10. Re: metadata and AS7
jfclere Sep 22, 2010 8:37 AM (in response to wolfc)I have hacked http://github.com/wolfc/jboss-beach-metadata to generate the metadata for the web see http://github.com/jfclere/jboss-beach-metadata
-
11. Re: metadata and AS7
rmaucher Sep 26, 2010 10:49 AM (in response to jfclere)Jean-Frederic Clere a écrit:
I have hacked http://github.com/wolfc/jboss-beach-metadata to generate the metadata for the web see http://github.com/jfclere/jboss-beach-metadata
Although it is nice to continue experimenting with code generation, the latest results make me think it is too difficult unfortunately
So I am back to a plan of using a hand coded parser with the original jboss-metadata beans (from metadata-common and metadata-war). Without interfaces since I am not buying there is any value add from that. This will allow reusing all the (complex) code from the AS 6 deployers, and lead to Servlet 3 working "quickly" (rather than Servlet 2.4 working quickly). Handling common element groups (description groups and the EE group) is really really annoying with STAX overall (no surprise here), but I guess there's no choice ...
-
12. Re: metadata and AS7
wolfc Sep 27, 2010 9:57 AM (in response to rmaucher)It is complicated and possibly too difficult. I agree with that.
But right now the issue we're seeing is that the spec xsd is incorrect:
<xsd:complexType name="web-appType"> <xsd:choice minOccurs="0" maxOccurs="unbounded"> <xsd:group ref="javaee:web-commonType"/> <xsd:element name="module-name" type="javaee:string" minOccurs="0"/> <xsd:element name="absolute-ordering" type="javaee:absoluteOrderingType"/> </xsd:choice> <xsd:attributeGroup ref="javaee:web-common-attributes"/> </xsd:complexType>
should be something like:
<xsd:complexType name="web-appType"> <xsd:sequence> <xsd:element name="module-name" type="javaee:string" minOccurs="0"/> <xsd:element name="absolute-ordering" type="javaee:absoluteOrderingType" minOccurs="0"/> <xsd:group ref="javaee:web-commonType" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attributeGroup ref="javaee:web-common-attributes"/> </xsd:complexType>
Regardless of this, the main advantage of using interfaces is that components like jboss-injection can use it as input without depending on any actual parser implementation.
Message was edited by: Carlo de Wolf - corrected minOccurs
-
13. Re: metadata and AS7
rmaucher Sep 27, 2010 3:30 PM (in response to wolfc)If you want to decorate JBoss Metadata with interfaces (in a spi package ), I'm fine with that. It is partially decorated already, there are a number of interfaces used.
As is, the xsd is too convoluted for automated generation, and is sometimes wrong We went from one problem to another one last week. Everything should be much simpler with explicit min/maxOccurs on each element if they are not the default, and it would make generation much easier obviously.
-
14. Re: metadata and AS7
rmaucher Sep 29, 2010 7:52 AM (in response to jfclere)Ok, so the web.xml custom parser is "done". It probably has bugs. I'm now looking at doing either .dtd or jboss-web.xml. And I looked in detail at the jboss-web schema, where it looks like my parser will not be able to avoid code duplication. For the generator based impl, it looks worse, as I don't see how to avoid complete duplication, which would make using the metadata API much more painful. Any ideas ?