geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Warning of change in configId format
Date Tue, 22 Nov 2005 23:52:58 GMT

On Nov 22, 2005, at 3:16 PM, Aaron Mulder wrote:

> I don't understand why people are using "repository" and
> "config-store" interchangeably.

Right now the config-store used in geronimo happens to not relate the 
configId and the file location.  I'm interested to see what happens if 
I implement a config-store that stores the configs in a (geronimo) 
repository.  However, the geronimo classes certainly have different 
methods and functions.

>
> My understanding of "repository" is that it's "where third-party
> libraries are stored".  A URI into the repository works like maven by
> convention because that's how we've chosen to lay out our repository.
> But for our file system repository implementation, we could also just
> put stuff in "any old place" under the repository root, and then the
> URI's would have to look like not-Maven-style in order to work.

So, the URIs for our standard repository follow the maven convention, 
although other choices are possible.  We could equally well insist that 
the configIds follow a maven convention, although other choices are 
possible.  Also, to perhaps nitpick, "third-party" is perhaps not quite 
accurate, all of geronimo is there too :-).
>
> My understanding of "config-store" is where all the code and config
> info for a particular deployed server configuration is stored.  We
> specifically avoid any knowledge of how things are laid out within the
> config store by using abstract names to identify the entries there
> (though in practice, our current implementation stores entries in
> sequentially numbered directories).

Yes, and we could, if we chose to, by convention, use maven style 
configIds, put the configs in a maven repo structure.  This is 
certainly not the only choice, but I believe it offers many advantages. 
  One is that it provides some advice on how to construct a configId.
>
> My understanding of "packaged configurations" is "you take whatever's
> in config-store/22 and zip it" -- now you have a "packaged
> configuration" or "CAR" and the repository was never involved.  If you
> want to move that to a different server, you pass the ZIP/CAR to the
> other server, it picks the next available config-store ID (say, 44)
> and unzips the thing into config-store/44.  Again, no repository
> involved.

To me you are confusing one way of constructing a packaged 
configuration with the concept itself.  I think it's a jar file with a 
serialized gbean data for a Configuration gbean in a particular 
location inside.  You are also dragging in many implementation 
artifacts of our current LocalConfigStore which are irrelevant to its 
purpose or interface-defined functioning.  I think there are errors in 
the current interface that obscure its functioning and tie it 
unnecessarily to a file system implementation.  Certainly the 
directory-numbering is pretty irrelevant to its functioning.

>
> So my view of a configId is it's the abstract/human-readable name used
> to interact with the thing that the config-store knows of as
> "config-store/22" on server 1 and "config-store/44" on server 2.  If
> we put a name or version or whatever in the configId that's OK, but it
> doesn't correspond to anything on the file system, it's just part of
> the chunk of text that identifies that entry in the config-store.  In
> particular, tying the human names of entries in the config-store to
> the layout of files in the repository seems unnatural to me.

I think it is all what conventions we want to support and encourage.  I 
think maven style config ids have numerous advantages, most of which 
are the same advantages of using them for your projects jar files 
rather than the random names and missing versions so prevalent outside 
maven-influenced projects.  In particular, more or less forcing people 
to include a version number in the configId can only be a good thing.  
So, we could implement un-maven-like repositories and config-stores, 
but why would we encourage such rampant disorganization?

I'm not sure I'm getting your point.... have you tried building 
geronimo with the packaging and assembly plugins and looking at how it 
works?  I've been somewhat influenced by that, and I might not be 
seeing the same things you are.

thanks
david jencks

>
> Help!
>
> Thanks,
>     Aaron
>
> On 11/22/05, Dain Sundstrom <dain@iq80.com> wrote:
>> On Nov 22, 2005, at 1:35 PM, David Jencks wrote:
>>
>>> To me the biggest problem here is still backwards compatibility and
>>> if/how we can support it.  Dain suggested (privately) that we might
>>> have a conversion table for our configids so that an old plan would
>>> still deploy.  This is possible but really ugly.  I will look into
>>> just how ugly :-)  I'd certainly appreciate any other opinions on
>>> how serious a problem this is and what we can do about it.
>>>
>>> Now to more specific responses:
>>> On Nov 18, 2005, at 6:59 AM, Aaron Mulder wrote:
>>>
>>>> I assume it will be the case that the configId declaration in the
>>>> file
>>>> will therefore control which repository location the CAR is 
>>>> installed
>>>> in -- so if you change the configId, it changes the install 
>>>> location.
>>>> Is that correct?
>>>
>>> well, maybe.  The packaging plugin is the only way currently to get
>>> a car file into a maven-like repository, and it only uses the
>>> actual maven repository at the moment.  The identity of path inside
>>> the maven repo and configId is currently a convention, but IMO a
>>> really good one.  I'd like to see if a packed-car repository config-
>>> store works, but I doubt I'll have time to try it before 1.0.
>>
>> I think using the maven repo path for the configId is problematic.
>> The layout of the repository will change over time, and is actually
>> completely repository dependent.  We have already seen a change
>> between maven 1 and maven 2.  I would prefer that the ID follow the
>> maven single line notation for an artifact.
>>
>> groupId:artifactId:version:type[:classifier]
>>
>> In this case, we don't need a classifier and we can always assume
>> type is "car", so we will end up with something like:
>>
>> org.apache.geronimo:j2ee-server:1.0
>>
>> which I think is a lot cleaner then the m1 and m2 paths, as doesn't
>> repeat information:
>>
>> org.apache.geronimo./cars/geronimo-j2ee-server-1.0.car
>> org/apache/geronimo/geronimo-j2ee-server/1.0/geronimo-j2ee-
>> server-1.0.car
>>
>> Does that seem reasonable?
>>
>>>> Here are my issues:
>>>>  - It's a pretty significant change for the "last gasp before
>>>> 1.0".  I
>>>> would *really* prefer to hold off on this so we have some time to
>>>> think it through and work with it a bit longer before committing
>>>> to it
>>>> as the future, but I'm afraid that you won't deliver separate
>>>> Jetty/Tomcat builds without it.  What do you think?
>>>
>>> Right, for me this is a requirement for separate jetty/tomcat builds.
>>
>> I think this is one of the things we address now, or defer until
>> Geronimo 2.0, whenever that is.
>>
>>>>  - I want to make sure that application configIds or configIds for
>>>> services created by the user (e.g. database pools, security realms)
>>>> can still be anything at all ("foo") and don't have to follow the
>>>> Maven style naming.  Further, I don't think that not using Maven-
>>>> style
>>>> configIds for your application should limit your capabilities in any
>>>> way (no, "can't deploy to a cluster if you can't use the packaging
>>>> plugin if you didn't use Maven-style configIds" or anything like
>>>> that)
>>>
>>> AFAIK we don't have clustering yet...  there's nothing stopping you
>>> from using whatever badly thought out :-) configIds you want, but I
>>> think we should encourage people to use configIds with systematic
>>> and useful info in them -- i.e. the maven style ones.
>>
>> Well if we want to use maven artifact to manage our repository, we
>> are going to need a groupId, artifactId and a version.  We could
>> simply make groupId and vendorId equal what ever random string the
>> user give us and make the version a time stamp.  I think it would be
>> better if the deployment tool prompted for the groupId and artifactId
>> if there wasn't a geronimo plan in the archive, but it isn't 
>> necessary.
>>
>> -dain
>>
>


Mime
View raw message