The storage engines will be wrapped up/delegated to by the Java/WebArchive spec impls and
never exposed directly through the chaining in the Archive interface.
The thought was to let the Storage Engines have there own Archive interfaces and not
depended on the specs.
The spec impls would wrap up the storage engines(handeled by a support Superclass) like:
| public JavaArchive add(Asset... assets)
| {
| archive.add(assets);
| return this;
| }
|
They do not extend the storage engines nor do they expose them directly in this way:
| public JavaArchiveImpl extends MemoryArchiveImpl {
| }
|
|
| public JavaArchive add(Asset... assets)
| {
| return archive.add(assets);
| }
|
Here is a more complete stack example:
| public interface ServiceProviderDelegate
| {
| Archive<?> getDelegate();
| }
|
| public interface MemoryArchive extends Archive<MemoryArchive>
| {
| }
|
| public class MemoryArchiveImpl implements MemoryArchive
| {
| }
|
| public class JavaArchiveImpl implements JavaArchive, ServiceProviderDelegate
| {
| Archive<?> archive;
|
| public JavaArchiveImpl(Archive<?> archive)
| {
| this.archive = archive;
| }
|
| public JavaArchive add(Asset... assets)
| {
| archive.add(assets);
| return this;
| }
|
| @Override
| public Archive<?> getDelegate()
| {
| return archive;
| }
| }
|
| JavaArchive jar = new JavaArchiveImpl(new MemoryArchiveImpl());
|
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250798#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...