You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by John Sisson <jr...@gmail.com> on 2006/02/01 06:44:10 UTC
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
Re: XML plan files not included in distributions
Posted by David Jencks <da...@yahoo.com>.
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
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <jg...@apache.org> 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 <jg...@apache.org> 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 <jg...@apache.org> 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 <jr...@gmail.com> 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)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> >>>>> );'
> >>>>>
> >>>>> Apache Geronimo (http://geronimo.apache.org/)
> >>>>>
> >>>>> Castor (http://castor.org/)
>
Re: XML plan files not included in distributions
Posted by Jeff Genender <jg...@apache.org>.
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 <jg...@apache.org> 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 <jg...@apache.org> 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 <jr...@gmail.com> 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)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
>>>>> );'
>>>>>
>>>>> Apache Geronimo (http://geronimo.apache.org/)
>>>>>
>>>>> Castor (http://castor.org/)
Re: XML plan files not included in distributions
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <da...@yahoo.com> 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 <da...@yahoo.com> 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 <br...@gmail.com> 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
Posted by David Jencks <da...@yahoo.com>.
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 <da...@yahoo.com> 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 <br...@gmail.com> 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
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <da...@yahoo.com> 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 <br...@gmail.com> 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
Posted by David Jencks <da...@yahoo.com>.
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 <br...@gmail.com> 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
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 2/1/06, Bruce Snyder <br...@gmail.com> 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
Posted by Bruce Snyder <br...@gmail.com>.
On 2/1/06, Aaron Mulder <am...@alumni.princeton.edu> 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)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache Geronimo (http://geronimo.apache.org/)
Castor (http://castor.org/)
Re: XML plan files not included in distributions
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <jg...@apache.org> 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 <jg...@apache.org> 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 <jr...@gmail.com> 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)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> >>> );'
> >>>
> >>> Apache Geronimo (http://geronimo.apache.org/)
> >>>
> >>> Castor (http://castor.org/)
>
Re: XML plan files not included in distributions
Posted by Jeff Genender <jg...@apache.org>.
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 <jg...@apache.org> 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 <jr...@gmail.com> 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)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
>>> );'
>>>
>>> Apache Geronimo (http://geronimo.apache.org/)
>>>
>>> Castor (http://castor.org/)
Re: XML plan files not included in distributions
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <jg...@apache.org> 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 <jr...@gmail.com> 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)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> > );'
> >
> > Apache Geronimo (http://geronimo.apache.org/)
> >
> > Castor (http://castor.org/)
>
Re: XML plan files not included in distributions
Posted by Jeff Genender <jg...@apache.org>.
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 <jr...@gmail.com> 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)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> Apache Geronimo (http://geronimo.apache.org/)
>
> Castor (http://castor.org/)
Re: XML plan files not included in distributions
Posted by Bruce Snyder <br...@gmail.com>.
On 1/31/06, John Sisson <jr...@gmail.com> 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)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache Geronimo (http://geronimo.apache.org/)
Castor (http://castor.org/)
Re: EJB Server Portlet / OpenEJB Stats
Posted by anita kulshreshtha <a_...@yahoo.com>.
--- Aaron Mulder <am...@alumni.princeton.edu>
wrote:
> I can help you with the portlet side of this; the
> trick is going to be
> getting the statistics out of OpenEJB. Once we
> figure that out, we
> can create an API around it and call that from the
> portlet. The best
> way to go would be to create JSR-77 objects for the
> EJBs, and then
> give them JSR-77 statistics objects.
There was
> recently talk of
> creating JSR-77 wrappers for Tomcat servlets I
> think, so if you can
> look into what was done there, maybe it will
> translate well to
> wrapping EJBs in OpenEJB...
EJB (jsr-77) object should already be there.
Could an EJB expert please confirm (deny) that? G-1293
has patches attached for the Stats part. You can use
that as a starting point.
Thnaks
Anita
>
> Thanks,
> Aaron
>
> On 2/1/06, Chris Cardona <ja...@yahoo.com>
> wrote:
> > Hi All,
> >
> > I'm interested on creating an EJB Server Portlet
> to
> > show some statistics (e.g. bean count of the
> different
> > bean types) about the EJB Server/Container and if
> > possible allow a user to make some basic
> configuration
> > changes. I'm not sure if this is currently
> supported
> > by Geronimo. Any help, tips, or info where to
> start
> > looking will be very helpful.
> >
> > Thanks,
> > Chris
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam
> protection around
> > http://mail.yahoo.com
> >
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: EJB Server Portlet / OpenEJB Stats
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I can help you with the portlet side of this; the trick is going to be
getting the statistics out of OpenEJB. Once we figure that out, we
can create an API around it and call that from the portlet. The best
way to go would be to create JSR-77 objects for the EJBs, and then
give them JSR-77 statistics objects. There was recently talk of
creating JSR-77 wrappers for Tomcat servlets I think, so if you can
look into what was done there, maybe it will translate well to
wrapping EJBs in OpenEJB...
Thanks,
Aaron
On 2/1/06, Chris Cardona <ja...@yahoo.com> wrote:
> Hi All,
>
> I'm interested on creating an EJB Server Portlet to
> show some statistics (e.g. bean count of the different
> bean types) about the EJB Server/Container and if
> possible allow a user to make some basic configuration
> changes. I'm not sure if this is currently supported
> by Geronimo. Any help, tips, or info where to start
> looking will be very helpful.
>
> Thanks,
> Chris
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
EJB Server Portlet / OpenEJB Stats
Posted by Chris Cardona <ja...@yahoo.com>.
Hi All,
Im interested on creating an EJB Server Portlet to
show some statistics (e.g. bean count of the different
bean types) about the EJB Server/Container and if
possible allow a user to make some basic configuration
changes. Im not sure if this is currently supported
by Geronimo. Any help, tips, or info where to start
looking will be very helpful.
Thanks,
Chris
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com