1 2 Previous Next 24 Replies Latest reply: Jun 13, 2010 6:02 PM by Dan Allen Go to original post RSS
  • 15. Re: ShrinkWrap - Descriptors
    Aslak Knutsen Master

    @ALR @epbernard
    Regardless of the Descriptors, we need the basic function that "specializes" gives us. A way of moving a nested archive into a new 'extension' type.

    The best example I have as for now is:

    EnterpriseArchive ear = ..
    WarArchive war = ear.getPathAsA("my.war", WebArchive.class)
    


    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)

  • 16. Re: ShrinkWrap - Descriptors
    John Bailey Novice

    I agree they need to be decoupled. When combined the interface has a bit of mismatch. This may simply be due to Discritptor being in the name. The following looks very strange to me:

    WebArchiveDescriptor webArchiveDescriptor = ...
    
    webArchiveDescriptor.add(path, archive)
     .addWebResource(path, asset);
    
    


    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.

    Could look like the following:

    WebArchive webArchive = ....
    WebArchiveBuilder builder = new WebArchiveBuilder(webArchive);
    
    builder.addLibrary(...)
     .addWebResource(...)
     .addServlet(...);
    
    



    It may be the builder is too generic, but it does seem to better describe what you are doing. It would also be possible to do the following:

    WebArchive webArchive = ....
    WebArchiveDescriptor descriptor = new WebArchiveDescriptor(webArchive);
    
    webArchive.addWebResource(descriptor);
    
    descriptor.addFilter(...)
     .addServlet(...);
    
    


    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.




  • 17. Re: ShrinkWrap - Descriptors
    Emmanuel Bernard Master

    web.xml "name" does not exists, it's displayName so that one is a non issue :)
    I don't follow you the second example. What do you mean by addServlet name forms?

    Assuming we are careful with the Archive method names (potentially by prefixing them), the risk of collision will be close to none and each subdomain can take care of itself.

  • 18. Re: ShrinkWrap - Descriptors
    Aslak Knutsen Master

    I'm conflicted.

    I like the idea of having the Descriptors integrated, and I like them separated..

    For me it kinda boils down to:

    What is a WebArchive(war) without its Descriptor(web.xml)?
    (If we ignore parts of the upcomming Servlet 3.0 spec)
    Not much.

    What is a ResourceAdapterArchive(ra) without its Descriptor(ra.xml)?
    ?

    What is a EnterpriseArchive(ear) without its Descriptor(application.xml)?
    Most common usecases were removed with J2ee 5?

    What is a EJB Archive without its Descriptor(ejb-jar.xml)?
    Most common usecases were removed with J2ee 5.


    This is all spec related questions. We of course have the set of Container specific deployment descriptors as well.. but that is another story.

  • 19. Re: ShrinkWrap - Descriptors
    Andrew Rubinger Master

     

    "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()".

    S,
    ALR

  • 20. Re: ShrinkWrap - Descriptors
    Andrew Rubinger Master

    Hehe, another snag is that these Container types have *versions*. So what version of the web.xml domain are we supporting? :) Or multiple, with the ability for users to define/plug in their own?

    S,
    ALR

  • 21. Re: ShrinkWrap - Descriptors
    Jason Greene Master

    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.


  • 22. Re: ShrinkWrap - Descriptors
    Aslak Knutsen Master

    Ok, I've done a little test with the 'Specializes' style.

    http://shrinkwrap.pastebin.com/mdca7a45

    Short v:
    - new interface Spercializer
    - Archive extends Specializer and performs the lookup via ArchiveExtensionLoader
    - SpecializerBase impl Specializer with delegation to Archive
    - ContainerBase extends SpecializerBase
    - WebArchiveDescriptor extends Specializer
    - WebArchiveDescriptorAsset extends SpecializerBasse impl Asset, WebArchiveDescriptor


    The new SPI looks like:
    - implements Spercialized
    - 1 argument constructor that extends Archive

    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.

    (ps: ignore the horrible ArchiveExtensionLoader impl for now.. :)

  • 23. Re: ShrinkWrap - Descriptors
    Aslak Knutsen Master

    Not sure its the right place for it, but the road is very short for the importer/exporter APIs to be implemented the same way.

     new MemoryMapArchiveImpl()
     .as(ZipImporter.class)
     .import("my.war")
     .as(WebArchiveDescriptor.class)
     .addListener(this.getClass())
     .addContextParameter("context-1", "value")
     .addServlet(Exception.class, "/*")
     .as(WebArchive.class)
     .addClass(this.getClass())
     .as(ZipExporter.class)
     .export("my-new.war");
    


  • 24. Re: ShrinkWrap - Descriptors
    Dan Allen Master

    Please jump over the ShrinkWrap development forum for the remainder of this discussion.

     

    DSL for XML descriptors

1 2 Previous Next