-
1. Re: JBoss 7 ClassNotFound using interface implementation
nickarls Feb 5, 2013 4:40 AM (in response to sven.plath)Would it work if you had a module like com.acme.pages which would have pages-api.jar (the Pages interface) and pages-impl.jar (Pages implementation) and a similar module for the registry concept and then a top-level app module?
-
2. Re: JBoss 7 ClassNotFound using interface implementation
sven.plath Feb 5, 2013 10:54 AM (in response to nickarls)Hey,
okay, let me first show you what I 'understood' (only utilizing one API for both registry and page for the sake of simplicity):
Module API:
public interface Registry
public interface Page
Module Impl:
public class RegistryImpl implements Registry
public class PageImpl implements Page
Module App:
public class someAccessClass
I tried that approach, however the problem remains. Dependency graph is:
App depends on API
Impl depends on API
-
3. Re: JBoss 7 ClassNotFound using interface implementation
nickarls Feb 5, 2013 12:48 PM (in response to sven.plath)I was thinking in the lines of
Page Module (com.acme.page)
page-api.jar
page-impl.jar
Registry Module (com.acme.registry)
registry-api.jar
registry-impl.jar
You are always going to have a impl -> api dep but at least it will always be within a module. And the app then uses the APIs.
-
4. Re: JBoss 7 ClassNotFound using interface implementation
sven.plath Feb 6, 2013 2:52 AM (in response to nickarls)Hey,
the problem is that sometimes, more than one impl exists (in fact, this is currently very common in our deployment scenarios). And because we want them to sit side by side and not in one big mega module, we need a decoupling.
Thanks,
Sven
-
5. Re: JBoss 7 ClassNotFound using interface implementation
nickarls Feb 6, 2013 3:01 AM (in response to sven.plath)If you have multiple Page implementations, they could all live in the page-impl.jar. Or you could have page1-impl.jar, page2-impl.jar and the page module.xml would reflect that. Or is it me misunderstanding here?
-
6. Re: JBoss 7 ClassNotFound using interface implementation
nickarls Feb 6, 2013 3:05 AM (in response to sven.plath)If you have many Page implementations, you could have page1-impl.jar, page2-impl.jar etc and have the Page module.xml include them
-
7. Re: JBoss 7 ClassNotFound using interface implementation
sven.plath Feb 6, 2013 3:10 AM (in response to nickarls)So you suggest that I should define circular dependencies? I also thought of that, but I feared that it is evil .
I think I will go with that. However, it is hard to define these dependencies because normally, the Page does not know how many Impl exist, so we would have to adjust it for every different deployment scenario.
Thanks again for your food of thought.
Sven
-
8. Re: JBoss 7 ClassNotFound using interface implementation
nickarls Feb 6, 2013 3:18 AM (in response to sven.plath)One option could be to have them all in the WAR lib (appropriately split into api/impl jars) and then use CDI Instance like
@Inject @Any Instance<Page> pages;
and you could iterate over the implementations. It all depends on how use the various implementations. Splitting into jars is good regardless of classloading, the module approach has the backside of a deployment no longer being a "drop-in-operation".
It could of course be what it required (e.g. customers have different implementation modules). Not sure how CDI picks up in stuff in modules currently, though.
BTW, what was the circular deps you mentioned? page-api, page1-impl and page2-impl would be in the same module (with no outgoing deps) and the application would depend on the module.
-
9. Re: JBoss 7 ClassNotFound using interface implementation
sven.plath Feb 6, 2013 4:04 AM (in response to nickarls)Hi,
regarding the circular deps, i was thinking of splitting page-api, page1-impl and page2-impl into different deployment units. It would resemble our way of developing stuff (we do not really want top-level modules if it can be avoided). I believe we will rethink our architecture to avoid implementing Interfaces, but making the Page class configurable so that it can be used in different scenarios. For example something like this:
Module A:
public class PageRegistryImpl implements PageRegistry
public interface PageRegistry
public class Page
Module B:
public class SomeAccessClass
public class SomeAccessClass { private PageRegistry registry; public void do() { registry = getRegistry(); registry.register(new Page(configuration)); } }
We currently think this would be a feasible solution. We really do not want to package stuff in a WAR (all our libraries and EJBs will be deployed seperately, not inside a WAR / EAR). Think of OSGi projects with hundreds of different bundles installed side by side.
I believe we have a design flaw here that the JBoss 7 revealed. I hope the stuff I said makes sense .
Thanks a lot for your input.
Sven Plath