You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wagon-dev@maven.apache.org by Michal Maczka <mm...@interia.pl> on 2004/08/17 07:39:06 UTC
Support for Sessions and other planned changes in Wagon API
Hey!
I've seen the latest discussion regarding session in wagon. and ideas
like "Plexus returning Map which hides the access to container".
I've walk this path long ago in early days of wagon and I don't think it
is a right way as it leads to nowhere
There are three problems which we have to solve here:
a) per lookup requires contextalizable lookup requires access to
container and we don't want this
b) how components are released (what does " the magic Map" buy us here?)
c) we need to support the concept of session in Wagon API
The simplest fix which I know is ... to come back to the old design
which was used in
Wagon before and was specially develop to support all those
requirements and to use WagonFactories
Note that
- not every class needs to be a component
- Wagon is loosely modeled after JDBC API - Wagon corresponds to
Connection, Wagon Factory to DataSource.
Datasouce is the perfect candidate for component - connection is rather not.
The same applies to WagonFactory and Wagon
Once we have back WagonFactory classes (which will be plexus component)
- any component willing to talk to repositories will
use them for obtaining an instance of Wagon. They can be declared as any
their dependencies - and WagonFactoryManager will give an access to all
of them.
And a "Session" will be simply .....a wagon which stays connected to the
repository until it is needed.
Wagon (session) can be closed at any place and any time without the
whole problem of releasing it back to plexus.
Wagon are by nature statefull and I think that any attempt which tries
to decouple state from wagon is similar to an attempt
to decouple state from JDBC connection - it is probably doable but it
will result in something more complex then it needs to be.
If somebody has __simpler__ idea how to do this please let me know ASAP
before I will go further will refactoring,
Other thing which I already fixed is the way in which event dispatching
was implemented.
I needed to distinguish listeners which are active (can themselves
generate evens and use wagon) and passive
which are just consuming events and not changing the state.
The idea is that "active" listeners can be only called once and they are
not going to receive any notification about events
which were generated by other listeners. So for example the listers
which transfers MD5 Checksum file won't
conflict with the listener which deploys SHA1 checksum and operation
performed by both can be tracked down
by third listener (e.g. "DEBUG" listener)
Once I am done with those change I will release wagon-alpha-2 which
from my point of view will be
feature complete. Then I will actualize docs and ... we can switch to
beta release cycle
Michal
----------------------------------------------------------------------
Ateny 2004 w Internecie! >>> http://link.interia.pl/f182d
---------------------------------------------------------------------
To unsubscribe, e-mail: wagon-dev-unsubscribe@maven.apache.org
For additional commands, e-mail: wagon-dev-help@maven.apache.org
Re: Support for Sessions and other planned changes in Wagon API
Posted by Jason van Zyl <jv...@maven.org>.
On Tue, 2004-08-17 at 01:39, Michal Maczka wrote:
> Hey!
>
> I've seen the latest discussion regarding session in wagon. and ideas
> like "Plexus returning Map which hides the access to container".
Aside from the test cases Wagon doesn't depend on Plexus at all. So any
discussion of how the Wagons are used inside Plexus doesn't really
affect Wagon at all. The only thing that I would like to be in the Wagon
JARs are the component descriptors.
> I've walk this path long ago in early days of wagon and I don't think it
> is a right way as it leads to nowhere
>
> There are three problems which we have to solve here:
>
> a) per lookup requires contextalizable lookup requires access to
> container and we don't want this
> b) how components are released (what does " the magic Map" buy us here?)
> c) we need to support the concept of session in Wagon API
None of this affects Wagon, I'm not sure what you're talking about. All
Wagon is an API and has some providers.
The discussion is really one of making the Wagons stateless, that's it.
I would simply leave Plexus out of the entire equation as far as the
code goes. Leave the component descriptors in there so they can be used
by plexus but that's really all we need.
Let's just get rid of the plexus dependencies in the way you suggested
and call it a day. This is just getting to the point of silliness if we
do yet another big refactoring. It's working fine, we don't need any
factories or other components in Wagon proper. We can build upon Wagon
which is what you originally intended so let's stick with that.
Wagon can be used as it is for Maven and we can return to the stateless
discussion further.
Why do we need anything else other than an API and the providers?
>
> --
> jvz.
>
> Jason van Zyl
> jason@maven.org
> http://maven.apache.org
>
> happiness is like a butterfly: the more you chase it, the more it will
> elude you, but if you turn your attention to other things, it will come
> and sit softly on your shoulder ...
>
> -- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: wagon-dev-unsubscribe@maven.apache.org
For additional commands, e-mail: wagon-dev-help@maven.apache.org
Re: Support for Sessions and other planned changes in Wagon API
Posted by Jason van Zyl <jv...@maven.org>.
On Wed, 2004-08-18 at 22:34, Michal Maczka wrote:
> Becouce I don't want to use Wagons as components.
Then we agree. In Wagon itself don't use them as components if that's
notion you're following and therefore don't use Plexus at all. It's
really not required.
Leave management of the wagons completely out of the picture for Wagon
proper.
--
jvz.
Jason van Zyl
jason@maven.org
http://maven.apache.org
believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.
-- Buddha
---------------------------------------------------------------------
To unsubscribe, e-mail: wagon-dev-unsubscribe@maven.apache.org
For additional commands, e-mail: wagon-dev-help@maven.apache.org
Re: Support for Sessions and other planned changes in Wagon API
Posted by Michal Maczka <mm...@interia.pl>.
Jason van Zyl wrote:
>On Wed, 2004-08-18 at 21:38, Michal Maczka wrote:
>
>
>>Trygve Laugstøl wrote:
>>
>>Plexus will be used for discovering WagonFactory components.
>>WagonFactory will be used for instatiating Wagons.
>>
>>
>
>-1
>
>That doesn't make any sense. Why would you use all of plexus simply for
>discovery to use something else to instantiate the component?
>
>
>
Becouce I don't want to use Wagons as components. As for me they are
conceptually similar to JDBC connection .
You are not going to do attampt to do things like:
container.lookup( java.sql.Connection.ROLE );
are you?
Note that the differnce for DefaultWagonManager
(http://cvs.apache.org/viewcvs.cgi/maven-components/maven-artifact/src/main/java/org/apache/maven/artifact/manager/DefaultWagonManager.java?rev=1.4&view=auto)
will be almost not existing:
(is)
private PlexusContainer container;
public Wagon getWagon( String protocol )
throws UnsupportedProtocolException
{
Wagon wagon;
try
{
wagon = (Wagon) container.lookup( Wagon.ROLE, protocol );
}
catch ( ComponentLookupException e )
{
throw new UnsupportedProtocolException( "Cannot find wagon which supports the requested protocol: " + protocol );
}
return wagon;
}
public void releaseWagon( Wagon wagon )
throws Exception
{
container.release( wagon );
}
public void contextualize( Context context )
throws ContextException
{
container = (PlexusContainer) context.get( PlexusConstants.PLEXUS_KEY );
}
-------------------------------
(could be)
private Map factoryMap;
public Wagon getWagon( String protocol )
throws UnsupportedProtocolException
{
Wagon wagon;
try
{
WagonFactory factory = (WagonFactory) factoryMap.lookup( protocol );
wagon = factory.createWagon();
}
catch ( ComponentLookupException e )
{
throw new UnsupportedProtocolException( "Cannot find wagon which supports the requested protocol: " + protocol );
}
return wagon;
}
}
so code will be even shorter
Once generics will be commonly used (in 2-3 years) you will be able to
use this technique to have fully strongly typed code.
So basiclly this makes code more beatiful as you don't have to use
container.lookup( Wagon.ROLE, protocol );
But this is not at all important :)
I agree that this is something which I want to put to Wagon in order to
support your use cases from m2.
I don't care much about anything else.
My main case was to support something which you call "session".
You mentioned that you want to have wagon as statless components and
pass to them a kind of memento which encapsulats
state (session).
For me Wagon itself is a __session__ already - in this case state and
operations using this state are encapsualted
in a single object (which imo is a good thing and something compilant
with the spirit of OOP).
As for Factories: There is abolutly no refactoring needed - In case I'll
go for those changes
I just need to add as many classes as we have wagon providers.
I can even have in components.xml files component descriptors for both:
Wagon, WagonFactory
and you will be able to choose which way of instantaing wagon you want
to use.
So if you will want to stick to current desing - you will not be
required to touch any code in m2.
In case when you will be thinking about "object kept in MavenSession" in
the future - this is what I want you propose to use
Michal
-------------------------------------------------------------------
E-maile przez telefon? U nas mozna...
Sprawdz: http://link.interia.pl/f182f
---------------------------------------------------------------------
To unsubscribe, e-mail: wagon-dev-unsubscribe@maven.apache.org
For additional commands, e-mail: wagon-dev-help@maven.apache.org
Re: Support for Sessions and other planned changes in Wagon API
Posted by Jason van Zyl <jv...@maven.org>.
On Wed, 2004-08-18 at 21:38, Michal Maczka wrote:
> Trygve Laugstøl wrote:
>
> Plexus will be used for discovering WagonFactory components.
> WagonFactory will be used for instatiating Wagons.
-1
That doesn't make any sense. Why would you use all of plexus simply for
discovery to use something else to instantiate the component?
Just leave the notion of managing Wagons entirely out of Wagon itself.
Making another layer built upon Wagon is dead simple.
Any patterns for using wagons should be encapsulated in Wagon, we don't
need to talk about releasing them back to containers. The Wagon API
should deal with anything required and an extension layer like
maven-artifact can utilize the patterns.
--
jvz.
Jason van Zyl
jason@maven.org
http://maven.apache.org
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: wagon-dev-unsubscribe@maven.apache.org
For additional commands, e-mail: wagon-dev-help@maven.apache.org
Re: Support for Sessions and other planned changes in Wagon API
Posted by Michal Maczka <mm...@interia.pl>.
Trygve Laugstøl wrote:
>On Mon, Aug 16, 2004 at 10:39:06PM -0700, Michal Maczka wrote:
>
>
>>Hey!
>>
>>I've seen the latest discussion regarding session in wagon. and ideas
>>like "Plexus returning Map which hides the access to container".
>>
>>I've walk this path long ago in early days of wagon and I don't think it
>>is a right way as it leads to nowhere
>>
>>There are three problems which we have to solve here:
>>
>>a) per lookup requires contextalizable lookup requires access to
>>container and we don't want this
>>
>>
>
>Why does a "per lookup" strategy require access to the container?
>
>
>
>>b) how components are released (what does " the magic Map" buy us here?)
>>
>>
>
>I don't think anyone has been talking about needing the special map for
>wagon. The biggest issue the special map is adding newly discovered
>components to the existing map. I would like the map to have a release()
>method on the map too for components that doesn't use the singleton
>lifecycle. I don't know if a special plexus map would implement
>java.util.Map but it would have about the same semantics.
>
>
>
>>c) we need to support the concept of session in Wagon API
>>
>>
>
>Indeed and thats the only problem that you are trying to solve, right?
>
>
>
>>The simplest fix which I know is ... to come back to the old design
>>which was used in
>>Wagon before and was specially develop to support all those
>>requirements and to use WagonFactories
>>
>>Note that
>>- not every class needs to be a component
>>- Wagon is loosely modeled after JDBC API - Wagon corresponds to
>>Connection, Wagon Factory to DataSource.
>>
>>Datasouce is the perfect candidate for component - connection is rather not.
>>The same applies to WagonFactory and Wagon
>>
>>Once we have back WagonFactory classes (which will be plexus component)
>>- any component willing to talk to repositories will
>>use them for obtaining an instance of Wagon. They can be declared as any
>>their dependencies - and WagonFactoryManager will give an access to all
>>of them.
>>
>>
>
>If you don't use plexus for discovery of wagons, how do you propose to
>find all the available implementations?
>
>
>
Plexus will be used for discovering WagonFactory components.
WagonFactory will be used for instatiating Wagons.
We will have one WagonFactory per one Wagon implementation.
WagonFactory is thread safe component which has no state. If you will
replace the word Wagon with Session
it will be more intuitive what's happening - we have SessionFactory (
WagonFactory component) and Session (Wagon which is statful object,
which can be cached in objects like MavenSession ).
You will be just required to close a session (connection) in Wagon - as
Wagon are not components they are not required
to be "released" back to the container.
From the point of view of m2 this should be all hidden in WagonManager
so classes using WagonManager class will feel almost no difference (only
difference will be that WagonManager won't have "release" method anymore)
Michal
----------------------------------------------------------------------
Ateny 2004 w Internecie! >>> http://link.interia.pl/f182d
---------------------------------------------------------------------
To unsubscribe, e-mail: wagon-dev-unsubscribe@maven.apache.org
For additional commands, e-mail: wagon-dev-help@maven.apache.org
Re: Support for Sessions and other planned changes in Wagon API
Posted by Trygve Laugstøl <tr...@student.matnat.uio.no>.
On Mon, Aug 16, 2004 at 10:39:06PM -0700, Michal Maczka wrote:
> Hey!
>
> I've seen the latest discussion regarding session in wagon. and ideas
> like "Plexus returning Map which hides the access to container".
>
> I've walk this path long ago in early days of wagon and I don't think it
> is a right way as it leads to nowhere
>
> There are three problems which we have to solve here:
>
> a) per lookup requires contextalizable lookup requires access to
> container and we don't want this
Why does a "per lookup" strategy require access to the container?
> b) how components are released (what does " the magic Map" buy us here?)
I don't think anyone has been talking about needing the special map for
wagon. The biggest issue the special map is adding newly discovered
components to the existing map. I would like the map to have a release()
method on the map too for components that doesn't use the singleton
lifecycle. I don't know if a special plexus map would implement
java.util.Map but it would have about the same semantics.
> c) we need to support the concept of session in Wagon API
Indeed and thats the only problem that you are trying to solve, right?
>
> The simplest fix which I know is ... to come back to the old design
> which was used in
> Wagon before and was specially develop to support all those
> requirements and to use WagonFactories
>
> Note that
> - not every class needs to be a component
> - Wagon is loosely modeled after JDBC API - Wagon corresponds to
> Connection, Wagon Factory to DataSource.
>
> Datasouce is the perfect candidate for component - connection is rather not.
> The same applies to WagonFactory and Wagon
>
> Once we have back WagonFactory classes (which will be plexus component)
> - any component willing to talk to repositories will
> use them for obtaining an instance of Wagon. They can be declared as any
> their dependencies - and WagonFactoryManager will give an access to all
> of them.
If you don't use plexus for discovery of wagons, how do you propose to
find all the available implementations?
>
> And a "Session" will be simply .....a wagon which stays connected to the
> repository until it is needed.
> Wagon (session) can be closed at any place and any time without the
> whole problem of releasing it back to plexus.
> Wagon are by nature statefull and I think that any attempt which tries
> to decouple state from wagon is similar to an attempt
> to decouple state from JDBC connection - it is probably doable but it
> will result in something more complex then it needs to be.
>
>
> If somebody has __simpler__ idea how to do this please let me know ASAP
> before I will go further will refactoring,
>
>
> Other thing which I already fixed is the way in which event dispatching
> was implemented.
>
> I needed to distinguish listeners which are active (can themselves
> generate evens and use wagon) and passive
> which are just consuming events and not changing the state.
>
> The idea is that "active" listeners can be only called once and they are
> not going to receive any notification about events
> which were generated by other listeners. So for example the listers
> which transfers MD5 Checksum file won't
> conflict with the listener which deploys SHA1 checksum and operation
> performed by both can be tracked down
> by third listener (e.g. "DEBUG" listener)
>
> Once I am done with those change I will release wagon-alpha-2 which
> from my point of view will be
> feature complete. Then I will actualize docs and ... we can switch to
> beta release cycle
>
> Michal
>
> ----------------------------------------------------------------------
> Ateny 2004 w Internecie! >>> http://link.interia.pl/f182d
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wagon-dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: wagon-dev-help@maven.apache.org
>
--
Trygve