You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tomee.apache.org by "Thiago Veronezi (JIRA)" <ji...@apache.org> on 2010/11/04 11:19:44 UTC
[jira] Created: (OPENEJB-1393) override ejb-jar.xml using system
properties
override ejb-jar.xml using system properties
--------------------------------------------
Key: OPENEJB-1393
URL: https://issues.apache.org/jira/browse/OPENEJB-1393
Project: OpenEJB
Issue Type: New Feature
Components: container system
Reporter: Thiago Veronezi
Assignee: Thiago Veronezi
Priority: Minor
Fix For: 3.2
Users can use the system properties to override ejb-jar.xml values. Details on a possible implementation bellow...
*********************************************************************************************************
On Oct 29, 2010, at 7:51 AM, Thiago Veronezi wrote:
> Good catch, Mohammad.
> I will try figureout a way to override the values from a ejb-jar.xml using
> the system properties but with no special changes within the ejb-jar.xml. I
> think I have an idea... let me see... thats going to be fun... :O)
Excellent discussion. Great points on keeping the original descriptor intact.
Our persistence.xml overriding follows that idea very strongly.
I've wondered how we could do the same thing with overriding the ejb-jar.xml
like we do properties in the persistence.xml. Not exactly apples to apples as
the real data in the persistence.xml file is already properties and the data in
an ejb-jar.xml is straight xml.
Any kind of experimentation in this area is good. It directly relates to
people being able to mock things in tests as well. Likely a lot of people who
would love the feature.
One approach I've kicked around in the back of my head is using xpath
expressions to point to particular elements of the ejb-jar.xml so that they
could be overridden. Downside is sometimes xpath is maybe a little complicated.
Other thoughts involve maybe a simpler concept where maybe you can do something
like
<ejbName>.<property>=<value>
Where <property> is some predetermined list of the most relevant things that
someone would want to override. That could definitely work, though we do have
an actual properties object associated with every ejb (it's right there in the
BeanContext -- formerly called DeploymentInfo) which can be configured via the
openejb-jar.xml file. Those properties typically override settings that are in
the <Container> declaration. A good example is 'AccessTimeout' which can be
specified in the Container declaration, in the openejb-jar.xml via properties,
and now there's a standard javax.ejb.AccessTimeout annotation and ejb-jar.xml
element. The relationship between all those (which wins, etc) is not really as
clear as it could be. I suspect this happen more and more as we continue to
standardize options which were typically only expressible in the vendor
descriptor.
Another idea is to possibly add some sort of "visitor" kind of callback api,
whereby people could tinker with the JAXB tree we have that represents the
ejb-jar.xml data. Kind of plug into the deployment system in a way. Something
like that would run after the AnnotationDeployer so the JAXB tree they get
represents 100% of the xml and annotation data and is then the final metadata
we use for deployment. With a hook like that you could really do anything you
wanted, including create properties based overriders and other kinds of
"meta-data manipulators"
Short answer is, I don't know :) But it's wonderful to have people thinking
about it and willing to do some experimentation. Certainly would be a killer
feature.
Any progress in this area no matter how small is wonderful!
-David
>
> On Thu, Oct 28, 2010 at 5:49 AM, Mohammad Nour El-Din <
> nour.mohammad@xxxxxxxxx> wrote:
>
>> Hi Thiago...
>>
>> Brilliant idea :), but the problem is that will make the
>> ejb-jar.xml not compliant with the stds, and hence if you wanted to
>> use the same ejb-jar with some other AppSrvr/Cntnr you will have to
>> modify it which breaks the very basic concept of having a standard DD.
>> But this should be done from the OEJB side, like the property to
>> specify which DP to use or any other mechanism provided or can be
>> provided by OEJB.
>>
>> On Wed, Oct 27, 2010 at 5:24 PM, Thiago Veronezi <th...@xxxxxxxxxxxx>
>> wrote:
>>> Devs,
>>>
>>> A friend of mine just faced a configuration issue with openejb. He has
>>> multiple clients (companies) and each client should use a custom
>>> "ejb-jar.xml" with specific configuration values (some MDB
>> configurations).
>>> My advice to him was to create the ejb jar with multiples "ejb-jar.xml"
>> and
>>> then to use the "openejb.altdd.prefix" property to specify the file to be
>>> used.
>>>
>>> I had an idea to make it more configurable, but I need your advice. What
>> do
>>> you think if we add a property like "*openejb.altdd.replace.<numeric
>> value>*
>>> "?
>>> Imagine an ejb-jar.xml file like:
>>>
>>> <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"; version="3.0"
>>> metadata-complete="false">
>>> <enterprise-beans>
>>> <session>
>>> <ejb-name>MessageReaderImpl</ejb-name>
>>> <env-entry>
>>> <description>email user</description>
>>>
>>>
>> <env-entry-name>embedded.applicationejb.ejb.service.impl.message.MessageReaderImpl/user</env-entry-name>
>>> <env-entry-type>java.lang.String</env-entry-type>
>>> <env-entry-value>*{0}*</env-entry-value>
>>> </env-entry>
>>> <env-entry>
>>> <description>email password</description>
>>>
>>>
>> <env-entry-name>embedded.applicationejb.ejb.service.impl.message.MessageReaderImpl/password</env-entry-name>
>>> <env-entry-type>java.lang.String</env-entry-type>
>>> <env-entry-value>*{1}*</env-entry-value>
>>> </env-entry>
>>> </session>
>>> </enterprise-beans>
>>> </ejb-jar>
>>>
>>> We could replace the values {0} and {1} by system properties like...
>>> *openejb.altdd.replace.**0*=myUser
>>> *openejb.altdd.replace.1*=aReallyGoodPassword
>>>
>>> This should be done when the system is reading the ejb-jar.xml file
>> (Using
>>> the MessageFormat utility class).
>>> Here:
>>>
>> ***************************************************************************************************
>>>
>> /openejb-core/src/main/java/org/apache/openejb/config/ReadDescriptors.java
>>>
>>> public static EjbJar readEjbJar(URL url) throws OpenEJBException {
>>> try {
>>> if (isEmpty(url, "ejb-jar")) return new EjbJar();
>>> return (EjbJar) JaxbJavaee.unmarshal(EjbJar.class,
>>> url.openStream());
>>> } catch (SAXException e) {
>>> throw new OpenEJBException("Cannot parse the ejb-jar.xml file:
>> "
>>> + url.toExternalForm(), e);
>>> } catch (JAXBException e) {
>>> throw new OpenEJBException("Cannot unmarshall the ejb-jar.xml
>>> file: " + url.toExternalForm(), e);
>>> } catch (IOException e) {
>>> throw new OpenEJBException("Cannot read the ejb-jar.xml file:
>> "
>>> + url.toExternalForm(), e);
>>> } catch (Exception e) {
>>> throw new OpenEJBException("Encountered unknown error parsing
>>> the ejb-jar.xml file: " + url.toExternalForm(), e);
>>> }
>>> }
>>>
>> ***************************************************************************************************
>>>
>>> What do you think?
>>>
>>> thanks,
>>> Thiago.
>>>
>>
>>
>>
>> --
>> Thanks
>> - Mohammad Nour
>> Author of (WebSphere Application Server Community Edition 2.0 User Guide)
>> http://www.redbooks.ibm.com/abstracts/sg247585.html
>> - LinkedIn: http://www.linkedin.com/in/mnour
>> - Blog: http://tadabborat.blogspot.com
>> ----
>> "Life is like riding a bicycle. To keep your balance you must keep moving"
>> - Albert Einstein
>>
>> "Writing clean code is what you must do in order to call yourself a
>> professional. There is no reasonable excuse for doing anything less
>> than your best."
>> - Clean Code: A Handbook of Agile Software Craftsmanship
>>
>> "Stay hungry, stay foolish."
>> - Steve Jobs
>>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] [Closed] (OPENEJB-1393) override ejb-jar.xml using system
properties
Posted by "Jean-Louis MONTEIRO (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENEJB-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jean-Louis MONTEIRO closed OPENEJB-1393.
----------------------------------------
Resolution: Fixed
> override ejb-jar.xml using system properties
> --------------------------------------------
>
> Key: OPENEJB-1393
> URL: https://issues.apache.org/jira/browse/OPENEJB-1393
> Project: OpenEJB
> Issue Type: New Feature
> Components: container system
> Reporter: Thiago Veronezi
> Assignee: Thiago Veronezi
> Priority: Minor
> Fix For: 4.5.0
>
>
> Users can use the system properties to override ejb-jar.xml values. Details on a possible implementation bellow...
> *********************************************************************************************************
> On Oct 29, 2010, at 7:51 AM, Thiago Veronezi wrote:
> > Good catch, Mohammad.
> > I will try figureout a way to override the values from a ejb-jar.xml using
> > the system properties but with no special changes within the ejb-jar.xml. I
> > think I have an idea... let me see... thats going to be fun... :O)
> Excellent discussion. Great points on keeping the original descriptor intact.
> Our persistence.xml overriding follows that idea very strongly.
> I've wondered how we could do the same thing with overriding the ejb-jar.xml
> like we do properties in the persistence.xml. Not exactly apples to apples as
> the real data in the persistence.xml file is already properties and the data in
> an ejb-jar.xml is straight xml.
> Any kind of experimentation in this area is good. It directly relates to
> people being able to mock things in tests as well. Likely a lot of people who
> would love the feature.
> One approach I've kicked around in the back of my head is using xpath
> expressions to point to particular elements of the ejb-jar.xml so that they
> could be overridden. Downside is sometimes xpath is maybe a little complicated.
> Other thoughts involve maybe a simpler concept where maybe you can do something
> like
> <ejbName>.<property>=<value>
> Where <property> is some predetermined list of the most relevant things that
> someone would want to override. That could definitely work, though we do have
> an actual properties object associated with every ejb (it's right there in the
> BeanContext -- formerly called DeploymentInfo) which can be configured via the
> openejb-jar.xml file. Those properties typically override settings that are in
> the <Container> declaration. A good example is 'AccessTimeout' which can be
> specified in the Container declaration, in the openejb-jar.xml via properties,
> and now there's a standard javax.ejb.AccessTimeout annotation and ejb-jar.xml
> element. The relationship between all those (which wins, etc) is not really as
> clear as it could be. I suspect this happen more and more as we continue to
> standardize options which were typically only expressible in the vendor
> descriptor.
> Another idea is to possibly add some sort of "visitor" kind of callback api,
> whereby people could tinker with the JAXB tree we have that represents the
> ejb-jar.xml data. Kind of plug into the deployment system in a way. Something
> like that would run after the AnnotationDeployer so the JAXB tree they get
> represents 100% of the xml and annotation data and is then the final metadata
> we use for deployment. With a hook like that you could really do anything you
> wanted, including create properties based overriders and other kinds of
> "meta-data manipulators"
> Short answer is, I don't know :) But it's wonderful to have people thinking
> about it and willing to do some experimentation. Certainly would be a killer
> feature.
> Any progress in this area no matter how small is wonderful!
> -David
> >
> > On Thu, Oct 28, 2010 at 5:49 AM, Mohammad Nour El-Din <
> > nour.mohammad@xxxxxxxxx> wrote:
> >
> >> Hi Thiago...
> >>
> >> Brilliant idea :), but the problem is that will make the
> >> ejb-jar.xml not compliant with the stds, and hence if you wanted to
> >> use the same ejb-jar with some other AppSrvr/Cntnr you will have to
> >> modify it which breaks the very basic concept of having a standard DD.
> >> But this should be done from the OEJB side, like the property to
> >> specify which DP to use or any other mechanism provided or can be
> >> provided by OEJB.
> >>
> >> On Wed, Oct 27, 2010 at 5:24 PM, Thiago Veronezi <th...@xxxxxxxxxxxx>
> >> wrote:
> >>> Devs,
> >>>
> >>> A friend of mine just faced a configuration issue with openejb. He has
> >>> multiple clients (companies) and each client should use a custom
> >>> "ejb-jar.xml" with specific configuration values (some MDB
> >> configurations).
> >>> My advice to him was to create the ejb jar with multiples "ejb-jar.xml"
> >> and
> >>> then to use the "openejb.altdd.prefix" property to specify the file to be
> >>> used.
> >>>
> >>> I had an idea to make it more configurable, but I need your advice. What
> >> do
> >>> you think if we add a property like "*openejb.altdd.replace.<numeric
> >> value>*
> >>> "?
> >>> Imagine an ejb-jar.xml file like:
> >>>
> >>> <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"; version="3.0"
> >>> metadata-complete="false">
> >>> <enterprise-beans>
> >>> <session>
> >>> <ejb-name>MessageReaderImpl</ejb-name>
> >>> <env-entry>
> >>> <description>email user</description>
> >>>
> >>>
> >> <env-entry-name>embedded.applicationejb.ejb.service.impl.message.MessageReaderImpl/user</env-entry-name>
> >>> <env-entry-type>java.lang.String</env-entry-type>
> >>> <env-entry-value>*{0}*</env-entry-value>
> >>> </env-entry>
> >>> <env-entry>
> >>> <description>email password</description>
> >>>
> >>>
> >> <env-entry-name>embedded.applicationejb.ejb.service.impl.message.MessageReaderImpl/password</env-entry-name>
> >>> <env-entry-type>java.lang.String</env-entry-type>
> >>> <env-entry-value>*{1}*</env-entry-value>
> >>> </env-entry>
> >>> </session>
> >>> </enterprise-beans>
> >>> </ejb-jar>
> >>>
> >>> We could replace the values {0} and {1} by system properties like...
> >>> *openejb.altdd.replace.**0*=myUser
> >>> *openejb.altdd.replace.1*=aReallyGoodPassword
> >>>
> >>> This should be done when the system is reading the ejb-jar.xml file
> >> (Using
> >>> the MessageFormat utility class).
> >>> Here:
> >>>
> >> ***************************************************************************************************
> >>>
> >> /openejb-core/src/main/java/org/apache/openejb/config/ReadDescriptors.java
> >>>
> >>> public static EjbJar readEjbJar(URL url) throws OpenEJBException {
> >>> try {
> >>> if (isEmpty(url, "ejb-jar")) return new EjbJar();
> >>> return (EjbJar) JaxbJavaee.unmarshal(EjbJar.class,
> >>> url.openStream());
> >>> } catch (SAXException e) {
> >>> throw new OpenEJBException("Cannot parse the ejb-jar.xml file:
> >> "
> >>> + url.toExternalForm(), e);
> >>> } catch (JAXBException e) {
> >>> throw new OpenEJBException("Cannot unmarshall the ejb-jar.xml
> >>> file: " + url.toExternalForm(), e);
> >>> } catch (IOException e) {
> >>> throw new OpenEJBException("Cannot read the ejb-jar.xml file:
> >> "
> >>> + url.toExternalForm(), e);
> >>> } catch (Exception e) {
> >>> throw new OpenEJBException("Encountered unknown error parsing
> >>> the ejb-jar.xml file: " + url.toExternalForm(), e);
> >>> }
> >>> }
> >>>
> >> ***************************************************************************************************
> >>>
> >>> What do you think?
> >>>
> >>> thanks,
> >>> Thiago.
> >>>
> >>
> >>
> >>
> >> --
> >> Thanks
> >> - Mohammad Nour
> >> Author of (WebSphere Application Server Community Edition 2.0 User Guide)
> >> http://www.redbooks.ibm.com/abstracts/sg247585.html
> >> - LinkedIn: http://www.linkedin.com/in/mnour
> >> - Blog: http://tadabborat.blogspot.com
> >> ----
> >> "Life is like riding a bicycle. To keep your balance you must keep moving"
> >> - Albert Einstein
> >>
> >> "Writing clean code is what you must do in order to call yourself a
> >> professional. There is no reasonable excuse for doing anything less
> >> than your best."
> >> - Clean Code: A Handbook of Agile Software Craftsmanship
> >>
> >> "Stay hungry, stay foolish."
> >> - Steve Jobs
> >>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENEJB-1393) override ejb-jar.xml using system
properties
Posted by "David Blevins (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENEJB-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Blevins updated OPENEJB-1393:
-----------------------------------
Due Date: 25/Nov/10 (was: 25/Nov/10)
Fix Version/s: 4.0.0
> override ejb-jar.xml using system properties
> --------------------------------------------
>
> Key: OPENEJB-1393
> URL: https://issues.apache.org/jira/browse/OPENEJB-1393
> Project: OpenEJB
> Issue Type: New Feature
> Components: container system
> Reporter: Thiago Veronezi
> Assignee: Thiago Veronezi
> Priority: Minor
> Fix For: 4.0.0
>
>
> Users can use the system properties to override ejb-jar.xml values. Details on a possible implementation bellow...
> *********************************************************************************************************
> On Oct 29, 2010, at 7:51 AM, Thiago Veronezi wrote:
> > Good catch, Mohammad.
> > I will try figureout a way to override the values from a ejb-jar.xml using
> > the system properties but with no special changes within the ejb-jar.xml. I
> > think I have an idea... let me see... thats going to be fun... :O)
> Excellent discussion. Great points on keeping the original descriptor intact.
> Our persistence.xml overriding follows that idea very strongly.
> I've wondered how we could do the same thing with overriding the ejb-jar.xml
> like we do properties in the persistence.xml. Not exactly apples to apples as
> the real data in the persistence.xml file is already properties and the data in
> an ejb-jar.xml is straight xml.
> Any kind of experimentation in this area is good. It directly relates to
> people being able to mock things in tests as well. Likely a lot of people who
> would love the feature.
> One approach I've kicked around in the back of my head is using xpath
> expressions to point to particular elements of the ejb-jar.xml so that they
> could be overridden. Downside is sometimes xpath is maybe a little complicated.
> Other thoughts involve maybe a simpler concept where maybe you can do something
> like
> <ejbName>.<property>=<value>
> Where <property> is some predetermined list of the most relevant things that
> someone would want to override. That could definitely work, though we do have
> an actual properties object associated with every ejb (it's right there in the
> BeanContext -- formerly called DeploymentInfo) which can be configured via the
> openejb-jar.xml file. Those properties typically override settings that are in
> the <Container> declaration. A good example is 'AccessTimeout' which can be
> specified in the Container declaration, in the openejb-jar.xml via properties,
> and now there's a standard javax.ejb.AccessTimeout annotation and ejb-jar.xml
> element. The relationship between all those (which wins, etc) is not really as
> clear as it could be. I suspect this happen more and more as we continue to
> standardize options which were typically only expressible in the vendor
> descriptor.
> Another idea is to possibly add some sort of "visitor" kind of callback api,
> whereby people could tinker with the JAXB tree we have that represents the
> ejb-jar.xml data. Kind of plug into the deployment system in a way. Something
> like that would run after the AnnotationDeployer so the JAXB tree they get
> represents 100% of the xml and annotation data and is then the final metadata
> we use for deployment. With a hook like that you could really do anything you
> wanted, including create properties based overriders and other kinds of
> "meta-data manipulators"
> Short answer is, I don't know :) But it's wonderful to have people thinking
> about it and willing to do some experimentation. Certainly would be a killer
> feature.
> Any progress in this area no matter how small is wonderful!
> -David
> >
> > On Thu, Oct 28, 2010 at 5:49 AM, Mohammad Nour El-Din <
> > nour.mohammad@xxxxxxxxx> wrote:
> >
> >> Hi Thiago...
> >>
> >> Brilliant idea :), but the problem is that will make the
> >> ejb-jar.xml not compliant with the stds, and hence if you wanted to
> >> use the same ejb-jar with some other AppSrvr/Cntnr you will have to
> >> modify it which breaks the very basic concept of having a standard DD.
> >> But this should be done from the OEJB side, like the property to
> >> specify which DP to use or any other mechanism provided or can be
> >> provided by OEJB.
> >>
> >> On Wed, Oct 27, 2010 at 5:24 PM, Thiago Veronezi <th...@xxxxxxxxxxxx>
> >> wrote:
> >>> Devs,
> >>>
> >>> A friend of mine just faced a configuration issue with openejb. He has
> >>> multiple clients (companies) and each client should use a custom
> >>> "ejb-jar.xml" with specific configuration values (some MDB
> >> configurations).
> >>> My advice to him was to create the ejb jar with multiples "ejb-jar.xml"
> >> and
> >>> then to use the "openejb.altdd.prefix" property to specify the file to be
> >>> used.
> >>>
> >>> I had an idea to make it more configurable, but I need your advice. What
> >> do
> >>> you think if we add a property like "*openejb.altdd.replace.<numeric
> >> value>*
> >>> "?
> >>> Imagine an ejb-jar.xml file like:
> >>>
> >>> <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"; version="3.0"
> >>> metadata-complete="false">
> >>> <enterprise-beans>
> >>> <session>
> >>> <ejb-name>MessageReaderImpl</ejb-name>
> >>> <env-entry>
> >>> <description>email user</description>
> >>>
> >>>
> >> <env-entry-name>embedded.applicationejb.ejb.service.impl.message.MessageReaderImpl/user</env-entry-name>
> >>> <env-entry-type>java.lang.String</env-entry-type>
> >>> <env-entry-value>*{0}*</env-entry-value>
> >>> </env-entry>
> >>> <env-entry>
> >>> <description>email password</description>
> >>>
> >>>
> >> <env-entry-name>embedded.applicationejb.ejb.service.impl.message.MessageReaderImpl/password</env-entry-name>
> >>> <env-entry-type>java.lang.String</env-entry-type>
> >>> <env-entry-value>*{1}*</env-entry-value>
> >>> </env-entry>
> >>> </session>
> >>> </enterprise-beans>
> >>> </ejb-jar>
> >>>
> >>> We could replace the values {0} and {1} by system properties like...
> >>> *openejb.altdd.replace.**0*=myUser
> >>> *openejb.altdd.replace.1*=aReallyGoodPassword
> >>>
> >>> This should be done when the system is reading the ejb-jar.xml file
> >> (Using
> >>> the MessageFormat utility class).
> >>> Here:
> >>>
> >> ***************************************************************************************************
> >>>
> >> /openejb-core/src/main/java/org/apache/openejb/config/ReadDescriptors.java
> >>>
> >>> public static EjbJar readEjbJar(URL url) throws OpenEJBException {
> >>> try {
> >>> if (isEmpty(url, "ejb-jar")) return new EjbJar();
> >>> return (EjbJar) JaxbJavaee.unmarshal(EjbJar.class,
> >>> url.openStream());
> >>> } catch (SAXException e) {
> >>> throw new OpenEJBException("Cannot parse the ejb-jar.xml file:
> >> "
> >>> + url.toExternalForm(), e);
> >>> } catch (JAXBException e) {
> >>> throw new OpenEJBException("Cannot unmarshall the ejb-jar.xml
> >>> file: " + url.toExternalForm(), e);
> >>> } catch (IOException e) {
> >>> throw new OpenEJBException("Cannot read the ejb-jar.xml file:
> >> "
> >>> + url.toExternalForm(), e);
> >>> } catch (Exception e) {
> >>> throw new OpenEJBException("Encountered unknown error parsing
> >>> the ejb-jar.xml file: " + url.toExternalForm(), e);
> >>> }
> >>> }
> >>>
> >> ***************************************************************************************************
> >>>
> >>> What do you think?
> >>>
> >>> thanks,
> >>> Thiago.
> >>>
> >>
> >>
> >>
> >> --
> >> Thanks
> >> - Mohammad Nour
> >> Author of (WebSphere Application Server Community Edition 2.0 User Guide)
> >> http://www.redbooks.ibm.com/abstracts/sg247585.html
> >> - LinkedIn: http://www.linkedin.com/in/mnour
> >> - Blog: http://tadabborat.blogspot.com
> >> ----
> >> "Life is like riding a bicycle. To keep your balance you must keep moving"
> >> - Albert Einstein
> >>
> >> "Writing clean code is what you must do in order to call yourself a
> >> professional. There is no reasonable excuse for doing anything less
> >> than your best."
> >> - Clean Code: A Handbook of Agile Software Craftsmanship
> >>
> >> "Stay hungry, stay foolish."
> >> - Steve Jobs
> >>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (OPENEJB-1393) override ejb-jar.xml using system
properties
Posted by "David Blevins (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENEJB-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Blevins closed OPENEJB-1393.
----------------------------------
Resolution: Fixed
> override ejb-jar.xml using system properties
> --------------------------------------------
>
> Key: OPENEJB-1393
> URL: https://issues.apache.org/jira/browse/OPENEJB-1393
> Project: OpenEJB
> Issue Type: New Feature
> Components: container system
> Reporter: Thiago Veronezi
> Assignee: Thiago Veronezi
> Priority: Minor
> Fix For: 4.0.0
>
>
> Users can use the system properties to override ejb-jar.xml values. Details on a possible implementation bellow...
> *********************************************************************************************************
> On Oct 29, 2010, at 7:51 AM, Thiago Veronezi wrote:
> > Good catch, Mohammad.
> > I will try figureout a way to override the values from a ejb-jar.xml using
> > the system properties but with no special changes within the ejb-jar.xml. I
> > think I have an idea... let me see... thats going to be fun... :O)
> Excellent discussion. Great points on keeping the original descriptor intact.
> Our persistence.xml overriding follows that idea very strongly.
> I've wondered how we could do the same thing with overriding the ejb-jar.xml
> like we do properties in the persistence.xml. Not exactly apples to apples as
> the real data in the persistence.xml file is already properties and the data in
> an ejb-jar.xml is straight xml.
> Any kind of experimentation in this area is good. It directly relates to
> people being able to mock things in tests as well. Likely a lot of people who
> would love the feature.
> One approach I've kicked around in the back of my head is using xpath
> expressions to point to particular elements of the ejb-jar.xml so that they
> could be overridden. Downside is sometimes xpath is maybe a little complicated.
> Other thoughts involve maybe a simpler concept where maybe you can do something
> like
> <ejbName>.<property>=<value>
> Where <property> is some predetermined list of the most relevant things that
> someone would want to override. That could definitely work, though we do have
> an actual properties object associated with every ejb (it's right there in the
> BeanContext -- formerly called DeploymentInfo) which can be configured via the
> openejb-jar.xml file. Those properties typically override settings that are in
> the <Container> declaration. A good example is 'AccessTimeout' which can be
> specified in the Container declaration, in the openejb-jar.xml via properties,
> and now there's a standard javax.ejb.AccessTimeout annotation and ejb-jar.xml
> element. The relationship between all those (which wins, etc) is not really as
> clear as it could be. I suspect this happen more and more as we continue to
> standardize options which were typically only expressible in the vendor
> descriptor.
> Another idea is to possibly add some sort of "visitor" kind of callback api,
> whereby people could tinker with the JAXB tree we have that represents the
> ejb-jar.xml data. Kind of plug into the deployment system in a way. Something
> like that would run after the AnnotationDeployer so the JAXB tree they get
> represents 100% of the xml and annotation data and is then the final metadata
> we use for deployment. With a hook like that you could really do anything you
> wanted, including create properties based overriders and other kinds of
> "meta-data manipulators"
> Short answer is, I don't know :) But it's wonderful to have people thinking
> about it and willing to do some experimentation. Certainly would be a killer
> feature.
> Any progress in this area no matter how small is wonderful!
> -David
> >
> > On Thu, Oct 28, 2010 at 5:49 AM, Mohammad Nour El-Din <
> > nour.mohammad@xxxxxxxxx> wrote:
> >
> >> Hi Thiago...
> >>
> >> Brilliant idea :), but the problem is that will make the
> >> ejb-jar.xml not compliant with the stds, and hence if you wanted to
> >> use the same ejb-jar with some other AppSrvr/Cntnr you will have to
> >> modify it which breaks the very basic concept of having a standard DD.
> >> But this should be done from the OEJB side, like the property to
> >> specify which DP to use or any other mechanism provided or can be
> >> provided by OEJB.
> >>
> >> On Wed, Oct 27, 2010 at 5:24 PM, Thiago Veronezi <th...@xxxxxxxxxxxx>
> >> wrote:
> >>> Devs,
> >>>
> >>> A friend of mine just faced a configuration issue with openejb. He has
> >>> multiple clients (companies) and each client should use a custom
> >>> "ejb-jar.xml" with specific configuration values (some MDB
> >> configurations).
> >>> My advice to him was to create the ejb jar with multiples "ejb-jar.xml"
> >> and
> >>> then to use the "openejb.altdd.prefix" property to specify the file to be
> >>> used.
> >>>
> >>> I had an idea to make it more configurable, but I need your advice. What
> >> do
> >>> you think if we add a property like "*openejb.altdd.replace.<numeric
> >> value>*
> >>> "?
> >>> Imagine an ejb-jar.xml file like:
> >>>
> >>> <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"; version="3.0"
> >>> metadata-complete="false">
> >>> <enterprise-beans>
> >>> <session>
> >>> <ejb-name>MessageReaderImpl</ejb-name>
> >>> <env-entry>
> >>> <description>email user</description>
> >>>
> >>>
> >> <env-entry-name>embedded.applicationejb.ejb.service.impl.message.MessageReaderImpl/user</env-entry-name>
> >>> <env-entry-type>java.lang.String</env-entry-type>
> >>> <env-entry-value>*{0}*</env-entry-value>
> >>> </env-entry>
> >>> <env-entry>
> >>> <description>email password</description>
> >>>
> >>>
> >> <env-entry-name>embedded.applicationejb.ejb.service.impl.message.MessageReaderImpl/password</env-entry-name>
> >>> <env-entry-type>java.lang.String</env-entry-type>
> >>> <env-entry-value>*{1}*</env-entry-value>
> >>> </env-entry>
> >>> </session>
> >>> </enterprise-beans>
> >>> </ejb-jar>
> >>>
> >>> We could replace the values {0} and {1} by system properties like...
> >>> *openejb.altdd.replace.**0*=myUser
> >>> *openejb.altdd.replace.1*=aReallyGoodPassword
> >>>
> >>> This should be done when the system is reading the ejb-jar.xml file
> >> (Using
> >>> the MessageFormat utility class).
> >>> Here:
> >>>
> >> ***************************************************************************************************
> >>>
> >> /openejb-core/src/main/java/org/apache/openejb/config/ReadDescriptors.java
> >>>
> >>> public static EjbJar readEjbJar(URL url) throws OpenEJBException {
> >>> try {
> >>> if (isEmpty(url, "ejb-jar")) return new EjbJar();
> >>> return (EjbJar) JaxbJavaee.unmarshal(EjbJar.class,
> >>> url.openStream());
> >>> } catch (SAXException e) {
> >>> throw new OpenEJBException("Cannot parse the ejb-jar.xml file:
> >> "
> >>> + url.toExternalForm(), e);
> >>> } catch (JAXBException e) {
> >>> throw new OpenEJBException("Cannot unmarshall the ejb-jar.xml
> >>> file: " + url.toExternalForm(), e);
> >>> } catch (IOException e) {
> >>> throw new OpenEJBException("Cannot read the ejb-jar.xml file:
> >> "
> >>> + url.toExternalForm(), e);
> >>> } catch (Exception e) {
> >>> throw new OpenEJBException("Encountered unknown error parsing
> >>> the ejb-jar.xml file: " + url.toExternalForm(), e);
> >>> }
> >>> }
> >>>
> >> ***************************************************************************************************
> >>>
> >>> What do you think?
> >>>
> >>> thanks,
> >>> Thiago.
> >>>
> >>
> >>
> >>
> >> --
> >> Thanks
> >> - Mohammad Nour
> >> Author of (WebSphere Application Server Community Edition 2.0 User Guide)
> >> http://www.redbooks.ibm.com/abstracts/sg247585.html
> >> - LinkedIn: http://www.linkedin.com/in/mnour
> >> - Blog: http://tadabborat.blogspot.com
> >> ----
> >> "Life is like riding a bicycle. To keep your balance you must keep moving"
> >> - Albert Einstein
> >>
> >> "Writing clean code is what you must do in order to call yourself a
> >> professional. There is no reasonable excuse for doing anything less
> >> than your best."
> >> - Clean Code: A Handbook of Agile Software Craftsmanship
> >>
> >> "Stay hungry, stay foolish."
> >> - Steve Jobs
> >>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENEJB-1393) override ejb-jar.xml using system
properties
Posted by "David Blevins (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENEJB-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Blevins updated OPENEJB-1393:
-----------------------------------
Fix Version/s: (was: 4.5.0)
> override ejb-jar.xml using system properties
> --------------------------------------------
>
> Key: OPENEJB-1393
> URL: https://issues.apache.org/jira/browse/OPENEJB-1393
> Project: OpenEJB
> Issue Type: New Feature
> Components: container system
> Reporter: Thiago Veronezi
> Assignee: Thiago Veronezi
> Priority: Minor
> Fix For: 4.0.0
>
>
> Users can use the system properties to override ejb-jar.xml values. Details on a possible implementation bellow...
> *********************************************************************************************************
> On Oct 29, 2010, at 7:51 AM, Thiago Veronezi wrote:
> > Good catch, Mohammad.
> > I will try figureout a way to override the values from a ejb-jar.xml using
> > the system properties but with no special changes within the ejb-jar.xml. I
> > think I have an idea... let me see... thats going to be fun... :O)
> Excellent discussion. Great points on keeping the original descriptor intact.
> Our persistence.xml overriding follows that idea very strongly.
> I've wondered how we could do the same thing with overriding the ejb-jar.xml
> like we do properties in the persistence.xml. Not exactly apples to apples as
> the real data in the persistence.xml file is already properties and the data in
> an ejb-jar.xml is straight xml.
> Any kind of experimentation in this area is good. It directly relates to
> people being able to mock things in tests as well. Likely a lot of people who
> would love the feature.
> One approach I've kicked around in the back of my head is using xpath
> expressions to point to particular elements of the ejb-jar.xml so that they
> could be overridden. Downside is sometimes xpath is maybe a little complicated.
> Other thoughts involve maybe a simpler concept where maybe you can do something
> like
> <ejbName>.<property>=<value>
> Where <property> is some predetermined list of the most relevant things that
> someone would want to override. That could definitely work, though we do have
> an actual properties object associated with every ejb (it's right there in the
> BeanContext -- formerly called DeploymentInfo) which can be configured via the
> openejb-jar.xml file. Those properties typically override settings that are in
> the <Container> declaration. A good example is 'AccessTimeout' which can be
> specified in the Container declaration, in the openejb-jar.xml via properties,
> and now there's a standard javax.ejb.AccessTimeout annotation and ejb-jar.xml
> element. The relationship between all those (which wins, etc) is not really as
> clear as it could be. I suspect this happen more and more as we continue to
> standardize options which were typically only expressible in the vendor
> descriptor.
> Another idea is to possibly add some sort of "visitor" kind of callback api,
> whereby people could tinker with the JAXB tree we have that represents the
> ejb-jar.xml data. Kind of plug into the deployment system in a way. Something
> like that would run after the AnnotationDeployer so the JAXB tree they get
> represents 100% of the xml and annotation data and is then the final metadata
> we use for deployment. With a hook like that you could really do anything you
> wanted, including create properties based overriders and other kinds of
> "meta-data manipulators"
> Short answer is, I don't know :) But it's wonderful to have people thinking
> about it and willing to do some experimentation. Certainly would be a killer
> feature.
> Any progress in this area no matter how small is wonderful!
> -David
> >
> > On Thu, Oct 28, 2010 at 5:49 AM, Mohammad Nour El-Din <
> > nour.mohammad@xxxxxxxxx> wrote:
> >
> >> Hi Thiago...
> >>
> >> Brilliant idea :), but the problem is that will make the
> >> ejb-jar.xml not compliant with the stds, and hence if you wanted to
> >> use the same ejb-jar with some other AppSrvr/Cntnr you will have to
> >> modify it which breaks the very basic concept of having a standard DD.
> >> But this should be done from the OEJB side, like the property to
> >> specify which DP to use or any other mechanism provided or can be
> >> provided by OEJB.
> >>
> >> On Wed, Oct 27, 2010 at 5:24 PM, Thiago Veronezi <th...@xxxxxxxxxxxx>
> >> wrote:
> >>> Devs,
> >>>
> >>> A friend of mine just faced a configuration issue with openejb. He has
> >>> multiple clients (companies) and each client should use a custom
> >>> "ejb-jar.xml" with specific configuration values (some MDB
> >> configurations).
> >>> My advice to him was to create the ejb jar with multiples "ejb-jar.xml"
> >> and
> >>> then to use the "openejb.altdd.prefix" property to specify the file to be
> >>> used.
> >>>
> >>> I had an idea to make it more configurable, but I need your advice. What
> >> do
> >>> you think if we add a property like "*openejb.altdd.replace.<numeric
> >> value>*
> >>> "?
> >>> Imagine an ejb-jar.xml file like:
> >>>
> >>> <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"; version="3.0"
> >>> metadata-complete="false">
> >>> <enterprise-beans>
> >>> <session>
> >>> <ejb-name>MessageReaderImpl</ejb-name>
> >>> <env-entry>
> >>> <description>email user</description>
> >>>
> >>>
> >> <env-entry-name>embedded.applicationejb.ejb.service.impl.message.MessageReaderImpl/user</env-entry-name>
> >>> <env-entry-type>java.lang.String</env-entry-type>
> >>> <env-entry-value>*{0}*</env-entry-value>
> >>> </env-entry>
> >>> <env-entry>
> >>> <description>email password</description>
> >>>
> >>>
> >> <env-entry-name>embedded.applicationejb.ejb.service.impl.message.MessageReaderImpl/password</env-entry-name>
> >>> <env-entry-type>java.lang.String</env-entry-type>
> >>> <env-entry-value>*{1}*</env-entry-value>
> >>> </env-entry>
> >>> </session>
> >>> </enterprise-beans>
> >>> </ejb-jar>
> >>>
> >>> We could replace the values {0} and {1} by system properties like...
> >>> *openejb.altdd.replace.**0*=myUser
> >>> *openejb.altdd.replace.1*=aReallyGoodPassword
> >>>
> >>> This should be done when the system is reading the ejb-jar.xml file
> >> (Using
> >>> the MessageFormat utility class).
> >>> Here:
> >>>
> >> ***************************************************************************************************
> >>>
> >> /openejb-core/src/main/java/org/apache/openejb/config/ReadDescriptors.java
> >>>
> >>> public static EjbJar readEjbJar(URL url) throws OpenEJBException {
> >>> try {
> >>> if (isEmpty(url, "ejb-jar")) return new EjbJar();
> >>> return (EjbJar) JaxbJavaee.unmarshal(EjbJar.class,
> >>> url.openStream());
> >>> } catch (SAXException e) {
> >>> throw new OpenEJBException("Cannot parse the ejb-jar.xml file:
> >> "
> >>> + url.toExternalForm(), e);
> >>> } catch (JAXBException e) {
> >>> throw new OpenEJBException("Cannot unmarshall the ejb-jar.xml
> >>> file: " + url.toExternalForm(), e);
> >>> } catch (IOException e) {
> >>> throw new OpenEJBException("Cannot read the ejb-jar.xml file:
> >> "
> >>> + url.toExternalForm(), e);
> >>> } catch (Exception e) {
> >>> throw new OpenEJBException("Encountered unknown error parsing
> >>> the ejb-jar.xml file: " + url.toExternalForm(), e);
> >>> }
> >>> }
> >>>
> >> ***************************************************************************************************
> >>>
> >>> What do you think?
> >>>
> >>> thanks,
> >>> Thiago.
> >>>
> >>
> >>
> >>
> >> --
> >> Thanks
> >> - Mohammad Nour
> >> Author of (WebSphere Application Server Community Edition 2.0 User Guide)
> >> http://www.redbooks.ibm.com/abstracts/sg247585.html
> >> - LinkedIn: http://www.linkedin.com/in/mnour
> >> - Blog: http://tadabborat.blogspot.com
> >> ----
> >> "Life is like riding a bicycle. To keep your balance you must keep moving"
> >> - Albert Einstein
> >>
> >> "Writing clean code is what you must do in order to call yourself a
> >> professional. There is no reasonable excuse for doing anything less
> >> than your best."
> >> - Clean Code: A Handbook of Agile Software Craftsmanship
> >>
> >> "Stay hungry, stay foolish."
> >> - Steve Jobs
> >>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENEJB-1393) override ejb-jar.xml using system
properties
Posted by "Jean-Louis MONTEIRO (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENEJB-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jean-Louis MONTEIRO updated OPENEJB-1393:
-----------------------------------------
Fix Version/s: (was: 4.0)
4.5.0
> override ejb-jar.xml using system properties
> --------------------------------------------
>
> Key: OPENEJB-1393
> URL: https://issues.apache.org/jira/browse/OPENEJB-1393
> Project: OpenEJB
> Issue Type: New Feature
> Components: container system
> Reporter: Thiago Veronezi
> Assignee: Thiago Veronezi
> Priority: Minor
> Fix For: 4.5.0
>
>
> Users can use the system properties to override ejb-jar.xml values. Details on a possible implementation bellow...
> *********************************************************************************************************
> On Oct 29, 2010, at 7:51 AM, Thiago Veronezi wrote:
> > Good catch, Mohammad.
> > I will try figureout a way to override the values from a ejb-jar.xml using
> > the system properties but with no special changes within the ejb-jar.xml. I
> > think I have an idea... let me see... thats going to be fun... :O)
> Excellent discussion. Great points on keeping the original descriptor intact.
> Our persistence.xml overriding follows that idea very strongly.
> I've wondered how we could do the same thing with overriding the ejb-jar.xml
> like we do properties in the persistence.xml. Not exactly apples to apples as
> the real data in the persistence.xml file is already properties and the data in
> an ejb-jar.xml is straight xml.
> Any kind of experimentation in this area is good. It directly relates to
> people being able to mock things in tests as well. Likely a lot of people who
> would love the feature.
> One approach I've kicked around in the back of my head is using xpath
> expressions to point to particular elements of the ejb-jar.xml so that they
> could be overridden. Downside is sometimes xpath is maybe a little complicated.
> Other thoughts involve maybe a simpler concept where maybe you can do something
> like
> <ejbName>.<property>=<value>
> Where <property> is some predetermined list of the most relevant things that
> someone would want to override. That could definitely work, though we do have
> an actual properties object associated with every ejb (it's right there in the
> BeanContext -- formerly called DeploymentInfo) which can be configured via the
> openejb-jar.xml file. Those properties typically override settings that are in
> the <Container> declaration. A good example is 'AccessTimeout' which can be
> specified in the Container declaration, in the openejb-jar.xml via properties,
> and now there's a standard javax.ejb.AccessTimeout annotation and ejb-jar.xml
> element. The relationship between all those (which wins, etc) is not really as
> clear as it could be. I suspect this happen more and more as we continue to
> standardize options which were typically only expressible in the vendor
> descriptor.
> Another idea is to possibly add some sort of "visitor" kind of callback api,
> whereby people could tinker with the JAXB tree we have that represents the
> ejb-jar.xml data. Kind of plug into the deployment system in a way. Something
> like that would run after the AnnotationDeployer so the JAXB tree they get
> represents 100% of the xml and annotation data and is then the final metadata
> we use for deployment. With a hook like that you could really do anything you
> wanted, including create properties based overriders and other kinds of
> "meta-data manipulators"
> Short answer is, I don't know :) But it's wonderful to have people thinking
> about it and willing to do some experimentation. Certainly would be a killer
> feature.
> Any progress in this area no matter how small is wonderful!
> -David
> >
> > On Thu, Oct 28, 2010 at 5:49 AM, Mohammad Nour El-Din <
> > nour.mohammad@xxxxxxxxx> wrote:
> >
> >> Hi Thiago...
> >>
> >> Brilliant idea :), but the problem is that will make the
> >> ejb-jar.xml not compliant with the stds, and hence if you wanted to
> >> use the same ejb-jar with some other AppSrvr/Cntnr you will have to
> >> modify it which breaks the very basic concept of having a standard DD.
> >> But this should be done from the OEJB side, like the property to
> >> specify which DP to use or any other mechanism provided or can be
> >> provided by OEJB.
> >>
> >> On Wed, Oct 27, 2010 at 5:24 PM, Thiago Veronezi <th...@xxxxxxxxxxxx>
> >> wrote:
> >>> Devs,
> >>>
> >>> A friend of mine just faced a configuration issue with openejb. He has
> >>> multiple clients (companies) and each client should use a custom
> >>> "ejb-jar.xml" with specific configuration values (some MDB
> >> configurations).
> >>> My advice to him was to create the ejb jar with multiples "ejb-jar.xml"
> >> and
> >>> then to use the "openejb.altdd.prefix" property to specify the file to be
> >>> used.
> >>>
> >>> I had an idea to make it more configurable, but I need your advice. What
> >> do
> >>> you think if we add a property like "*openejb.altdd.replace.<numeric
> >> value>*
> >>> "?
> >>> Imagine an ejb-jar.xml file like:
> >>>
> >>> <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"; version="3.0"
> >>> metadata-complete="false">
> >>> <enterprise-beans>
> >>> <session>
> >>> <ejb-name>MessageReaderImpl</ejb-name>
> >>> <env-entry>
> >>> <description>email user</description>
> >>>
> >>>
> >> <env-entry-name>embedded.applicationejb.ejb.service.impl.message.MessageReaderImpl/user</env-entry-name>
> >>> <env-entry-type>java.lang.String</env-entry-type>
> >>> <env-entry-value>*{0}*</env-entry-value>
> >>> </env-entry>
> >>> <env-entry>
> >>> <description>email password</description>
> >>>
> >>>
> >> <env-entry-name>embedded.applicationejb.ejb.service.impl.message.MessageReaderImpl/password</env-entry-name>
> >>> <env-entry-type>java.lang.String</env-entry-type>
> >>> <env-entry-value>*{1}*</env-entry-value>
> >>> </env-entry>
> >>> </session>
> >>> </enterprise-beans>
> >>> </ejb-jar>
> >>>
> >>> We could replace the values {0} and {1} by system properties like...
> >>> *openejb.altdd.replace.**0*=myUser
> >>> *openejb.altdd.replace.1*=aReallyGoodPassword
> >>>
> >>> This should be done when the system is reading the ejb-jar.xml file
> >> (Using
> >>> the MessageFormat utility class).
> >>> Here:
> >>>
> >> ***************************************************************************************************
> >>>
> >> /openejb-core/src/main/java/org/apache/openejb/config/ReadDescriptors.java
> >>>
> >>> public static EjbJar readEjbJar(URL url) throws OpenEJBException {
> >>> try {
> >>> if (isEmpty(url, "ejb-jar")) return new EjbJar();
> >>> return (EjbJar) JaxbJavaee.unmarshal(EjbJar.class,
> >>> url.openStream());
> >>> } catch (SAXException e) {
> >>> throw new OpenEJBException("Cannot parse the ejb-jar.xml file:
> >> "
> >>> + url.toExternalForm(), e);
> >>> } catch (JAXBException e) {
> >>> throw new OpenEJBException("Cannot unmarshall the ejb-jar.xml
> >>> file: " + url.toExternalForm(), e);
> >>> } catch (IOException e) {
> >>> throw new OpenEJBException("Cannot read the ejb-jar.xml file:
> >> "
> >>> + url.toExternalForm(), e);
> >>> } catch (Exception e) {
> >>> throw new OpenEJBException("Encountered unknown error parsing
> >>> the ejb-jar.xml file: " + url.toExternalForm(), e);
> >>> }
> >>> }
> >>>
> >> ***************************************************************************************************
> >>>
> >>> What do you think?
> >>>
> >>> thanks,
> >>> Thiago.
> >>>
> >>
> >>
> >>
> >> --
> >> Thanks
> >> - Mohammad Nour
> >> Author of (WebSphere Application Server Community Edition 2.0 User Guide)
> >> http://www.redbooks.ibm.com/abstracts/sg247585.html
> >> - LinkedIn: http://www.linkedin.com/in/mnour
> >> - Blog: http://tadabborat.blogspot.com
> >> ----
> >> "Life is like riding a bicycle. To keep your balance you must keep moving"
> >> - Albert Einstein
> >>
> >> "Writing clean code is what you must do in order to call yourself a
> >> professional. There is no reasonable excuse for doing anything less
> >> than your best."
> >> - Clean Code: A Handbook of Agile Software Craftsmanship
> >>
> >> "Stay hungry, stay foolish."
> >> - Steve Jobs
> >>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (OPENEJB-1393) override ejb-jar.xml using system
properties
Posted by "David Blevins (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENEJB-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Blevins reopened OPENEJB-1393:
------------------------------------
> override ejb-jar.xml using system properties
> --------------------------------------------
>
> Key: OPENEJB-1393
> URL: https://issues.apache.org/jira/browse/OPENEJB-1393
> Project: OpenEJB
> Issue Type: New Feature
> Components: container system
> Reporter: Thiago Veronezi
> Assignee: Thiago Veronezi
> Priority: Minor
> Fix For: 4.0.0
>
>
> Users can use the system properties to override ejb-jar.xml values. Details on a possible implementation bellow...
> *********************************************************************************************************
> On Oct 29, 2010, at 7:51 AM, Thiago Veronezi wrote:
> > Good catch, Mohammad.
> > I will try figureout a way to override the values from a ejb-jar.xml using
> > the system properties but with no special changes within the ejb-jar.xml. I
> > think I have an idea... let me see... thats going to be fun... :O)
> Excellent discussion. Great points on keeping the original descriptor intact.
> Our persistence.xml overriding follows that idea very strongly.
> I've wondered how we could do the same thing with overriding the ejb-jar.xml
> like we do properties in the persistence.xml. Not exactly apples to apples as
> the real data in the persistence.xml file is already properties and the data in
> an ejb-jar.xml is straight xml.
> Any kind of experimentation in this area is good. It directly relates to
> people being able to mock things in tests as well. Likely a lot of people who
> would love the feature.
> One approach I've kicked around in the back of my head is using xpath
> expressions to point to particular elements of the ejb-jar.xml so that they
> could be overridden. Downside is sometimes xpath is maybe a little complicated.
> Other thoughts involve maybe a simpler concept where maybe you can do something
> like
> <ejbName>.<property>=<value>
> Where <property> is some predetermined list of the most relevant things that
> someone would want to override. That could definitely work, though we do have
> an actual properties object associated with every ejb (it's right there in the
> BeanContext -- formerly called DeploymentInfo) which can be configured via the
> openejb-jar.xml file. Those properties typically override settings that are in
> the <Container> declaration. A good example is 'AccessTimeout' which can be
> specified in the Container declaration, in the openejb-jar.xml via properties,
> and now there's a standard javax.ejb.AccessTimeout annotation and ejb-jar.xml
> element. The relationship between all those (which wins, etc) is not really as
> clear as it could be. I suspect this happen more and more as we continue to
> standardize options which were typically only expressible in the vendor
> descriptor.
> Another idea is to possibly add some sort of "visitor" kind of callback api,
> whereby people could tinker with the JAXB tree we have that represents the
> ejb-jar.xml data. Kind of plug into the deployment system in a way. Something
> like that would run after the AnnotationDeployer so the JAXB tree they get
> represents 100% of the xml and annotation data and is then the final metadata
> we use for deployment. With a hook like that you could really do anything you
> wanted, including create properties based overriders and other kinds of
> "meta-data manipulators"
> Short answer is, I don't know :) But it's wonderful to have people thinking
> about it and willing to do some experimentation. Certainly would be a killer
> feature.
> Any progress in this area no matter how small is wonderful!
> -David
> >
> > On Thu, Oct 28, 2010 at 5:49 AM, Mohammad Nour El-Din <
> > nour.mohammad@xxxxxxxxx> wrote:
> >
> >> Hi Thiago...
> >>
> >> Brilliant idea :), but the problem is that will make the
> >> ejb-jar.xml not compliant with the stds, and hence if you wanted to
> >> use the same ejb-jar with some other AppSrvr/Cntnr you will have to
> >> modify it which breaks the very basic concept of having a standard DD.
> >> But this should be done from the OEJB side, like the property to
> >> specify which DP to use or any other mechanism provided or can be
> >> provided by OEJB.
> >>
> >> On Wed, Oct 27, 2010 at 5:24 PM, Thiago Veronezi <th...@xxxxxxxxxxxx>
> >> wrote:
> >>> Devs,
> >>>
> >>> A friend of mine just faced a configuration issue with openejb. He has
> >>> multiple clients (companies) and each client should use a custom
> >>> "ejb-jar.xml" with specific configuration values (some MDB
> >> configurations).
> >>> My advice to him was to create the ejb jar with multiples "ejb-jar.xml"
> >> and
> >>> then to use the "openejb.altdd.prefix" property to specify the file to be
> >>> used.
> >>>
> >>> I had an idea to make it more configurable, but I need your advice. What
> >> do
> >>> you think if we add a property like "*openejb.altdd.replace.<numeric
> >> value>*
> >>> "?
> >>> Imagine an ejb-jar.xml file like:
> >>>
> >>> <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"; version="3.0"
> >>> metadata-complete="false">
> >>> <enterprise-beans>
> >>> <session>
> >>> <ejb-name>MessageReaderImpl</ejb-name>
> >>> <env-entry>
> >>> <description>email user</description>
> >>>
> >>>
> >> <env-entry-name>embedded.applicationejb.ejb.service.impl.message.MessageReaderImpl/user</env-entry-name>
> >>> <env-entry-type>java.lang.String</env-entry-type>
> >>> <env-entry-value>*{0}*</env-entry-value>
> >>> </env-entry>
> >>> <env-entry>
> >>> <description>email password</description>
> >>>
> >>>
> >> <env-entry-name>embedded.applicationejb.ejb.service.impl.message.MessageReaderImpl/password</env-entry-name>
> >>> <env-entry-type>java.lang.String</env-entry-type>
> >>> <env-entry-value>*{1}*</env-entry-value>
> >>> </env-entry>
> >>> </session>
> >>> </enterprise-beans>
> >>> </ejb-jar>
> >>>
> >>> We could replace the values {0} and {1} by system properties like...
> >>> *openejb.altdd.replace.**0*=myUser
> >>> *openejb.altdd.replace.1*=aReallyGoodPassword
> >>>
> >>> This should be done when the system is reading the ejb-jar.xml file
> >> (Using
> >>> the MessageFormat utility class).
> >>> Here:
> >>>
> >> ***************************************************************************************************
> >>>
> >> /openejb-core/src/main/java/org/apache/openejb/config/ReadDescriptors.java
> >>>
> >>> public static EjbJar readEjbJar(URL url) throws OpenEJBException {
> >>> try {
> >>> if (isEmpty(url, "ejb-jar")) return new EjbJar();
> >>> return (EjbJar) JaxbJavaee.unmarshal(EjbJar.class,
> >>> url.openStream());
> >>> } catch (SAXException e) {
> >>> throw new OpenEJBException("Cannot parse the ejb-jar.xml file:
> >> "
> >>> + url.toExternalForm(), e);
> >>> } catch (JAXBException e) {
> >>> throw new OpenEJBException("Cannot unmarshall the ejb-jar.xml
> >>> file: " + url.toExternalForm(), e);
> >>> } catch (IOException e) {
> >>> throw new OpenEJBException("Cannot read the ejb-jar.xml file:
> >> "
> >>> + url.toExternalForm(), e);
> >>> } catch (Exception e) {
> >>> throw new OpenEJBException("Encountered unknown error parsing
> >>> the ejb-jar.xml file: " + url.toExternalForm(), e);
> >>> }
> >>> }
> >>>
> >> ***************************************************************************************************
> >>>
> >>> What do you think?
> >>>
> >>> thanks,
> >>> Thiago.
> >>>
> >>
> >>
> >>
> >> --
> >> Thanks
> >> - Mohammad Nour
> >> Author of (WebSphere Application Server Community Edition 2.0 User Guide)
> >> http://www.redbooks.ibm.com/abstracts/sg247585.html
> >> - LinkedIn: http://www.linkedin.com/in/mnour
> >> - Blog: http://tadabborat.blogspot.com
> >> ----
> >> "Life is like riding a bicycle. To keep your balance you must keep moving"
> >> - Albert Einstein
> >>
> >> "Writing clean code is what you must do in order to call yourself a
> >> professional. There is no reasonable excuse for doing anything less
> >> than your best."
> >> - Clean Code: A Handbook of Agile Software Craftsmanship
> >>
> >> "Stay hungry, stay foolish."
> >> - Steve Jobs
> >>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira