Re: XML plan files not included in distributions
I wouldn't really say it's "just for that". The service modules are effectively modules, and I lean toward eexposing them in the same way as any other module. If we had Spring or ServiceMix modules or whatever I'd think we should expose those in the same way. Thanks, Aaron On 2/2/06, David Jencks <[EMAIL PROTECTED]> wrote: > We don't have a ServiceModule gbean, and I don't think it makes a lot > of sense to install one for the sole purpose of exposing the plan. > That was kind of my point. We could obviously do it but it seems > flaky to me. > > thanks > david jencks > > > > > Thanks, > > Aaron > > > > On 2/1/06, David Jencks <[EMAIL PROTECTED]> wrote: > >> Remember that all the plans are currently called "plan.xml" I think > >> the only plausible solution for now is to have the packaging plugin > >> copy the plan into META-INF/plan.xml in the car file. This won't > >> catch embedded j2ee plans, but they will probably get copied in while > >> unpacking the j2ee artifact. > >> > >> As for exposing the plans in a jsr-77 friendly way, what gbean would > >> expose the plan for a non-j2ee service configuration that has only > >> gbeans in it? > >> > >> thanks > >> david jencks > >> > >> On Feb 1, 2006, at 8:22 AM, Aaron Mulder wrote: > >> > >>> On 2/1/06, Bruce Snyder <[EMAIL PROTECTED]> wrote: > IMO, it's a problem that constucting a plan from the running > configurations is so difficult. I'm not sure exactly if this is an > issue with the builders or with the GBean architecture or both. > But I > wonder if use of the XBean kernel would facilitate this > functionality? > I have spoken with Dain about this very functionality but I can't > recall where our conversation ended. > >>> > >>> Well, take a web or EJB plan. It may include next to nothing. > >>> However, if there are a lot of servlets or session beans or > >>> whatever, > >>> there could be loads of GBeans generated. So if you look at this > >>> set > >>> of 57 GBeans, it's hard to reduce that to the minimalist possible > >>> deployment plan. > >>> > >>> For server plans, many GBeans have complex configuration settings > >>> that > >>> should be easier to reverse out with XBean than with the current > >>> kernel. But even then, a set of 10 security-related beans could be > >>> represented as an ugly plan with 10 GBean entries or a nice plan > >>> with > >>> 1 GBean including a nested XML configuration block. Which do you > >>> produce? How do you tell when the complexity of the raw GBeans > >>> exceeds what can be represented by the pretty-looking nested XML > >>> block? Do we insist that every XML "configurer" also includes a > >>> "deconfigurer" that accepts an arbitrary set of GBeans (or just a > >>> Kernel) and backs out what the XML plan should be? I don't like > >>> that, > >>> but I also don't like always returning the "big ugly format" instead > >>> of the nice XML format. > >>> > As for including the default plans in the binary, I say put them in > the docs dir. I don't think I want to require that the deployer be > used to extract a plan and I certainly don't want to advise > users to > monkey around in the config-store. Why make access to the plans any > more difficult than opening them from the docs directory in a text > editor? > >>> > >>> Because it's easier to automate. If we save the plans in the config > >>> store during deployment, it's 100% guaranteed that they'll be there, > >>> even if we forget to run some particular step while preparing a > >>> release. Also, once they're in there, we can potentially add an > >>> "extract plan" operation to the Maven deployment plugin, which means > >>> we can have our assembly script automatically pull them out into the > >>> docs dir if you feel strongly. > >>> > >>> Aaron > >> > >> > >
Re: XML plan files not included in distributions
On Feb 2, 2006, at 5:48 AM, Aaron Mulder wrote: I need to check the spec, but isn't it the Module GBean that exposes the deployment descriptor? I'm assuming we'd extend that with our method to get the Geronimo deployment plan. We could (if we don't already) expose a ServiceModule or something for the non-J2EE configurations. Other than not having a J2EE DD, I think a service module behaves pretty similarly to a J2EE module... We don't have a ServiceModule gbean, and I don't think it makes a lot of sense to install one for the sole purpose of exposing the plan. That was kind of my point. We could obviously do it but it seems flaky to me. thanks david jencks Thanks, Aaron On 2/1/06, David Jencks <[EMAIL PROTECTED]> wrote: Remember that all the plans are currently called "plan.xml" I think the only plausible solution for now is to have the packaging plugin copy the plan into META-INF/plan.xml in the car file. This won't catch embedded j2ee plans, but they will probably get copied in while unpacking the j2ee artifact. As for exposing the plans in a jsr-77 friendly way, what gbean would expose the plan for a non-j2ee service configuration that has only gbeans in it? thanks david jencks On Feb 1, 2006, at 8:22 AM, Aaron Mulder wrote: On 2/1/06, Bruce Snyder <[EMAIL PROTECTED]> wrote: IMO, it's a problem that constucting a plan from the running configurations is so difficult. I'm not sure exactly if this is an issue with the builders or with the GBean architecture or both. But I wonder if use of the XBean kernel would facilitate this functionality? I have spoken with Dain about this very functionality but I can't recall where our conversation ended. Well, take a web or EJB plan. It may include next to nothing. However, if there are a lot of servlets or session beans or whatever, there could be loads of GBeans generated. So if you look at this set of 57 GBeans, it's hard to reduce that to the minimalist possible deployment plan. For server plans, many GBeans have complex configuration settings that should be easier to reverse out with XBean than with the current kernel. But even then, a set of 10 security-related beans could be represented as an ugly plan with 10 GBean entries or a nice plan with 1 GBean including a nested XML configuration block. Which do you produce? How do you tell when the complexity of the raw GBeans exceeds what can be represented by the pretty-looking nested XML block? Do we insist that every XML "configurer" also includes a "deconfigurer" that accepts an arbitrary set of GBeans (or just a Kernel) and backs out what the XML plan should be? I don't like that, but I also don't like always returning the "big ugly format" instead of the nice XML format. As for including the default plans in the binary, I say put them in the docs dir. I don't think I want to require that the deployer be used to extract a plan and I certainly don't want to advise users to monkey around in the config-store. Why make access to the plans any more difficult than opening them from the docs directory in a text editor? Because it's easier to automate. If we save the plans in the config store during deployment, it's 100% guaranteed that they'll be there, even if we forget to run some particular step while preparing a release. Also, once they're in there, we can potentially add an "extract plan" operation to the Maven deployment plugin, which means we can have our assembly script automatically pull them out into the docs dir if you feel strongly. Aaron
Re: XML plan files not included in distributions
I need to check the spec, but isn't it the Module GBean that exposes the deployment descriptor? I'm assuming we'd extend that with our method to get the Geronimo deployment plan. We could (if we don't already) expose a ServiceModule or something for the non-J2EE configurations. Other than not having a J2EE DD, I think a service module behaves pretty similarly to a J2EE module... Thanks, Aaron On 2/1/06, David Jencks <[EMAIL PROTECTED]> wrote: > Remember that all the plans are currently called "plan.xml" I think > the only plausible solution for now is to have the packaging plugin > copy the plan into META-INF/plan.xml in the car file. This won't > catch embedded j2ee plans, but they will probably get copied in while > unpacking the j2ee artifact. > > As for exposing the plans in a jsr-77 friendly way, what gbean would > expose the plan for a non-j2ee service configuration that has only > gbeans in it? > > thanks > david jencks > > On Feb 1, 2006, at 8:22 AM, Aaron Mulder wrote: > > > On 2/1/06, Bruce Snyder <[EMAIL PROTECTED]> wrote: > >> IMO, it's a problem that constucting a plan from the running > >> configurations is so difficult. I'm not sure exactly if this is an > >> issue with the builders or with the GBean architecture or both. But I > >> wonder if use of the XBean kernel would facilitate this > >> functionality? > >> I have spoken with Dain about this very functionality but I can't > >> recall where our conversation ended. > > > > Well, take a web or EJB plan. It may include next to nothing. > > However, if there are a lot of servlets or session beans or whatever, > > there could be loads of GBeans generated. So if you look at this set > > of 57 GBeans, it's hard to reduce that to the minimalist possible > > deployment plan. > > > > For server plans, many GBeans have complex configuration settings that > > should be easier to reverse out with XBean than with the current > > kernel. But even then, a set of 10 security-related beans could be > > represented as an ugly plan with 10 GBean entries or a nice plan with > > 1 GBean including a nested XML configuration block. Which do you > > produce? How do you tell when the complexity of the raw GBeans > > exceeds what can be represented by the pretty-looking nested XML > > block? Do we insist that every XML "configurer" also includes a > > "deconfigurer" that accepts an arbitrary set of GBeans (or just a > > Kernel) and backs out what the XML plan should be? I don't like that, > > but I also don't like always returning the "big ugly format" instead > > of the nice XML format. > > > >> As for including the default plans in the binary, I say put them in > >> the docs dir. I don't think I want to require that the deployer be > >> used to extract a plan and I certainly don't want to advise users to > >> monkey around in the config-store. Why make access to the plans any > >> more difficult than opening them from the docs directory in a text > >> editor? > > > > Because it's easier to automate. If we save the plans in the config > > store during deployment, it's 100% guaranteed that they'll be there, > > even if we forget to run some particular step while preparing a > > release. Also, once they're in there, we can potentially add an > > "extract plan" operation to the Maven deployment plugin, which means > > we can have our assembly script automatically pull them out into the > > docs dir if you feel strongly. > > > > Aaron > >
Re: XML plan files not included in distributions
Remember that all the plans are currently called "plan.xml" I think the only plausible solution for now is to have the packaging plugin copy the plan into META-INF/plan.xml in the car file. This won't catch embedded j2ee plans, but they will probably get copied in while unpacking the j2ee artifact. As for exposing the plans in a jsr-77 friendly way, what gbean would expose the plan for a non-j2ee service configuration that has only gbeans in it? thanks david jencks On Feb 1, 2006, at 8:22 AM, Aaron Mulder wrote: On 2/1/06, Bruce Snyder <[EMAIL PROTECTED]> wrote: IMO, it's a problem that constucting a plan from the running configurations is so difficult. I'm not sure exactly if this is an issue with the builders or with the GBean architecture or both. But I wonder if use of the XBean kernel would facilitate this functionality? I have spoken with Dain about this very functionality but I can't recall where our conversation ended. Well, take a web or EJB plan. It may include next to nothing. However, if there are a lot of servlets or session beans or whatever, there could be loads of GBeans generated. So if you look at this set of 57 GBeans, it's hard to reduce that to the minimalist possible deployment plan. For server plans, many GBeans have complex configuration settings that should be easier to reverse out with XBean than with the current kernel. But even then, a set of 10 security-related beans could be represented as an ugly plan with 10 GBean entries or a nice plan with 1 GBean including a nested XML configuration block. Which do you produce? How do you tell when the complexity of the raw GBeans exceeds what can be represented by the pretty-looking nested XML block? Do we insist that every XML "configurer" also includes a "deconfigurer" that accepts an arbitrary set of GBeans (or just a Kernel) and backs out what the XML plan should be? I don't like that, but I also don't like always returning the "big ugly format" instead of the nice XML format. As for including the default plans in the binary, I say put them in the docs dir. I don't think I want to require that the deployer be used to extract a plan and I certainly don't want to advise users to monkey around in the config-store. Why make access to the plans any more difficult than opening them from the docs directory in a text editor? Because it's easier to automate. If we save the plans in the config store during deployment, it's 100% guaranteed that they'll be there, even if we forget to run some particular step while preparing a release. Also, once they're in there, we can potentially add an "extract plan" operation to the Maven deployment plugin, which means we can have our assembly script automatically pull them out into the docs dir if you feel strongly. Aaron
Re: XML plan files not included in distributions
On 2/1/06, Bruce Snyder <[EMAIL PROTECTED]> wrote: > IMO, it's a problem that constucting a plan from the running > configurations is so difficult. I'm not sure exactly if this is an > issue with the builders or with the GBean architecture or both. But I > wonder if use of the XBean kernel would facilitate this functionality? > I have spoken with Dain about this very functionality but I can't > recall where our conversation ended. Well, take a web or EJB plan. It may include next to nothing. However, if there are a lot of servlets or session beans or whatever, there could be loads of GBeans generated. So if you look at this set of 57 GBeans, it's hard to reduce that to the minimalist possible deployment plan. For server plans, many GBeans have complex configuration settings that should be easier to reverse out with XBean than with the current kernel. But even then, a set of 10 security-related beans could be represented as an ugly plan with 10 GBean entries or a nice plan with 1 GBean including a nested XML configuration block. Which do you produce? How do you tell when the complexity of the raw GBeans exceeds what can be represented by the pretty-looking nested XML block? Do we insist that every XML "configurer" also includes a "deconfigurer" that accepts an arbitrary set of GBeans (or just a Kernel) and backs out what the XML plan should be? I don't like that, but I also don't like always returning the "big ugly format" instead of the nice XML format. > As for including the default plans in the binary, I say put them in > the docs dir. I don't think I want to require that the deployer be > used to extract a plan and I certainly don't want to advise users to > monkey around in the config-store. Why make access to the plans any > more difficult than opening them from the docs directory in a text > editor? Because it's easier to automate. If we save the plans in the config store during deployment, it's 100% guaranteed that they'll be there, even if we forget to run some particular step while preparing a release. Also, once they're in there, we can potentially add an "extract plan" operation to the Maven deployment plugin, which means we can have our assembly script automatically pull them out into the docs dir if you feel strongly. Aaron
Re: XML plan files not included in distributions
On 2/1/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:
> Well, I wasn't going to go that far. Generally speaking, we can't
> easily reconstruct a plan from a set of GBeans (particularly for plans
> that use abbreviated XML syntax like for CSS/TSS or login modules).
> I'd prefer to start with "retrieve original deployment plan" and get
> that in there, and then if we want to we can think about stuff like
> you're describing. (After all, any plan we provided in docs/ wouldn't
> match the current state of the configuration either...)
IMO, it's a problem that constucting a plan from the running
configurations is so difficult. I'm not sure exactly if this is an
issue with the builders or with the GBean architecture or both. But I
wonder if use of the XBean kernel would facilitate this functionality?
I have spoken with Dain about this very functionality but I can't
recall where our conversation ended.
As for including the default plans in the binary, I say put them in
the docs dir. I don't think I want to require that the deployer be
used to extract a plan and I certainly don't want to advise users to
monkey around in the config-store. Why make access to the plans any
more difficult than opening them from the docs directory in a text
editor?
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)
Castor (http://castor.org/)
Re: XML plan files not included in distributions
Sure, I'm fine with a disclaimer. :) I think the JSR-77 method to
get the plan may be a little generic, but then we can have a "dump
config" tool that will spit out XML to the command line or to a file
or whatever and that one would give you a little warning when you
invoke it. It might also be possible to flag when the configurations
were modified so we could tell if the plan was accurate (modified =
deployed then accurate, modified > deployed then not accurate).
Thanks,
Aaron
On 2/1/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
> I know its not easy, but its something I think is important to have at
> some point. It would be nice to know the current state of Geronimo and
> have it spit out the configuration or be able to view it. There are
> many areas where this would be very useful. So maybe one day? ;-)
>
> My .02, I would be careful to include the current plans in the
> config.store or through the console without some sort of disclaimer that
> says they are the original plans and are not the current state. What do
> you think?
>
> Jeff
>
> Aaron Mulder wrote:
> > Well, I wasn't going to go that far. Generally speaking, we can't
> > easily reconstruct a plan from a set of GBeans (particularly for plans
> > that use abbreviated XML syntax like for CSS/TSS or login modules).
> > I'd prefer to start with "retrieve original deployment plan" and get
> > that in there, and then if we want to we can think about stuff like
> > you're describing. (After all, any plan we provided in docs/ wouldn't
> > match the current state of the configuration either...)
> >
> > Thanks,
> > Aaron
> >
> > On 2/1/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
> >> Aaron, yes...that is a great idea.
> >>
> >> But then I think we get into opening up the can of worms about the plan
> >> files in the config.store matching what is actually running in Geronimo.
> >> It would be great to have something that can "rebuild" a plan from the
> >> running configuration, so you can see an accurate snapshot. I would
> >> love to jump on this, but my plate is really full right now...
> >>
> >> Any takers? Otherwise I may be able to get to it in a couple of weeks.
> >>
> >> In the mean time, would anyone mind if we did bundle the plan files
> >> somewhere in G for reference?
> >>
> >> Jeff
> >>
> >> Aaron Mulder wrote:
> >>> Though personally, I think I'd rather store them in the config store
> >>> and have an easy routine to get them out of there (using a JSR-77 call
> >>> like the one that gets the J2EE deployment descriptor)... Some day, I
> >>> guess.
> >>>
> >>> Thanks,
> >>> Aaron
> >>>
> >>> On 2/1/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
> Yes, I would really like to see the original plans in the doc for
> reference. I think it will be helpful and good reference for those
> people who need to override Gbeans in the config.xml.
>
> Jeff
>
> Bruce Snyder wrote:
> > On 1/31/06, John Sisson <[EMAIL PROTECTED]> wrote:
> >> Is there a reason why we no longer ship the XML plan files in the
> >> distributions? In the M5 release (when we were using modules/assembly)
> >> we included them in the geronimo\doc\plan directory.
> >>
> >> I haven't been able to find a JIRA for this, but seem to remember
> >> someone discussing it recently.
> > I just discovered this the other day and as far as I can tell, it was
> > just not considered before shipping 1.0. Call it an oversight. But
> > there's no time like the present for fixing it.
> >
> > Bruce
> > --
> > perl -e 'print unpack("u30","D0G)[EMAIL
> > PROTECTED]&5R\"F)R=6-E+G-N>61E > );'
> >
> > Apache Geronimo (http://geronimo.apache.org/)
> >
> > Castor (http://castor.org/)
>
Re: XML plan files not included in distributions
I know its not easy, but its something I think is important to have at
some point. It would be nice to know the current state of Geronimo and
have it spit out the configuration or be able to view it. There are
many areas where this would be very useful. So maybe one day? ;-)
My .02, I would be careful to include the current plans in the
config.store or through the console without some sort of disclaimer that
says they are the original plans and are not the current state. What do
you think?
Jeff
Aaron Mulder wrote:
> Well, I wasn't going to go that far. Generally speaking, we can't
> easily reconstruct a plan from a set of GBeans (particularly for plans
> that use abbreviated XML syntax like for CSS/TSS or login modules).
> I'd prefer to start with "retrieve original deployment plan" and get
> that in there, and then if we want to we can think about stuff like
> you're describing. (After all, any plan we provided in docs/ wouldn't
> match the current state of the configuration either...)
>
> Thanks,
> Aaron
>
> On 2/1/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
>> Aaron, yes...that is a great idea.
>>
>> But then I think we get into opening up the can of worms about the plan
>> files in the config.store matching what is actually running in Geronimo.
>> It would be great to have something that can "rebuild" a plan from the
>> running configuration, so you can see an accurate snapshot. I would
>> love to jump on this, but my plate is really full right now...
>>
>> Any takers? Otherwise I may be able to get to it in a couple of weeks.
>>
>> In the mean time, would anyone mind if we did bundle the plan files
>> somewhere in G for reference?
>>
>> Jeff
>>
>> Aaron Mulder wrote:
>>> Though personally, I think I'd rather store them in the config store
>>> and have an easy routine to get them out of there (using a JSR-77 call
>>> like the one that gets the J2EE deployment descriptor)... Some day, I
>>> guess.
>>>
>>> Thanks,
>>> Aaron
>>>
>>> On 2/1/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
Yes, I would really like to see the original plans in the doc for
reference. I think it will be helpful and good reference for those
people who need to override Gbeans in the config.xml.
Jeff
Bruce Snyder wrote:
> On 1/31/06, John Sisson <[EMAIL PROTECTED]> wrote:
>> Is there a reason why we no longer ship the XML plan files in the
>> distributions? In the M5 release (when we were using modules/assembly)
>> we included them in the geronimo\doc\plan directory.
>>
>> I haven't been able to find a JIRA for this, but seem to remember
>> someone discussing it recently.
> I just discovered this the other day and as far as I can tell, it was
> just not considered before shipping 1.0. Call it an oversight. But
> there's no time like the present for fixing it.
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)[EMAIL
> PROTECTED]&5R\"F)R=6-E+G-N>61E );'
>
> Apache Geronimo (http://geronimo.apache.org/)
>
> Castor (http://castor.org/)
Re: XML plan files not included in distributions
Well, I wasn't going to go that far. Generally speaking, we can't
easily reconstruct a plan from a set of GBeans (particularly for plans
that use abbreviated XML syntax like for CSS/TSS or login modules).
I'd prefer to start with "retrieve original deployment plan" and get
that in there, and then if we want to we can think about stuff like
you're describing. (After all, any plan we provided in docs/ wouldn't
match the current state of the configuration either...)
Thanks,
Aaron
On 2/1/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
> Aaron, yes...that is a great idea.
>
> But then I think we get into opening up the can of worms about the plan
> files in the config.store matching what is actually running in Geronimo.
> It would be great to have something that can "rebuild" a plan from the
> running configuration, so you can see an accurate snapshot. I would
> love to jump on this, but my plate is really full right now...
>
> Any takers? Otherwise I may be able to get to it in a couple of weeks.
>
> In the mean time, would anyone mind if we did bundle the plan files
> somewhere in G for reference?
>
> Jeff
>
> Aaron Mulder wrote:
> > Though personally, I think I'd rather store them in the config store
> > and have an easy routine to get them out of there (using a JSR-77 call
> > like the one that gets the J2EE deployment descriptor)... Some day, I
> > guess.
> >
> > Thanks,
> > Aaron
> >
> > On 2/1/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
> >> Yes, I would really like to see the original plans in the doc for
> >> reference. I think it will be helpful and good reference for those
> >> people who need to override Gbeans in the config.xml.
> >>
> >> Jeff
> >>
> >> Bruce Snyder wrote:
> >>> On 1/31/06, John Sisson <[EMAIL PROTECTED]> wrote:
> Is there a reason why we no longer ship the XML plan files in the
> distributions? In the M5 release (when we were using modules/assembly)
> we included them in the geronimo\doc\plan directory.
>
> I haven't been able to find a JIRA for this, but seem to remember
> someone discussing it recently.
> >>> I just discovered this the other day and as far as I can tell, it was
> >>> just not considered before shipping 1.0. Call it an oversight. But
> >>> there's no time like the present for fixing it.
> >>>
> >>> Bruce
> >>> --
> >>> perl -e 'print unpack("u30","D0G)[EMAIL
> >>> PROTECTED]&5R\"F)R=6-E+G-N>61E >>> );'
> >>>
> >>> Apache Geronimo (http://geronimo.apache.org/)
> >>>
> >>> Castor (http://castor.org/)
>
Re: XML plan files not included in distributions
Aaron, yes...that is a great idea.
But then I think we get into opening up the can of worms about the plan
files in the config.store matching what is actually running in Geronimo.
It would be great to have something that can "rebuild" a plan from the
running configuration, so you can see an accurate snapshot. I would
love to jump on this, but my plate is really full right now...
Any takers? Otherwise I may be able to get to it in a couple of weeks.
In the mean time, would anyone mind if we did bundle the plan files
somewhere in G for reference?
Jeff
Aaron Mulder wrote:
> Though personally, I think I'd rather store them in the config store
> and have an easy routine to get them out of there (using a JSR-77 call
> like the one that gets the J2EE deployment descriptor)... Some day, I
> guess.
>
> Thanks,
> Aaron
>
> On 2/1/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
>> Yes, I would really like to see the original plans in the doc for
>> reference. I think it will be helpful and good reference for those
>> people who need to override Gbeans in the config.xml.
>>
>> Jeff
>>
>> Bruce Snyder wrote:
>>> On 1/31/06, John Sisson <[EMAIL PROTECTED]> wrote:
Is there a reason why we no longer ship the XML plan files in the
distributions? In the M5 release (when we were using modules/assembly)
we included them in the geronimo\doc\plan directory.
I haven't been able to find a JIRA for this, but seem to remember
someone discussing it recently.
>>> I just discovered this the other day and as far as I can tell, it was
>>> just not considered before shipping 1.0. Call it an oversight. But
>>> there's no time like the present for fixing it.
>>>
>>> Bruce
>>> --
>>> perl -e 'print unpack("u30","D0G)[EMAIL
>>> PROTECTED]&5R\"F)R=6-E+G-N>61E>> );'
>>>
>>> Apache Geronimo (http://geronimo.apache.org/)
>>>
>>> Castor (http://castor.org/)
Re: XML plan files not included in distributions
Though personally, I think I'd rather store them in the config store
and have an easy routine to get them out of there (using a JSR-77 call
like the one that gets the J2EE deployment descriptor)... Some day, I
guess.
Thanks,
Aaron
On 2/1/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
> Yes, I would really like to see the original plans in the doc for
> reference. I think it will be helpful and good reference for those
> people who need to override Gbeans in the config.xml.
>
> Jeff
>
> Bruce Snyder wrote:
> > On 1/31/06, John Sisson <[EMAIL PROTECTED]> wrote:
> >> Is there a reason why we no longer ship the XML plan files in the
> >> distributions? In the M5 release (when we were using modules/assembly)
> >> we included them in the geronimo\doc\plan directory.
> >>
> >> I haven't been able to find a JIRA for this, but seem to remember
> >> someone discussing it recently.
> >
> > I just discovered this the other day and as far as I can tell, it was
> > just not considered before shipping 1.0. Call it an oversight. But
> > there's no time like the present for fixing it.
> >
> > Bruce
> > --
> > perl -e 'print unpack("u30","D0G)[EMAIL
> > PROTECTED]&5R\"F)R=6-E+G-N>61E > );'
> >
> > Apache Geronimo (http://geronimo.apache.org/)
> >
> > Castor (http://castor.org/)
>
Re: XML plan files not included in distributions
Yes, I would really like to see the original plans in the doc for
reference. I think it will be helpful and good reference for those
people who need to override Gbeans in the config.xml.
Jeff
Bruce Snyder wrote:
> On 1/31/06, John Sisson <[EMAIL PROTECTED]> wrote:
>> Is there a reason why we no longer ship the XML plan files in the
>> distributions? In the M5 release (when we were using modules/assembly)
>> we included them in the geronimo\doc\plan directory.
>>
>> I haven't been able to find a JIRA for this, but seem to remember
>> someone discussing it recently.
>
> I just discovered this the other day and as far as I can tell, it was
> just not considered before shipping 1.0. Call it an oversight. But
> there's no time like the present for fixing it.
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)[EMAIL
> PROTECTED]&5R\"F)R=6-E+G-N>61E );'
>
> Apache Geronimo (http://geronimo.apache.org/)
>
> Castor (http://castor.org/)
Re: XML plan files not included in distributions
On Jan 31, 2006, at 9:44 PM, John Sisson wrote: Is there a reason why we no longer ship the XML plan files in the distributions? In the M5 release (when we were using modules/ assembly) we included them in the geronimo\doc\plan directory. I haven't been able to find a JIRA for this, but seem to remember someone discussing it recently. It was a combination of an oversight and the idea that being able to add gbeans using config.xml could replace the need to modify and redeploy the plans we supply. I think that we should distribute them with the servers. david jencks John
Re: XML plan files not included in distributions
On 1/31/06, John Sisson <[EMAIL PROTECTED]> wrote:
> Is there a reason why we no longer ship the XML plan files in the
> distributions? In the M5 release (when we were using modules/assembly)
> we included them in the geronimo\doc\plan directory.
>
> I haven't been able to find a JIRA for this, but seem to remember
> someone discussing it recently.
I just discovered this the other day and as far as I can tell, it was
just not considered before shipping 1.0. Call it an oversight. But
there's no time like the present for fixing it.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)
Castor (http://castor.org/)
XML plan files not included in distributions
Is there a reason why we no longer ship the XML plan files in the distributions? In the M5 release (when we were using modules/assembly) we included them in the geronimo\doc\plan directory. I haven't been able to find a JIRA for this, but seem to remember someone discussing it recently. John
