"aslak" wrote : "epbernard" wrote : | | BTW I dont' think specializes(Class<T extends Archive> clazz, Path basePath) should be here, what does it do to a real user, what's the use case? | | | | WarArchive war = ear.specializes(WebArchive.class, "my.war"); | | should raise an exception IMO as we do not specialize, we actually add a new archive inside an archive. An EAR contains a WAR, it is not a WAR. | | | We mostly create/add, but we have the Importer API as well, meaning you can import an existing war/jar/ear etc. In this case the API might not know what type of file is actually in there(here we could do some file extensions checks etc, but that's not always a fit. especially when it comes to descriptors).. So you want the Resource at Path X in the imported Archive 'specialized' as a WebArchive so that you can manipulate the classpath or web.xml. | | I imagine that ear.getModule("my.war").specializes(WebArchive.class) is a bit clearer, marginally more verbose and more consistent. WDYT? anonymous wrote : | "epbernard" wrote : | | So if I sumamrize, a descriptor is a super interface of archive that describes a given configuration file like web.xml. Why separate it from the WebArchive interface exactly? | | | | Also remember that some configuration files can be at disfferent places and be multiple. For example in JPA, orm.xmls can be named as it pleases you and you can add many of them. | | | I Agree, I think most of the Descriptors(they are suppose to describe the content after all) are so tightly coupled with the Archive itself, that WebArchive implements WebArchiveDescriptor makes sense. | | The reason for having it as a separate Interface is to be able to have a Asset(file) implement the same, so that we can support adding descriptor files to different paths. ie: | | | WebArchive war = .. | | war.addWebResource("my-web.xml", new WebArchiveDescriptorAsset()); | | | | Well war.addWebResource returns WebArchive and that forces the user to break the fluent API to build the asset. Trying idea. What if we merge somehow XArchive and ZAsset from the user PoV. The only difference would be the method that provides it. For example. | archive.specializes(WebArchive.class) | .displayName("Example") | .addWebResource( "my-web.xml", WebArchive.class) | .displayName("My Example") | .addWebResource("my-web2.xml", WebArchive.class) | // ... | .addClass(User.class) | .specializes(PersistenceArchive.class) | .persistenceProvider(HibernatePersistence.class); | | //BTW displayName is better than setDisplayName for fluent APIs and tells | //BTW2 addWebResource, couldn't it be addResource with a specialized logic when it's a web archive? | the user that it's not a Java setter. | Better names still have to be found but the API flows more easily and the diff between an "asset" / file and an archive / zip is addXResource vs specializes. Better names could be specializes(WebDescriptor.class) => asArchive(WebDescriptor.class) addWebResource => add(Web)Resource anonymous wrote : | Having the specializes(class, path) also helps out in your orm.xml example i guess.. | | | JavaArchive jar = .. | | PersistenceDescriptor desc = jar.specializes(PersistenceDescriptor.class, "my-orm.xml-path") | | | But that's a resource in this case. anonymous wrote : | The name specializes might not be the correct wording in these cases. maybe something like "get as", "convert to" or "re map". | Exactly see above. anonymous wrote : | Another interesting 'issue' is how should we handle for instance the jboss-web.xml. In some cases it is all standalone, but in other it uses the same names as in web.xml.. descriptor pipeline ? | I don't quite understand this one but I am not familiar with jboss-web. WDYM by pipeline? If jboss-web extends the structure of web.xml, you can subclass WebDescriptor.class to JBossWebDescriptor.class View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257564#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...