1 2 3 Previous Next 34 Replies Latest reply on Dec 30, 2013 12:48 PM by rbattenfeld Go to original post
      • 15. Re: ShrinkWrap Descriptors Reboot

        A nice example (and appreciated), but IMO backwards.  I want us to envision the eventual ideal in terms of API and usage, then investigate the tools which will get us there.  For instance the generated code in the gist doesn't pass muster for all requirements we have listed.

        • 16. Re: ShrinkWrap Descriptors Reboot

          Right, I think you might be reading too much into my post.  It's not "wow, xjc does a great job" it's "wow, this is a pretty fluent API with a couple of caveats"  It fixes a few issues I have with the code.  First, I don't need a factory if I'm creating a new one; I can simply do Foo x = new Foo().  I can easily navigate the object structure.  I also don't end up with that inverse XML syntax with the generics.

          • 17. Re: ShrinkWrap Descriptors Reboot

            Excellent.  Though I might have missed the fluent component of what XJC is doing; I caught a lot of methods (ie. setDescription()) which return void instead of "this".

            • 18. Re: ShrinkWrap Descriptors Reboot

              I would be interested in seeing a hierarchical relationship between descriptor types.


              E.g. WebAppDescriptor_3_0 extends WebAppDescriptor_2_5

              • 19. Re: ShrinkWrap Descriptors Reboot

                Interesting, for types that are supersets of their prior version.  Add to the desired requirements page?

                • 20. Re: ShrinkWrap Descriptors Reboot

                  Already done

                  • 21. Re: ShrinkWrap Descriptors Reboot

                    Nice idea but I am not sure what this should solve. I see unpredictable behavour and a nightmare for testing.


                    What I would propose is something like a top level descriptor that returns a version based instance:


                       final WebAppDescriptor descr = Descriptor.getInstance(DescriptorType.WebAppDescriptor, Version.7)


                      final WebAppDescriptor descr = WebAppCreator.getInstance, Version.7)


                    Is that what you want to simplify? The several versions per descriptor type?

                    • 22. Re: ShrinkWrap Descriptors Reboot

                      What I really want to simplify is use of the Descriptor for features that are backwards compatible. For instance... all Servlet specs allow addition of a filter. You shouldn't have to re-program that functionality for each spec version, but without inheritance (or shared interfaces) there is no way to effectively use OO polymorphism and re-use the code (without reflection, and that would be narsty)

                      • 23. Re: ShrinkWrap Descriptors Reboot

                        I think it's the trade off between the code gen'd approach that the current descriptors take, and actually putting some code behind the descriptor implementations.


                        Personally, I'd much rather a simple pojo based approach for making these things, easier to understand conceptually.

                        • 24. Re: ShrinkWrap Descriptors Reboot

                          I view the code-gen as an implementation detail.  In the revised requirements I note a section for custom overriding of methods in the code to ensure we can put whatever we want in place on a case-by-case basis. 


                          What do you mean by "POJO-based approach"?  Even the current descriptors are POJOs just adhering to an API.


                          The tricky bit would be in determining exactly what the hierarchy would be for, say, EE7 descriptors which would also fulfill EE6 APIs.  My first thought is that it wouldn't be inheritance, but rather the EE7 impl would fulfill both the EE6 and EE7 API interfaces (ie. composition).



                          • 25. Re: Re: ShrinkWrap Descriptors Reboot

                            Maybe a simple 'toplevel version less Marker interface' pr Descriptor could work, with a option to 'swap' between the different versions..


                            package org.shrinkwrap.descriptors.webapp;
                            public interface WebAppDescriptor { }
                            package org.shrinkwrap.descriptors.webapp.ee5;
                            public interface EE5WebAppDescriptor implements WebAppDescriptor { }
                            package org.shrinkwrap.descriptors.webapp.ee6;
                            public interface EE6WebAppDescriptor implements WebAppDescriptor { }
                            package org.someother.project;
                            This method defines it require 'some' WebAppDescriptor to limit
                            it from just 'some' Descriptor, but the interface doesn't have to
                            define if it's a EE5 or EE6 descriptor.
                            public void doDescriptorWork(Descriptor<WebAppDescriptor> desc) {
                               we currently only support EE5, or we know (programmer knowlegde)
                               that the EE5 methods we use will work on EE6 and EE7 as well.
                               Lowest common denominator, even tho not enforced by API.
                               Following similar rules as ShrinkWrap Archives. There is a underlying model
                               and there is a View on top. I view this as a EE5 descriptor.
                            • 26. Re: Re: ShrinkWrap Descriptors Reboot

                              Inheritance, interfaces, whatever You know what I meant.

                              • 27. Re: Re: ShrinkWrap Descriptors Reboot

                                Something like this would probably be OK. But having a shared *interface* hierarchy would probably be ideal.

                                • 28. Re: Re: Re: ShrinkWrap Descriptors Reboot

                                  I think we can get away without "marker" interfaces and satisfy the requirement by taking some cues from Aslak's latest post:


                                  public interface WebAppDescriptor { // All the EE5 operations here }
                                  public interface EE5WebAppDescriptor extends WebAppDescriptor { // Nothing in here }
                                  public interface EE6WebAppDescriptor extends EE5WebAppDescriptor { // EE6-specific ops here }


                                  Then users can either request any "WebAppDescriptor" or a specific version.  The difference in mine here is that EE6 extends EE5, and that the EE5 support actually is defined in the generic "WebAppDescriptor"  The reason for this: avoid the need to "swap" views.  Potential problems with this approach: if there is ANY SINGLE INSTANCE where EE6 is not back-compat with EE5, ie. is not a superset of EE5.




                                  • 29. Re: ShrinkWrap Descriptors Reboot

                                    I assume that the that the 'extend' approach will lead to a growing descriptor instance, right?. The latest one will allow to set for example in case of a WebAppDescriptor filters for EE5, EE6 and EE7 correct?


                                    Or do you intend somehow to 'merge' the potentially different class definition, e.g Filter class?


                                    What I want to point out is that to discuss this on the top level Descriptor interface is too simplyfied (for me). Could you give an example how to deal with the nested classes referenced by the descriptors? Currently, we have a distinct version for each class and XSD version. This is actually the same issue we had with the mutual / non mutual view in SHRINKDESC-21, I believe.