Jean-Sebastien Delfino wrote:
[snip]
Luciano Resende wrote:
Thanks for checking Sebastien, most is in SVN now, and I have already
cleaned up the classLoader issue you mentioned. Indeed, I have couple
questions...
- We need a better extensible way to handle the matching of
import/export to proper initialize the resolvers. I have looked into
using the ArtifactProcessor.resolve to handle part of this (as
suggested on the code comments), but I could think about couple issues
: the processor might bot have all the required dependencies to proper
find the matching import/export and to initialize the resolvers, also
the processors might be contributed by the not really be tied together
with the module that implementing the import/export support (java
case). So, any ideas are welcome... For now, TUSCANY-1488 [1] shows a
workaround that is working on top of svn.
Ok, ArtifactProcessor.resolve is probably not the right method to do
that then, as it doesn't have the correct context.
ContributionPostProcessor.visit seems more promising, but it is not
given the list of available contributions. I'll take a look at what
you've done and see if I can come up with any ideas.
To overcome the limitations with ContributionPostProcessor I have added
a strawman of some support for Contribution listeners:
o.a.t.contribution.service.ContributionListener and
ContributionListenerExtensionPoint.
Here's how to use it:
- Get the ContributionListenerExtensionPoint from the extension point
regsitry
- Add your ContributionListener to it
- A ContributionListener implements contributionAdded,
contributionRemoved, contributionUpdated methods allowing it to be
notified of these events and process the contribution (e.g. connect
imports to exports, disconnect them when a contribution gets removed)
- ContributionListener is also passed an instance of
ContributionRepository, which allows you to find contributions by URI or
get the list of all contributions
- To get this to work I also simplified ContributionServiceImpl a bit
which was using two different registries of contributions before:
contributionRepository and contributionRegistry. It's only using
contributionRepository to track which contributions are there now.
I hope this helps. With this I think you should now be able to:
- Remove the dependency from contribution-impl on contribution-java
- Plug in the logic to connect/disconnect imports -> exports in a
ContributionListener implemented in the contribution-java module
- Move the logic for XML namespace imports to a separate
ContributionListener as well (which could stay in contribution-impl)
Finally, I think that the logic in ImportSDOPostProcessor could be
refactored as a listener as well. In fact I marked
ContributionPostProcessor deprecated for now as ContributionListener
provides equivalent + more complete function.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
