In this case, since EnterpriseArchive and WebArchive have a relation it's probably better to have WebArchive archive = EnterpriseArchive.getWebModule(path); but i would like this to be just a struct impl over something like archive.getPathAsA(path, WebArchive.class)

The issue I have is neither of those operations really affects the descriptor for the archive, but nothing would tell me that from the usage.

If the archive behavior was kept as it is today and the WebArchiveDescriptor actually implemented Asset (which is what it is in the end) that will serialize the content to xml prior in the getStream call. There could then be a builder that creates a unified interface to both WebArchive, and WebArchiveDescriptor. Internally the builder creates the WebArchiveDescriptor(extends asset), adds it as the web.xml asset for the archive, and delegates to the archive, descriptor, or both as needed.

There is a bit more code, but it is more clear when operations affect the archive structure/contents, and when they affect the descriptor. The nice thing about some unified interface like the builder is there are cases where the operation affects both, like addServlet adding the both the descriptor information and the asset.

"epbernard" wrote:web.xml "name" does not exists, it's displayName so that one is a non issue :)

Bah, you get the idea. ;) The fact is that archives don't have associated metadata; their descriptors do. So lumping every operation together in one master object gives me the feelings of an antipattern.

You could counter that argument by saying that descriptors are the only mechanism to give "real" archives some metadata, and that they're in fact one and the same. But I still prefer to draw the line.

"aslak" wrote:What is a ResourceAdapterArchive(ra) without its Descriptor(ra.xml)?

The way I'm proposing, just a regular archive which additionally supports "public ResourceAdaptorDescriptor getDescriptor()".

We can have our cake and eat it too. Offering an integrated API can be done in such a way that still allows for nice separation and modularity. Emmanuel's suggestion for adding an extension point with a generic typed parameter accomplishes this (.asArchive/specializes). It's type-safe, extensible, and super-friendly.

The ArchiveExtensionLoader will try to do lookups recursive, so in the WebArchiveDescriptorAsset case, the flow is:- Lookup impl for WebArchiveDescriptor based on WebArchiveDesctiptor META-INF/Service/...- Find suitable constructor on found class- Finds constrcutor with argument WebArchive -- Lookup impl for WebArchive .. -- Find suitable constrcutor -- Construct WebArchiveImpl with given Archive- Construct WebArchiveDescriptorAsset with WebArchiveImpl

A side effect of this change is that we can move the spec impls and descriptor impls over to the SPI package, since they now are actually loaded dynamically.