rakesh bhakta wrote:
Main question - do you have the classes that make up the API of you services separate from the classes that deal with the implementation? If yes - then you clients need to be aware of this api and the address of your block.
Hope that clarifies things.
Steve.
Your explanation and merlin?s behavior is consistent and reasonable.
Yes, I do have separate API jars; but I think I need to give impl jars too.
So, I have not found a way to do that without explosing all the internal classes.
The best way to expose a service without exposing the implementation is to use a <include>. Basically thing work as follows:
|--------------------------| | <container name="A"> | | <classloader> | |-------------------------| | * api 1 jar | | <container name="B"> | | * api 2 jar | | <classloader> | | * small manager jar | | * dirty impl stuff | | <classloader> | | </classloader> | | | | <services> | | <include ... /> <------------->| <service type="..." | | | | | | | <component .. > | | </service> | | | | | | | | <component ...> | | | | <component ...> | | | | | | |
The only thing an import introduced from container B into container A is the service. If effect all of the implementation classes are locked away in a separate classloader.
But, perhaps I am looking at the problem wrong; it may not be a jar issue.
Let me try to further explain using avalon\merlin\platform\tutorials\composition.
Let?s say, that in composition\publisher\impl\conf\block.xml, I add another
component called ?DatabasePublisher? which takes <configuration> of jdbc-url.
I believe in composition\application\impl\conf\block.xml, I can use <dependency> to use the new ?DatabasePublisher?, and <profiles> or <targets> to setup the jdbc-url. Correct?
It's possible - but I would not recommend it - its better to import a service from which you make a selection request (otherwise the container that references a named component in an imported container is compromised because its using names that are specific to the imported container).
Now, let say the composition\application needs multiple ?DatabasePublisher?
services, each with its own jdb-url. My current thought is that this is only
possible by create the extra DatabasePublishers within
composition\application\impl\conf\block.xml, and thus bringing the impl jar
and all its dependent jars.
That's one approach. Another approach is to look at the problem in terms of the consumer component's service requirements. If your consumer component can make request for connections using expressions that describe the "type" of connection it requires (as opposed to requesting a named connection) then your maintaining good separation between service and implementation. For example, a client component could request a persistent connection by supplying a selection policy, or perhaps identifying connections in terms of expected storage integrity (long term, versus a session cache). With that resolved you would able to publish a single service from container B to container A and container A would not need to know anything about the implementation strategy of container B.
I was hoping that using Artifact packaging (*.jar.meta file), I would be automatically bring in the dependent jars. This did not work. .
Doing an import is basically doing the same thing. The only real difference with the .meta is that .meta supports staged classloader definitions (but that's not an issue here - all you need to do is to make sure that the API exposed by B is contained in the classloader definition in A.
Is there any other solution?
There's always another solution!
;-)
Cheers, Steve.
_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar ? get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
|---------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
