You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@gmail.com> on 2012/02/16 14:49:40 UTC
Note on adding properties
Just a reminder that when adding flags and properties into code, to use the SystemInstance Options to check for those properties.
Specifically, calls like the following should be avoided.
- Boolean.getBoolean("foo")
- System.getProperty("foo")
If someone were to attempt to use the above in an embedded scenario like so, they would be ignored:
Properties p = new Properties();
p.setProperty("foo", "the value");
EJBContainer.createEJBContainer(p);
Same if those were passed into an InitialContext or specified via a jndi.properties file.
The nice thing about placing properties in these areas is they only last temporarily. If you run a test like this:
Properties p = new Properties();
p.setProperty("foo", "the value");
EJBContainer.createEJBContainer(p);
Then this:
Properties p = new Properties();
EJBContainer.createEJBContainer(p);
The "foo" property of the previous test does not persist to the next test and change the behavior in unwanted ways. So the SystemInstance effectively allows us to create and destroy the container several times in a VM without any "bleeding" of static state.
In that spirit, ideally we'd not store properties obtained through SystemInstance Options as static variables. Not sure how good we've been in that regard in the past. Probably something we should evaluate.
Also note, you can check for properties at an application, module or ejb level. There are only a couple places where we use that so far, but certainly something it would be nice to see used more.
Another interesting feature of the Options class is that it will log the property and value. Debug is used if the default value is chosen. Info level is used if the user changed the default. So it makes it easier for users to know if we are in fact "seeing" the property. Nice because it's really easy to misspell property names and spend a couple hours pulling your hair out.
-David
Re: Note on adding properties
Posted by Romain Manni-Bucau <rm...@gmail.com>.
ok
- Romain
2012/2/16 David Blevins <da...@gmail.com>
>
> On Feb 16, 2012, at 6:07 AM, Romain Manni-Bucau wrote:
>
> > couldn't we simply add syst prop to th ejb container before adding the
> map?
> >
> > it is what we do for other container styles
>
> That's exactly what ends up happening. We just need to make sure that on
> our end we check the properties in SytemInstance rather than
> java.lang.System so we can see all sources of properties.
>
> -David
>
> >
> > 2012/2/16 David Blevins <da...@gmail.com>
> >
> >> Just a reminder that when adding flags and properties into code, to use
> >> the SystemInstance Options to check for those properties.
> >>
> >> Specifically, calls like the following should be avoided.
> >>
> >> - Boolean.getBoolean("foo")
> >> - System.getProperty("foo")
> >>
> >> If someone were to attempt to use the above in an embedded scenario like
> >> so, they would be ignored:
> >>
> >> Properties p = new Properties();
> >> p.setProperty("foo", "the value");
> >> EJBContainer.createEJBContainer(p);
> >>
> >> Same if those were passed into an InitialContext or specified via a
> >> jndi.properties file.
> >>
> >> The nice thing about placing properties in these areas is they only last
> >> temporarily. If you run a test like this:
> >>
> >> Properties p = new Properties();
> >> p.setProperty("foo", "the value");
> >> EJBContainer.createEJBContainer(p);
> >>
> >> Then this:
> >>
> >> Properties p = new Properties();
> >> EJBContainer.createEJBContainer(p);
> >>
> >> The "foo" property of the previous test does not persist to the next
> test
> >> and change the behavior in unwanted ways. So the SystemInstance
> >> effectively allows us to create and destroy the container several times
> in
> >> a VM without any "bleeding" of static state.
> >>
> >> In that spirit, ideally we'd not store properties obtained through
> >> SystemInstance Options as static variables. Not sure how good we've
> been
> >> in that regard in the past. Probably something we should evaluate.
> >>
> >> Also note, you can check for properties at an application, module or ejb
> >> level. There are only a couple places where we use that so far, but
> >> certainly something it would be nice to see used more.
> >>
> >> Another interesting feature of the Options class is that it will log the
> >> property and value. Debug is used if the default value is chosen. Info
> >> level is used if the user changed the default. So it makes it easier
> for
> >> users to know if we are in fact "seeing" the property. Nice because
> it's
> >> really easy to misspell property names and spend a couple hours pulling
> >> your hair out.
> >>
> >>
> >> -David
> >>
> >>
>
>
Re: Note on adding properties
Posted by David Blevins <da...@gmail.com>.
On Feb 16, 2012, at 6:07 AM, Romain Manni-Bucau wrote:
> couldn't we simply add syst prop to th ejb container before adding the map?
>
> it is what we do for other container styles
That's exactly what ends up happening. We just need to make sure that on our end we check the properties in SytemInstance rather than java.lang.System so we can see all sources of properties.
-David
>
> 2012/2/16 David Blevins <da...@gmail.com>
>
>> Just a reminder that when adding flags and properties into code, to use
>> the SystemInstance Options to check for those properties.
>>
>> Specifically, calls like the following should be avoided.
>>
>> - Boolean.getBoolean("foo")
>> - System.getProperty("foo")
>>
>> If someone were to attempt to use the above in an embedded scenario like
>> so, they would be ignored:
>>
>> Properties p = new Properties();
>> p.setProperty("foo", "the value");
>> EJBContainer.createEJBContainer(p);
>>
>> Same if those were passed into an InitialContext or specified via a
>> jndi.properties file.
>>
>> The nice thing about placing properties in these areas is they only last
>> temporarily. If you run a test like this:
>>
>> Properties p = new Properties();
>> p.setProperty("foo", "the value");
>> EJBContainer.createEJBContainer(p);
>>
>> Then this:
>>
>> Properties p = new Properties();
>> EJBContainer.createEJBContainer(p);
>>
>> The "foo" property of the previous test does not persist to the next test
>> and change the behavior in unwanted ways. So the SystemInstance
>> effectively allows us to create and destroy the container several times in
>> a VM without any "bleeding" of static state.
>>
>> In that spirit, ideally we'd not store properties obtained through
>> SystemInstance Options as static variables. Not sure how good we've been
>> in that regard in the past. Probably something we should evaluate.
>>
>> Also note, you can check for properties at an application, module or ejb
>> level. There are only a couple places where we use that so far, but
>> certainly something it would be nice to see used more.
>>
>> Another interesting feature of the Options class is that it will log the
>> property and value. Debug is used if the default value is chosen. Info
>> level is used if the user changed the default. So it makes it easier for
>> users to know if we are in fact "seeing" the property. Nice because it's
>> really easy to misspell property names and spend a couple hours pulling
>> your hair out.
>>
>>
>> -David
>>
>>
Re: Note on adding properties
Posted by Romain Manni-Bucau <rm...@gmail.com>.
couldn't we simply add syst prop to th ejb container before adding the map?
it is what we do for other container styles
- Romain
2012/2/16 David Blevins <da...@gmail.com>
> Just a reminder that when adding flags and properties into code, to use
> the SystemInstance Options to check for those properties.
>
> Specifically, calls like the following should be avoided.
>
> - Boolean.getBoolean("foo")
> - System.getProperty("foo")
>
> If someone were to attempt to use the above in an embedded scenario like
> so, they would be ignored:
>
> Properties p = new Properties();
> p.setProperty("foo", "the value");
> EJBContainer.createEJBContainer(p);
>
> Same if those were passed into an InitialContext or specified via a
> jndi.properties file.
>
> The nice thing about placing properties in these areas is they only last
> temporarily. If you run a test like this:
>
> Properties p = new Properties();
> p.setProperty("foo", "the value");
> EJBContainer.createEJBContainer(p);
>
> Then this:
>
> Properties p = new Properties();
> EJBContainer.createEJBContainer(p);
>
> The "foo" property of the previous test does not persist to the next test
> and change the behavior in unwanted ways. So the SystemInstance
> effectively allows us to create and destroy the container several times in
> a VM without any "bleeding" of static state.
>
> In that spirit, ideally we'd not store properties obtained through
> SystemInstance Options as static variables. Not sure how good we've been
> in that regard in the past. Probably something we should evaluate.
>
> Also note, you can check for properties at an application, module or ejb
> level. There are only a couple places where we use that so far, but
> certainly something it would be nice to see used more.
>
> Another interesting feature of the Options class is that it will log the
> property and value. Debug is used if the default value is chosen. Info
> level is used if the user changed the default. So it makes it easier for
> users to know if we are in fact "seeing" the property. Nice because it's
> really easy to misspell property names and spend a couple hours pulling
> your hair out.
>
>
> -David
>
>