Ok, I've done a little test with the 'Specializes' style.
- 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.. :)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257788#4257788
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257788
"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()".
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257739#4257739
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257739
anonymous wrote : I am not sure why spend the effort creating a new global section to the jboss-esb.xml.
Sorry I might not have done a very good job at explaining this. This issue came up after the addition of the new http-provider. This has the ability to specify a security domain. There is only one war per jboss-esb.xml so this means that this security domain is shared among the all http-providers and all EBWS. To make it clear that this configuration has an effect outside of the http-provider it was decided to create this new global section.
anonymous wrote :
| In a service oriented architecture each service should be independently deployed, so from a best practice standpoint, I think having a separate jboss-esb.xml file for each service makes more sense.
But even with a single service in the esb users might want to have a http-provider (REST) configured and at the same time expose the service as a web service (EBWS). Users might want to configure security for the war that gets generated. Having the configuration in a separate section of jboss-esb.xml hopefully makes it clear that this setting effects the whole war.
anonymous wrote : What I would like to understand is that even when authentication is performed by the container, the EBWS gateway will add the security token to the ESB message context, and that the ESB will use this for authorization to ESB services, i.e. rolesAllowed and runAs would be supported.
The container/gateway level security is separate from the security at the esb service level. This means that unless there is a Single Sign On solution in place there will be a another authentication when the call reaches the esb service. The esb level security is not affected by this work.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257738#4257738
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257738
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)
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.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257708#4257708
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257708