Usage of ContributionRepository in ContributionListener interface, was Re: Support for SCA Java package imports/exports, was: svn commit: r559257

[Luciano Resende <lu...@gmail.com>]

I'll take a deeper look at your proposed changes later today or in the
morning, as I'm in the middle of something now... I have one quick
question ...

ContributionRepository was created to allow remote contributions to be
stored in a local repository to be processed by the contribution
service. You now have extended the repository responsibilities to also
track the list of contributions added to the domain, but not
physically stored in the repository, but I still see store and
addContribution implementations working in a disconnected way today in
ContributionRepositoryImpl. Well, I guess I understand why you did it,
basically to be able to pass a list of contribution to the listeners,
so in my scenario, I can use that to instantiate a
ImportAllModelResolverImpl, but we probably need a better discussion
on what are the responsibilities of the Repository,  as there were
some interest of extending it's usage for other scenarios as discussed
in [1], and then review its implementation based on the outcome of
these discussion. Well, I just want to raise the issue to avoid
confusion later on...

[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20100.html

On 7/30/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>


-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Usage of ContributionRepository in ContributionListener interface, was Re: Support for SCA Java package imports/exports, was: svn commit: r559257

[Jean-Sebastien Delfino <js...@apache.org>]

Luciano Resende wrote:
> I'll take a deeper look at your proposed changes later today or in the
> morning, as I'm in the middle of something now... I have one quick
> question ...
>
> ContributionRepository was created to allow remote contributions to be
> stored in a local repository to be processed by the contribution
> service. You now have extended the repository responsibilities to also
> track the list of contributions added to the domain, but not
> physically stored in the repository, but I still see store and
> addContribution implementations working in a disconnected way today in
> ContributionRepositoryImpl. Well, I guess I understand why you did it,
> basically to be able to pass a list of contribution to the listeners,
> so in my scenario, I can use that to instantiate a
> ImportAllModelResolverImpl, but we probably need a better discussion
> on what are the responsibilities of the Repository,  as there were
> some interest of extending it's usage for other scenarios as discussed
> in [1], and then review its implementation based on the outcome of
> these discussion. Well, I just want to raise the issue to avoid
> confusion later on...
>
> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20100.html
>
>   

I left all existing methods in place as I'm anticipating that we'll want 
to merge them at some point:
- find / getContribution
- remove / removeContribution
- store / addContribution and updateContribution
all look pretty similar :)

If you think that tracking the contributions installed on an SCA domain 
is not the responsibility of ContributionRepository, I'm also happy to 
move these methods out into a different class... Whatever option we 
choose, we'll need a clean class - cleaner than a Hashmap buried inside 
ContributionServiceImpl :) - to track which contributions are installed 
on a domain.

--

Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org