Metadata processing

[rmaucher]

For metadata processing, at least the web related portions (web.xml, jboss-web.xml, *.tld, web-fragment.xml), I plan to continue using XB and JBoss Metadata. There are a few classes which imply otherwise (ex: org.jboss.as.deployment.descriptor.JBossWebXmlDescriptor), and I removed from my tree. What was their purpose ?

[dmlloyd]

Remy Maucherat wrote:

For metadata processing, at least the web related portions (web.xml, jboss-web.xml, *.tld, web-fragment.xml), I plan to continue using XB and JBoss Metadata. There are a few classes which imply otherwise (ex: org.jboss.as.deployment.descriptor.JBossWebXmlDescriptor), and I removed from my tree. What was their purpose ?

I'd recommend against this.  JBoss Metadata will pull in gobs of useless and unnecessary dependencies, and JBossXB also pulls in several dependencies and is incompatible with a modular classloading structure (i.e. the static binder system, which relies on a flat classpath).  The JBossWebXmlDescriptor is intended as an object model of the descriptor that is parsed using StAX.

[rmaucher]

Thanks for the recommendation. if I am to participate in this project, I will use JBossXB and JBoss Metadata for web metadata processing, JBoss Scanning for annotation scanning, etc. Processing of this stuff is complex, and your low level XML code is not appropriate for this.

Let me know quicky if this will be blocked, as I would like to know if I will actually participate in this project, or if I have nothing to contribute.

[dmlloyd]

Remy Maucherat wrote:

Thanks for the recommendation. if I am to participate in this project, I will use JBossXB and JBoss Metadata for web metadata processing, JBoss Scanning for annotation scanning, etc. Processing of this stuff is complex, and your low level XML code is not appropriate for this.

Let me know quicky if this will be blocked, as I would like to know if I will actually participate in this project, or if I have nothing to contribute.

You're free to do this if you want.  But then it is your responsibility to fix all the aforementioned problems in JBossXB and JBoss Metadata, and the other subprojects you bring in, which will include stripping down dependencies and modularizing them before it will be accepted; sounds like a lot more work to me.

In any case, so far this "low-level" XML code has proven equal to every task.  I don't see why parsing web.xml and jboss-web.xml would suddenly be too complex for it.  Anyway parsing the XML is only a small portion of this task.  The deployment processing is by far the more complex part of this, and this is completely different from AS 6 in order to accommodate the new domain-based architecture. Also AS 7 will include annotation scanning as part of the class loading architecture in order to accommodate indexing deployments as a separate deployment step, so using another layer will be redundant.

[rmaucher]

As you wish, good luck with your project then.

[ropalka]

Remy,

   AS 7 is about doing things properly. JBossXB depends directly on apache JAXP implementation classes (not JAXP API only)

and this is not acceptable. There should be no xalan/xercesImpl in JBossAS distro

[ropalka]

David, is it a MUST requirement that MD object model needs to be written back to XML stream?

[rmaucher]

You're not making any sense. JBoss Metadata *is* about doing things properly actually. Processing EE metadata is very complex, needs to be robust, so we cannot afford to redo it from scratch basically. Especially using low level XML code, that cannot work ...

I will be writing a folluw-up on our mailing list I think ...

[alesj]

Also AS 7 will include annotation scanning as part of the class loading architecture in order to accommodate indexing deployments as a separate deployment step, so using another layer will be redundant.

How exactly are you going to do this? Or where is this discussed?

As I wouldn't limit it only to annotations scanning, but making it generic for every resource -- same way it's done now in AS6.

e.g. MC's CL layer has a simple resource visitor abstraction, hidding the filtering,importing,VFS, ... details

[dmlloyd]

Ales Justin wrote:

Also AS 7 will include annotation scanning as part of the class loading architecture in order to accommodate indexing deployments as a separate deployment step, so using another layer will be redundant.

How exactly are you going to do this? Or where is this discussed?

As I wouldn't limit it only to annotations scanning, but making it generic for every resource -- same way it's done now in AS6.

e.g. MC's CL layer has a simple resource visitor abstraction, hidding the filtering,importing,VFS, ... details

The idea is to have O(1) indexes for everything that needs to be searched: annotations, packages, and resources.  Packages and resources are already in an O(1) index thanks to Modules.  The only thing left is annotations.  A Visitor abstraction would typically be O(n) by its nature, if one were to use it for scanning.

The idea is to only introduce abstractions for which there are concrete use cases.  The abstractions should then be tailored for the given use cases.

[rmaucher]

Ok, so you need class hierarchies too

Anyway, I'm really so happy all my EE 6 work is going to the trash. But it's fine since David can redo it in three days. Or four.

[alesj]

Packages and resources are already in an O(1) index thanks to Modules.

How is this done O(1)? (where to look?)

e.g. how do I get all *.hbm.xml files

[dmlloyd]

Ales Justin wrote:

Packages and resources are already in an O(1) index thanks to Modules.

How is this done O(1)? (where to look?)

e.g. how do I get all *.hbm.xml files

Resource directory indexing is done as part of Modules.  It uses JAR INDEX.LIST files to create an O(1) index of every directory in the module.  This means that I can determine whether a resource path is present, and in what resource loader or imported module, in one map lookup without even traversing the module's imports.

Annotation indexing was done by Jason.

We don't have a wildcard-matching index currently, though it might make sense to front-load this task into the domain controller like we are for annotation indexing and INDEX.LIST generation (our plan is to provide offline tooling for the former [the latter is just a question of running jar -i], but if the index is not present in either case the DC will generate it before sending the deployment to the servers).

In any case, even in the event of a complete scan of an archive for the purposes of identifying what is to be deployed, it only has to be done once - when the server is restarted, the deployment state is remembered.

[alesj]

Annotation indexing was done by Jason.

Where in Modules is this?

It might be just me having trouble finding it with all this scattered git stuff ...

[jason.greene]

Ales Justin wrote:

Annotation indexing was done by Jason.

Where in Modules is this?

It might be just me having trouble finding it with all this scattered git stuff ...

David is referring to a component I created awhile back:

http://github.com/jbossas/jandex

It's a generic, small low level component that indexes a set of classes (typically a jar) and provides an incomplete index (only from the viewpoint of those classes). It has no dependencies, and bypasses any kind of bytecode framework (javassist, asm, etc) so that it can take certain optimizations (not processing the full class, and skipping classes that don't have annotations). It also produces a space efficient index that is designed to be read quickly. It's intended to be attractive to all java projects, so that their is a strong incentive for users to index their jars, however initially we just care about fast domain performance.

This is only part of the puzzle though, as to have a complete picture the index lookups have to be aggregated to represent the class loader. That aggregation pattern would likely needed to be coordinated by an API that has the "complete" picture of module imports, deployments, etc (likely similar to AS6). The current Managed Bean impl uses it to index directly, however once the deployment repository is complete it can pull from index files that survive restart. The aggregation doesn't exist yet, and may or may not belong in modules.