You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Vamsavardhana Reddy <c1...@gmail.com> on 2005/11/16 13:10:21 UTC
Constructing deployment plans from Configuration GBeanData
I am trying to reconstruct deployment plan from the Configuration GBeanData.
I have a code segment like the following.
ObjectName configName = Configuration.getConfigurationObjectName(configId);
GBeanData configData = kernel.getGBeanData(configName);
Once I have the GBeanData object, I am retreiving the attributes, references
& any GBeans inside the configuration and printing out the information. With
this procedure, I am able to reconstruct the deployment plan for some, but
not all :(, of the configurations in Geronimo. Is there any other way of
getting deployment plan out of configuration GBeanData object?
Re: Constructing deployment plans from Configuration GBeanData
Posted by Dain Sundstrom <da...@iq80.com>.
How about we do what apple does... When connecting to a protected
wifi node, it won't show you the password unless you ask it to. This
prevents shoulder surfing but if you know your location is safe, you
can actually see what you typed. Also the key chain manager built
into the os allows you to see your stored passwords but you must
provide your paster password first.
Anyway, we could pop up a dialog box reminding the user that the
configuration file may contain sensitive information such as
passwords and do they really want to show it on the screen?
Alternatively, we could ask the user to re-authenticate themselves
before showing any sensitive information, but I'm not sure how you do
this in a web application.
-dain
On Nov 18, 2005, at 9:14 AM, Aaron Mulder wrote:
> On 11/18/05, Dain Sundstrom <da...@iq80.com> wrote:
>> Wait a sec. We are worried about an administrator that has access to
>> the console from seeing a password embedded an a configuration file?
>> The admin can deploy applications, which could easily just scan for
>> passwords in memory or on disk. Anyone with access to this console
>> is "root" for the geronimo instance.
>
> Yeah, that's why I waffle. But for example, if you look at a database
> pool in the console, it uses a password field and doesn't show you the
> plain text. It's not that you can't get around this (via, say, view
> source, if not writing your own code to inspect the GBeans), it's that
> I'm not sure I like flagrantly popping up stuff with passwords right
> there. You know, shoulder-surfing, or whatever.
>
> Erin says some peolpe argue that no security is better than something
> weak that gives you a false sense of security, but I also think
> there's a place for defending against the casual observer.
>
> Forget about the console for a sec. How many people will think to
> make their config store directory non-world-readable? Sure you could
> write some code to deserialize the stuff in there today, but if anyone
> with an account on the box can just view a plain-text plan out of the
> config store with the passwords, that's really "no security". (And
> since every connector has different config params it's not so easy to
> just mask out the password in every file we copy in there, though it
> would be a good start to do it for any config-param where
> name.toLowerCase().indexOf("password") > -1.)
>
> Aaron
Re: Constructing deployment plans from Configuration GBeanData
Posted by Dain Sundstrom <da...@iq80.com>.
On Nov 18, 2005, at 3:03 PM, Aaron Mulder wrote:
> On 11/18/05, Dain Sundstrom <da...@iq80.com> wrote:
>> In 1.1+ we could change the config store to set the file permissions
>> on the directories it creates.
>
> How can you do that from Java?
The same way ant does, you exec some platform program :( Setting
file permissions was supposed to addressed in NIO but I guess they
dropped the ball.
If we decide to add this feature this, I would hope we can simply
reuse the ant library.
-dain
Re: Constructing deployment plans from Configuration GBeanData
Posted by John Sisson <jr...@gmail.com>.
You could look at how ant does it. I am guessing using exec().
http://ant.apache.org/manual/CoreTasks/chmod.html
John
Aaron Mulder wrote:
>On 11/18/05, Dain Sundstrom <da...@iq80.com> wrote:
>
>
>>In 1.1+ we could change the config store to set the file permissions
>>on the directories it creates.
>>
>>
>
>How can you do that from Java?
>
>Aaron
>
>
>
>>On Nov 18, 2005, at 11:05 AM, Kevan Miller wrote:
>>
>>
>>
>>>On 11/18/05, Aaron Mulder <am...@alumni.princeton.edu> wrote:
>>>On 11/18/05, Dain Sundstrom <da...@iq80.com> wrote:
>>>
>>>
>>>>Wait a sec. We are worried about an administrator that has
>>>>
>>>>
>>>access to
>>>
>>>
>>>>the console from seeing a password embedded an a configuration file?
>>>>The admin can deploy applications, which could easily just scan for
>>>>passwords in memory or on disk. Anyone with access to this console
>>>>is "root" for the geronimo instance.
>>>>
>>>>
>>>Yeah, that's why I waffle. But for example, if you look at a database
>>>pool in the console, it uses a password field and doesn't show you the
>>>plain text. It's not that you can't get around this (via, say, view
>>>source, if not writing your own code to inspect the GBeans), it's that
>>>I'm not sure I like flagrantly popping up stuff with passwords right
>>>there. You know, shoulder-surfing, or whatever.
>>>
>>>Erin says some peolpe argue that no security is better than something
>>>weak that gives you a false sense of security, but I also think
>>>there's a place for defending against the casual observer.
>>>
>>>Forget about the console for a sec. How many people will think to
>>>make their config store directory non-world-readable? Sure you could
>>>write some code to deserialize the stuff in there today, but if anyone
>>>with an account on the box can just view a plain-text plan out of the
>>>config store with the passwords, that's really "no security". (And
>>>since every connector has different config params it's not so easy to
>>>just mask out the password in every file we copy in there, though it
>>>would be a good start to do it for any config-param where
>>>name.toLowerCase().indexOf("password") > -1.)
>>>
>>>Aaron
>>>
>>>I think you raise a couple of good points about 1) protecting
>>>config-store directory and 2) masking sensitive configuration data.
>>>I ran into both of these looking at your recent issue
>>>http://issues.apache.org/jira/browse/GERONIMO-1135 (keystore and
>>>passstore passwords are available in System properties).
>>>
>>>BTW, another potential exposure of sensitive data are the admin ids
>>>and passwords stored in a .geronimo-deployer directory by your
>>>recent "login" addition to deployer.
>>>
>>>config-store and .geronimo-deployer are documentation/good practice
>>>issues which shouldn't be too hard to document (but easy to ignore/
>>>miss...). Protecting sensitive data in the runtime seems like a
>>>harder task. Something we can address in V1? Something we must
>>>address in V1? Any other security-related problems?
>>>
>>>
>>-dain
>>
>>
>>
>
>
>
Re: Constructing deployment plans from Configuration GBeanData
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 11/18/05, Dain Sundstrom <da...@iq80.com> wrote:
> In 1.1+ we could change the config store to set the file permissions
> on the directories it creates.
How can you do that from Java?
Aaron
>
> On Nov 18, 2005, at 11:05 AM, Kevan Miller wrote:
>
> > On 11/18/05, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> > On 11/18/05, Dain Sundstrom <da...@iq80.com> wrote:
> > > Wait a sec. We are worried about an administrator that has
> > access to
> > > the console from seeing a password embedded an a configuration file?
> > > The admin can deploy applications, which could easily just scan for
> > > passwords in memory or on disk. Anyone with access to this console
> > > is "root" for the geronimo instance.
> >
> > Yeah, that's why I waffle. But for example, if you look at a database
> > pool in the console, it uses a password field and doesn't show you the
> > plain text. It's not that you can't get around this (via, say, view
> > source, if not writing your own code to inspect the GBeans), it's that
> > I'm not sure I like flagrantly popping up stuff with passwords right
> > there. You know, shoulder-surfing, or whatever.
> >
> > Erin says some peolpe argue that no security is better than something
> > weak that gives you a false sense of security, but I also think
> > there's a place for defending against the casual observer.
> >
> > Forget about the console for a sec. How many people will think to
> > make their config store directory non-world-readable? Sure you could
> > write some code to deserialize the stuff in there today, but if anyone
> > with an account on the box can just view a plain-text plan out of the
> > config store with the passwords, that's really "no security". (And
> > since every connector has different config params it's not so easy to
> > just mask out the password in every file we copy in there, though it
> > would be a good start to do it for any config-param where
> > name.toLowerCase().indexOf("password") > -1.)
> >
> > Aaron
> >
> > I think you raise a couple of good points about 1) protecting
> > config-store directory and 2) masking sensitive configuration data.
> > I ran into both of these looking at your recent issue
> > http://issues.apache.org/jira/browse/GERONIMO-1135 (keystore and
> > passstore passwords are available in System properties).
> >
> > BTW, another potential exposure of sensitive data are the admin ids
> > and passwords stored in a .geronimo-deployer directory by your
> > recent "login" addition to deployer.
> >
> > config-store and .geronimo-deployer are documentation/good practice
> > issues which shouldn't be too hard to document (but easy to ignore/
> > miss...). Protecting sensitive data in the runtime seems like a
> > harder task. Something we can address in V1? Something we must
> > address in V1? Any other security-related problems?
>
>
> -dain
>
Re: Constructing deployment plans from Configuration GBeanData
Posted by Dain Sundstrom <da...@iq80.com>.
On Nov 18, 2005, at 11:05 AM, Kevan Miller wrote:
> On 11/18/05, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> On 11/18/05, Dain Sundstrom <da...@iq80.com> wrote:
> > Wait a sec. We are worried about an administrator that has
> access to
> > the console from seeing a password embedded an a configuration file?
> > The admin can deploy applications, which could easily just scan for
> > passwords in memory or on disk. Anyone with access to this console
> > is "root" for the geronimo instance.
>
> Yeah, that's why I waffle. But for example, if you look at a database
> pool in the console, it uses a password field and doesn't show you the
> plain text. It's not that you can't get around this (via, say, view
> source, if not writing your own code to inspect the GBeans), it's that
> I'm not sure I like flagrantly popping up stuff with passwords right
> there. You know, shoulder-surfing, or whatever.
>
> Erin says some peolpe argue that no security is better than something
> weak that gives you a false sense of security, but I also think
> there's a place for defending against the casual observer.
>
> Forget about the console for a sec. How many people will think to
> make their config store directory non-world-readable? Sure you could
> write some code to deserialize the stuff in there today, but if anyone
> with an account on the box can just view a plain-text plan out of the
> config store with the passwords, that's really "no security". (And
> since every connector has different config params it's not so easy to
> just mask out the password in every file we copy in there, though it
> would be a good start to do it for any config-param where
> name.toLowerCase().indexOf("password") > -1.)
>
> Aaron
>
> I think you raise a couple of good points about 1) protecting
> config-store directory and 2) masking sensitive configuration data.
> I ran into both of these looking at your recent issue
> http://issues.apache.org/jira/browse/GERONIMO-1135 (keystore and
> passstore passwords are available in System properties).
>
> BTW, another potential exposure of sensitive data are the admin ids
> and passwords stored in a .geronimo-deployer directory by your
> recent "login" addition to deployer.
>
> config-store and .geronimo-deployer are documentation/good practice
> issues which shouldn't be too hard to document (but easy to ignore/
> miss...). Protecting sensitive data in the runtime seems like a
> harder task. Something we can address in V1? Something we must
> address in V1? Any other security-related problems?
In 1.1+ we could change the config store to set the file permissions
on the directories it creates.
-dain
Re: Constructing deployment plans from Configuration GBeanData
Posted by Kevan Miller <ke...@gmail.com>.
On 11/18/05, Aaron Mulder <am...@alumni.princeton.edu> wrote:
>
> On 11/18/05, Dain Sundstrom <da...@iq80.com> wrote:
> > Wait a sec. We are worried about an administrator that has access to
> > the console from seeing a password embedded an a configuration file?
> > The admin can deploy applications, which could easily just scan for
> > passwords in memory or on disk. Anyone with access to this console
> > is "root" for the geronimo instance.
>
> Yeah, that's why I waffle. But for example, if you look at a database
> pool in the console, it uses a password field and doesn't show you the
> plain text. It's not that you can't get around this (via, say, view
> source, if not writing your own code to inspect the GBeans), it's that
> I'm not sure I like flagrantly popping up stuff with passwords right
> there. You know, shoulder-surfing, or whatever.
>
> Erin says some peolpe argue that no security is better than something
> weak that gives you a false sense of security, but I also think
> there's a place for defending against the casual observer.
>
> Forget about the console for a sec. How many people will think to
> make their config store directory non-world-readable? Sure you could
> write some code to deserialize the stuff in there today, but if anyone
> with an account on the box can just view a plain-text plan out of the
> config store with the passwords, that's really "no security". (And
> since every connector has different config params it's not so easy to
> just mask out the password in every file we copy in there, though it
> would be a good start to do it for any config-param where
> name.toLowerCase().indexOf("password") > -1.)
>
> Aaron
I think you raise a couple of good points about 1) protecting config-store
directory and 2) masking sensitive configuration data. I ran into both of
these looking at your recent issue
http://issues.apache.org/jira/browse/GERONIMO-1135 (keystore and passstore
passwords are available in System properties).
BTW, another potential exposure of sensitive data are the admin ids and
passwords stored in a .geronimo-deployer directory by your recent "login"
addition to deployer.
config-store and .geronimo-deployer are documentation/good practice issues
which shouldn't be too hard to document (but easy to ignore/miss...).
Protecting sensitive data in the runtime seems like a harder task. Something
we can address in V1? Something we must address in V1? Any other
security-related problems?
--kevan
> On Nov 18, 2005, at 8:57 AM, Dain Sundstrom wrote:
> > > If we are the ones copying over the plans, why not have the
> > > deployment code for the module, simply remove passwords from the
> > > file before copying it. Alternatively, we could choose to not copy
> > > over the plan for connectors.
> > >
> > > -dain
> > >
> > > On Nov 17, 2005, at 11:30 PM, Aaron Mulder wrote:
> > >
> > >> Note that JSR-77 requires us to expose the J2EE DD through our module
> > >> beans, and it may make sense to provide a similar hook for the
> > >> Geronimo plan. That would make it easy to implement nicely in the
> > >> console, certainly.
> > >>
> > >> However, I agree that it's important to be able to suppress showing
> > >> plans, particular for connectors where they're likely to have
> > >> passwords in them. Sure, you only see that if you got into the
> > >> console/MEJB/whatever to begin with, but still... I'm not sure what
> > >> to say about the default behavior. I thought this was such a cool
> > >> idea until I thought about the password issue, but if we make hiding
> > >> the plans the default, then it's not all that useful a feature. I'm
> > >> waffling.
> > >>
> > >> Aaron
> > >>
> > >> On 11/18/05, David Jencks < david_jencks@yahoo.com> wrote:
> > >>>
> > >>> On Nov 17, 2005, at 9:21 PM, Vamsavardhana Reddy wrote:
> > >>>
> > >>>>
> > >>>>
> > >>>> On 11/17/05, David Jencks < david_jencks@yahoo.com> wrote:
> > >>>>> On Nov 17, 2005, at 4:45 AM, Vamsavardhana Reddy wrote:
> > >>>>>
> > >>>>>> If deployment plans are inside the archive (ear, war, etc.)
> > >>>>>> they can
> > >>>>>> be obtained from config-store. If the deployment plan is
> > >>>>>> supplied as
> > >>>>>> an external file to the deployer and if the original file is not
> > >>>>>> available, the only way to get any information on the
> > >>>>>> configuration
> > >>>>> is
> > >>>>>> from the Configuration GBeanData obtained from the kernel at
> > >>>>>> runtime
> > >>>>>> or from deserializing config.ser files under config-store. For
> > >>>>>> analyzing any problems after an application is deployed,
> > >>>>>> deployment
> > >>>>>> plans will certainly be helpful.
> > >>>>>
> > >>>>> If you think this is really valuable information, I think a better
>
> > >>>>> approach is to store the plan(s) in a known location in the
> > >>>>> configuration so they may be retrieved directly.
> > >>>> I thought of this as an option because it will really simplify
> > >>>> a lot
> > >>>> of things, and I can avoid writing a configuration decompiler :o).
> > >>>> But, then will there be any instances where the user will not
> > >>>> want the
> > >>>> deployment plan to be stored in the server as is? Will "not want to
> > >>>> store the deployment plan in the config-store" be ever a users'
> > >>>> reason
> > >>>> for supplying deployment plan as an external file to the deployer?
> > >>>
> > >>> Well, I think there will be few cases where the original deployment
> > >>> plan will be unavailable from other sources, and I don't
> > >>> particularly
> > >>> like including it in the configuration. However, I don't think this
> > >>> has much to do with the desirability of keeping the plan separate
> > >>> from
> > >>> the module you are deploying: I think this is always a good
> > >>> idea. I do
> > >>> think that some people will want to conceal their plan and if we do
> > >>> provide a way to include it in the configuration this choice must be
>
> > >>> optional.
> > >>>
> > >>> thanks
> > >>> david jencks
> > >>>
> > >>>
> >
> >
>
Re: Constructing deployment plans from Configuration GBeanData
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 11/18/05, Dain Sundstrom <da...@iq80.com> wrote:
> Wait a sec. We are worried about an administrator that has access to
> the console from seeing a password embedded an a configuration file?
> The admin can deploy applications, which could easily just scan for
> passwords in memory or on disk. Anyone with access to this console
> is "root" for the geronimo instance.
Yeah, that's why I waffle. But for example, if you look at a database
pool in the console, it uses a password field and doesn't show you the
plain text. It's not that you can't get around this (via, say, view
source, if not writing your own code to inspect the GBeans), it's that
I'm not sure I like flagrantly popping up stuff with passwords right
there. You know, shoulder-surfing, or whatever.
Erin says some peolpe argue that no security is better than something
weak that gives you a false sense of security, but I also think
there's a place for defending against the casual observer.
Forget about the console for a sec. How many people will think to
make their config store directory non-world-readable? Sure you could
write some code to deserialize the stuff in there today, but if anyone
with an account on the box can just view a plain-text plan out of the
config store with the passwords, that's really "no security". (And
since every connector has different config params it's not so easy to
just mask out the password in every file we copy in there, though it
would be a good start to do it for any config-param where
name.toLowerCase().indexOf("password") > -1.)
Aaron
> On Nov 18, 2005, at 8:57 AM, Dain Sundstrom wrote:
> > If we are the ones copying over the plans, why not have the
> > deployment code for the module, simply remove passwords from the
> > file before copying it. Alternatively, we could choose to not copy
> > over the plan for connectors.
> >
> > -dain
> >
> > On Nov 17, 2005, at 11:30 PM, Aaron Mulder wrote:
> >
> >> Note that JSR-77 requires us to expose the J2EE DD through our module
> >> beans, and it may make sense to provide a similar hook for the
> >> Geronimo plan. That would make it easy to implement nicely in the
> >> console, certainly.
> >>
> >> However, I agree that it's important to be able to suppress showing
> >> plans, particular for connectors where they're likely to have
> >> passwords in them. Sure, you only see that if you got into the
> >> console/MEJB/whatever to begin with, but still... I'm not sure what
> >> to say about the default behavior. I thought this was such a cool
> >> idea until I thought about the password issue, but if we make hiding
> >> the plans the default, then it's not all that useful a feature. I'm
> >> waffling.
> >>
> >> Aaron
> >>
> >> On 11/18/05, David Jencks <da...@yahoo.com> wrote:
> >>>
> >>> On Nov 17, 2005, at 9:21 PM, Vamsavardhana Reddy wrote:
> >>>
> >>>>
> >>>>
> >>>> On 11/17/05, David Jencks <da...@yahoo.com> wrote:
> >>>>> On Nov 17, 2005, at 4:45 AM, Vamsavardhana Reddy wrote:
> >>>>>
> >>>>>> If deployment plans are inside the archive (ear, war, etc.)
> >>>>>> they can
> >>>>>> be obtained from config-store. If the deployment plan is
> >>>>>> supplied as
> >>>>>> an external file to the deployer and if the original file is not
> >>>>>> available, the only way to get any information on the
> >>>>>> configuration
> >>>>> is
> >>>>>> from the Configuration GBeanData obtained from the kernel at
> >>>>>> runtime
> >>>>>> or from deserializing config.ser files under config-store. For
> >>>>>> analyzing any problems after an application is deployed,
> >>>>>> deployment
> >>>>>> plans will certainly be helpful.
> >>>>>
> >>>>> If you think this is really valuable information, I think a better
> >>>>> approach is to store the plan(s) in a known location in the
> >>>>> configuration so they may be retrieved directly.
> >>>> I thought of this as an option because it will really simplify
> >>>> a lot
> >>>> of things, and I can avoid writing a configuration decompiler :o).
> >>>> But, then will there be any instances where the user will not
> >>>> want the
> >>>> deployment plan to be stored in the server as is? Will "not want to
> >>>> store the deployment plan in the config-store" be ever a users'
> >>>> reason
> >>>> for supplying deployment plan as an external file to the deployer?
> >>>
> >>> Well, I think there will be few cases where the original deployment
> >>> plan will be unavailable from other sources, and I don't
> >>> particularly
> >>> like including it in the configuration. However, I don't think this
> >>> has much to do with the desirability of keeping the plan separate
> >>> from
> >>> the module you are deploying: I think this is always a good
> >>> idea. I do
> >>> think that some people will want to conceal their plan and if we do
> >>> provide a way to include it in the configuration this choice must be
> >>> optional.
> >>>
> >>> thanks
> >>> david jencks
> >>>
> >>>
>
>
Re: Constructing deployment plans from Configuration GBeanData
Posted by Dain Sundstrom <da...@iq80.com>.
Wait a sec. We are worried about an administrator that has access to
the console from seeing a password embedded an a configuration file?
The admin can deploy applications, which could easily just scan for
passwords in memory or on disk. Anyone with access to this console
is "root" for the geronimo instance.
-dain
On Nov 18, 2005, at 8:57 AM, Dain Sundstrom wrote:
> If we are the ones copying over the plans, why not have the
> deployment code for the module, simply remove passwords from the
> file before copying it. Alternatively, we could choose to not copy
> over the plan for connectors.
>
> -dain
>
> On Nov 17, 2005, at 11:30 PM, Aaron Mulder wrote:
>
>> Note that JSR-77 requires us to expose the J2EE DD through our module
>> beans, and it may make sense to provide a similar hook for the
>> Geronimo plan. That would make it easy to implement nicely in the
>> console, certainly.
>>
>> However, I agree that it's important to be able to suppress showing
>> plans, particular for connectors where they're likely to have
>> passwords in them. Sure, you only see that if you got into the
>> console/MEJB/whatever to begin with, but still... I'm not sure what
>> to say about the default behavior. I thought this was such a cool
>> idea until I thought about the password issue, but if we make hiding
>> the plans the default, then it's not all that useful a feature. I'm
>> waffling.
>>
>> Aaron
>>
>> On 11/18/05, David Jencks <da...@yahoo.com> wrote:
>>>
>>> On Nov 17, 2005, at 9:21 PM, Vamsavardhana Reddy wrote:
>>>
>>>>
>>>>
>>>> On 11/17/05, David Jencks <da...@yahoo.com> wrote:
>>>>> On Nov 17, 2005, at 4:45 AM, Vamsavardhana Reddy wrote:
>>>>>
>>>>>> If deployment plans are inside the archive (ear, war, etc.)
>>>>>> they can
>>>>>> be obtained from config-store. If the deployment plan is
>>>>>> supplied as
>>>>>> an external file to the deployer and if the original file is not
>>>>>> available, the only way to get any information on the
>>>>>> configuration
>>>>> is
>>>>>> from the Configuration GBeanData obtained from the kernel at
>>>>>> runtime
>>>>>> or from deserializing config.ser files under config-store. For
>>>>>> analyzing any problems after an application is deployed,
>>>>>> deployment
>>>>>> plans will certainly be helpful.
>>>>>
>>>>> If you think this is really valuable information, I think a better
>>>>> approach is to store the plan(s) in a known location in the
>>>>> configuration so they may be retrieved directly.
>>>> I thought of this as an option because it will really simplify
>>>> a lot
>>>> of things, and I can avoid writing a configuration decompiler :o).
>>>> But, then will there be any instances where the user will not
>>>> want the
>>>> deployment plan to be stored in the server as is? Will "not want to
>>>> store the deployment plan in the config-store" be ever a users'
>>>> reason
>>>> for supplying deployment plan as an external file to the deployer?
>>>
>>> Well, I think there will be few cases where the original deployment
>>> plan will be unavailable from other sources, and I don't
>>> particularly
>>> like including it in the configuration. However, I don't think this
>>> has much to do with the desirability of keeping the plan separate
>>> from
>>> the module you are deploying: I think this is always a good
>>> idea. I do
>>> think that some people will want to conceal their plan and if we do
>>> provide a way to include it in the configuration this choice must be
>>> optional.
>>>
>>> thanks
>>> david jencks
>>>
>>>
Re: Constructing deployment plans from Configuration GBeanData
Posted by Dain Sundstrom <da...@iq80.com>.
If we are the ones copying over the plans, why not have the
deployment code for the module, simply remove passwords from the file
before copying it. Alternatively, we could choose to not copy over
the plan for connectors.
-dain
On Nov 17, 2005, at 11:30 PM, Aaron Mulder wrote:
> Note that JSR-77 requires us to expose the J2EE DD through our module
> beans, and it may make sense to provide a similar hook for the
> Geronimo plan. That would make it easy to implement nicely in the
> console, certainly.
>
> However, I agree that it's important to be able to suppress showing
> plans, particular for connectors where they're likely to have
> passwords in them. Sure, you only see that if you got into the
> console/MEJB/whatever to begin with, but still... I'm not sure what
> to say about the default behavior. I thought this was such a cool
> idea until I thought about the password issue, but if we make hiding
> the plans the default, then it's not all that useful a feature. I'm
> waffling.
>
> Aaron
>
> On 11/18/05, David Jencks <da...@yahoo.com> wrote:
>>
>> On Nov 17, 2005, at 9:21 PM, Vamsavardhana Reddy wrote:
>>
>>>
>>>
>>> On 11/17/05, David Jencks <da...@yahoo.com> wrote:
>>>> On Nov 17, 2005, at 4:45 AM, Vamsavardhana Reddy wrote:
>>>>
>>>>> If deployment plans are inside the archive (ear, war, etc.)
>>>>> they can
>>>>> be obtained from config-store. If the deployment plan is
>>>>> supplied as
>>>>> an external file to the deployer and if the original file is not
>>>>> available, the only way to get any information on the
>>>>> configuration
>>>> is
>>>>> from the Configuration GBeanData obtained from the kernel at
>>>>> runtime
>>>>> or from deserializing config.ser files under config-store. For
>>>>> analyzing any problems after an application is deployed,
>>>>> deployment
>>>>> plans will certainly be helpful.
>>>>
>>>> If you think this is really valuable information, I think a better
>>>> approach is to store the plan(s) in a known location in the
>>>> configuration so they may be retrieved directly.
>>> I thought of this as an option because it will really simplify a
>>> lot
>>> of things, and I can avoid writing a configuration decompiler :o).
>>> But, then will there be any instances where the user will not
>>> want the
>>> deployment plan to be stored in the server as is? Will "not want to
>>> store the deployment plan in the config-store" be ever a users'
>>> reason
>>> for supplying deployment plan as an external file to the deployer?
>>
>> Well, I think there will be few cases where the original deployment
>> plan will be unavailable from other sources, and I don't particularly
>> like including it in the configuration. However, I don't think this
>> has much to do with the desirability of keeping the plan separate
>> from
>> the module you are deploying: I think this is always a good idea.
>> I do
>> think that some people will want to conceal their plan and if we do
>> provide a way to include it in the configuration this choice must be
>> optional.
>>
>> thanks
>> david jencks
>>
>>
Re: Constructing deployment plans from Configuration GBeanData
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Note that JSR-77 requires us to expose the J2EE DD through our module
beans, and it may make sense to provide a similar hook for the
Geronimo plan. That would make it easy to implement nicely in the
console, certainly.
However, I agree that it's important to be able to suppress showing
plans, particular for connectors where they're likely to have
passwords in them. Sure, you only see that if you got into the
console/MEJB/whatever to begin with, but still... I'm not sure what
to say about the default behavior. I thought this was such a cool
idea until I thought about the password issue, but if we make hiding
the plans the default, then it's not all that useful a feature. I'm
waffling.
Aaron
On 11/18/05, David Jencks <da...@yahoo.com> wrote:
>
> On Nov 17, 2005, at 9:21 PM, Vamsavardhana Reddy wrote:
>
> >
> >
> > On 11/17/05, David Jencks <da...@yahoo.com> wrote:
> >> On Nov 17, 2005, at 4:45 AM, Vamsavardhana Reddy wrote:
> >>
> >> > If deployment plans are inside the archive (ear, war, etc.) they can
> >> > be obtained from config-store. If the deployment plan is supplied as
> >> > an external file to the deployer and if the original file is not
> >> > available, the only way to get any information on the configuration
> >> is
> >> > from the Configuration GBeanData obtained from the kernel at runtime
> >> > or from deserializing config.ser files under config-store. For
> >> > analyzing any problems after an application is deployed, deployment
> >> > plans will certainly be helpful.
> >>
> >> If you think this is really valuable information, I think a better
> >> approach is to store the plan(s) in a known location in the
> >> configuration so they may be retrieved directly.
> > I thought of this as an option because it will really simplify a lot
> > of things, and I can avoid writing a configuration decompiler :o).
> > But, then will there be any instances where the user will not want the
> > deployment plan to be stored in the server as is? Will "not want to
> > store the deployment plan in the config-store" be ever a users' reason
> > for supplying deployment plan as an external file to the deployer?
>
> Well, I think there will be few cases where the original deployment
> plan will be unavailable from other sources, and I don't particularly
> like including it in the configuration. However, I don't think this
> has much to do with the desirability of keeping the plan separate from
> the module you are deploying: I think this is always a good idea. I do
> think that some people will want to conceal their plan and if we do
> provide a way to include it in the configuration this choice must be
> optional.
>
> thanks
> david jencks
>
>
Re: Constructing deployment plans from Configuration GBeanData
Posted by David Jencks <da...@yahoo.com>.
On Nov 17, 2005, at 9:21 PM, Vamsavardhana Reddy wrote:
>
>
> On 11/17/05, David Jencks <da...@yahoo.com> wrote:
>> On Nov 17, 2005, at 4:45 AM, Vamsavardhana Reddy wrote:
>>
>> > If deployment plans are inside the archive (ear, war, etc.) they can
>> > be obtained from config-store. If the deployment plan is supplied as
>> > an external file to the deployer and if the original file is not
>> > available, the only way to get any information on the configuration
>> is
>> > from the Configuration GBeanData obtained from the kernel at runtime
>> > or from deserializing config.ser files under config-store. For
>> > analyzing any problems after an application is deployed, deployment
>> > plans will certainly be helpful.
>>
>> If you think this is really valuable information, I think a better
>> approach is to store the plan(s) in a known location in the
>> configuration so they may be retrieved directly.
> I thought of this as an option because it will really simplify a lot
> of things, and I can avoid writing a configuration decompiler :o).
> But, then will there be any instances where the user will not want the
> deployment plan to be stored in the server as is? Will "not want to
> store the deployment plan in the config-store" be ever a users' reason
> for supplying deployment plan as an external file to the deployer?
Well, I think there will be few cases where the original deployment
plan will be unavailable from other sources, and I don't particularly
like including it in the configuration. However, I don't think this
has much to do with the desirability of keeping the plan separate from
the module you are deploying: I think this is always a good idea. I do
think that some people will want to conceal their plan and if we do
provide a way to include it in the configuration this choice must be
optional.
thanks
david jencks
Re: Constructing deployment plans from Configuration GBeanData
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
On 11/17/05, David Jencks <da...@yahoo.com> wrote:
>
>
> On Nov 17, 2005, at 4:45 AM, Vamsavardhana Reddy wrote:
>
> > If deployment plans are inside the archive (ear, war, etc.) they can
> > be obtained from config-store. If the deployment plan is supplied as
> > an external file to the deployer and if the original file is not
> > available, the only way to get any information on the configuration is
> > from the Configuration GBeanData obtained from the kernel at runtime
> > or from deserializing config.ser files under config-store. For
> > analyzing any problems after an application is deployed, deployment
> > plans will certainly be helpful.
>
> If you think this is really valuable information, I think a better
> approach is to store the plan(s) in a known location in the
> configuration so they may be retrieved directly.
I thought of this as an option because it will really simplify a lot of
things, and I can avoid writing a configuration decompiler :o). But, then
will there be any instances where the user will not want the deployment plan
to be stored in the server as is? Will "not want to store the deployment
plan in the config-store" be ever a users' reason for supplying deployment
plan as an external file to the deployer?
thanks
> david jencks
>
>
Re: Constructing deployment plans from Configuration GBeanData
Posted by Joe Bohn <jo...@earthlink.net>.
I can look into adding that to the console once the plans are persisted.
-Joe
Jeff Genender wrote:
> Go Jacek Go!
>
> Also what would be cool is on the console, that we have another link
> next to the app name called "plan" and we can see the plan in the web
> browser/console.
>
> Jeff
>
> Jacek Laskowski wrote:
>
>> Jeff Genender wrote:
>>
>>> I was think about this too and it would be very helpful...
>>>
>>> What about each plan goes in:
>>>
>>> ./config-store/XXX/plan
>>>
>>> where XXX is the deployment id.
>>
>>
>> +1. I could implement if noone objects and we agree upon it.
>>
>>> Jeff
>>
>>
>> Jacek
>
>
>
--
Joe Bohn
joe.bohn@earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot
lose." -- Jim Elliot
Re: Constructing deployment plans from Configuration GBeanData
Posted by Jeff Genender <jg...@apache.org>.
Go Jacek Go!
Also what would be cool is on the console, that we have another link
next to the app name called "plan" and we can see the plan in the web
browser/console.
Jeff
Jacek Laskowski wrote:
> Jeff Genender wrote:
>> I was think about this too and it would be very helpful...
>>
>> What about each plan goes in:
>>
>> ./config-store/XXX/plan
>>
>> where XXX is the deployment id.
>
> +1. I could implement if noone objects and we agree upon it.
>
>> Jeff
>
> Jacek
Re: Constructing deployment plans from Configuration GBeanData
Posted by Jacek Laskowski <jl...@apache.org>.
Jeff Genender wrote:
> I was think about this too and it would be very helpful...
>
> What about each plan goes in:
>
> ./config-store/XXX/plan
>
> where XXX is the deployment id.
+1. I could implement if noone objects and we agree upon it.
> Jeff
Jacek
Re: Constructing deployment plans from Configuration GBeanData
Posted by Jeff Genender <jg...@apache.org>.
I was think about this too and it would be very helpful...
What about each plan goes in:
./config-store/XXX/plan
where XXX is the deployment id.
Jeff
Aaron Mulder wrote:
> I don't think that would be such a bad idea -- storing the original
> plan in the config-store somewhere.
>
> Aaron
>
> On 11/17/05, David Jencks <da...@yahoo.com> wrote:
>> On Nov 17, 2005, at 4:45 AM, Vamsavardhana Reddy wrote:
>>
>>> If deployment plans are inside the archive (ear, war, etc.) they can
>>> be obtained from config-store. If the deployment plan is supplied as
>>> an external file to the deployer and if the original file is not
>>> available, the only way to get any information on the configuration is
>>> from the Configuration GBeanData obtained from the kernel at runtime
>>> or from deserializing config.ser files under config-store. For
>>> analyzing any problems after an application is deployed, deployment
>>> plans will certainly be helpful.
>> If you think this is really valuable information, I think a better
>> approach is to store the plan(s) in a known location in the
>> configuration so they may be retrieved directly.
>>
>> thanks
>> david jencks
>>
>>
Re: Constructing deployment plans from Configuration GBeanData
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I don't think that would be such a bad idea -- storing the original
plan in the config-store somewhere.
Aaron
On 11/17/05, David Jencks <da...@yahoo.com> wrote:
>
> On Nov 17, 2005, at 4:45 AM, Vamsavardhana Reddy wrote:
>
> > If deployment plans are inside the archive (ear, war, etc.) they can
> > be obtained from config-store. If the deployment plan is supplied as
> > an external file to the deployer and if the original file is not
> > available, the only way to get any information on the configuration is
> > from the Configuration GBeanData obtained from the kernel at runtime
> > or from deserializing config.ser files under config-store. For
> > analyzing any problems after an application is deployed, deployment
> > plans will certainly be helpful.
>
> If you think this is really valuable information, I think a better
> approach is to store the plan(s) in a known location in the
> configuration so they may be retrieved directly.
>
> thanks
> david jencks
>
>
Re: Constructing deployment plans from Configuration GBeanData
Posted by David Jencks <da...@yahoo.com>.
On Nov 17, 2005, at 4:45 AM, Vamsavardhana Reddy wrote:
> If deployment plans are inside the archive (ear, war, etc.) they can
> be obtained from config-store. If the deployment plan is supplied as
> an external file to the deployer and if the original file is not
> available, the only way to get any information on the configuration is
> from the Configuration GBeanData obtained from the kernel at runtime
> or from deserializing config.ser files under config-store. For
> analyzing any problems after an application is deployed, deployment
> plans will certainly be helpful.
If you think this is really valuable information, I think a better
approach is to store the plan(s) in a known location in the
configuration so they may be retrieved directly.
thanks
david jencks
Re: Constructing deployment plans from Configuration GBeanData
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
If deployment plans are inside the archive (ear, war, etc.) they can be
obtained from config-store. If the deployment plan is supplied as an
external file to the deployer and if the original file is not available, the
only way to get any information on the configuration is from the
Configuration GBeanData obtained from the kernel at runtime or from
deserializing config.ser files under config-store. For analyzing any
problems after an application is deployed, deployment plans will certainly
be helpful.
-Vamsi
On 11/16/05, David Jencks <da...@yahoo.com> wrote:
>
>
> On Nov 16, 2005, at 4:10 AM, Vamsavardhana Reddy wrote:
>
> > I am trying to reconstruct deployment plan from the Configuration
> > GBeanData.
>
> umm, why?
>
> >
> > I have a code segment like the following.
> > ObjectName configName =
> > Configuration.getConfigurationObjectName(configId);
> > GBeanData configData = kernel.getGBeanData(configName);
> >
> > Once I have the GBeanData object, I am retreiving the attributes,
> > references & any GBeans inside the configuration and printing out the
> > information. With this procedure, I am able to reconstruct the
> > deployment plan for some, but not all :(, of the configurations in
> > Geronimo. Is there any other way of getting deployment plan out of
> > configuration GBeanData object?
> >
>
> this will probably work for gbeans that came from a configuration
> directly, rather than e.g. an ejb container gbean, and that do not have
> any xml-attributes. I don't think you will succeed in generating a
> gbean configuration for something like an ejb container. Again, what
> is your goal? This is very much akin to writing a java disassembler.
>
> thanks
> david jencks
>
>
Re: Constructing deployment plans from Configuration GBeanData
Posted by David Jencks <da...@yahoo.com>.
On Nov 16, 2005, at 4:10 AM, Vamsavardhana Reddy wrote:
> I am trying to reconstruct deployment plan from the Configuration
> GBeanData.
umm, why?
>
> I have a code segment like the following.
> ObjectName configName =
> Configuration.getConfigurationObjectName(configId);
> GBeanData configData = kernel.getGBeanData(configName);
>
> Once I have the GBeanData object, I am retreiving the attributes,
> references & any GBeans inside the configuration and printing out the
> information. With this procedure, I am able to reconstruct the
> deployment plan for some, but not all :(, of the configurations in
> Geronimo. Is there any other way of getting deployment plan out of
> configuration GBeanData object?
>
this will probably work for gbeans that came from a configuration
directly, rather than e.g. an ejb container gbean, and that do not have
any xml-attributes. I don't think you will succeed in generating a
gbean configuration for something like an ejb container. Again, what
is your goal? This is very much akin to writing a java disassembler.
thanks
david jencks