new feature: properties inside ejb-jar.xml

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

new feature: properties inside ejb-jar.xml

Thiago Veronezi
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.
Reply | Threaded
Open this post in threaded view
|

Re: new feature: properties inside ejb-jar.xml

Mohammad Nour El-Din
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: new feature: properties inside ejb-jar.xml

Thiago Veronezi
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)
tkx a lot,
Thiago.

On Thu, Oct 28, 2010 at 5:49 AM, Mohammad Nour El-Din <
[hidden email]> 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 <[hidden email]>
> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: new feature: properties inside ejb-jar.xml

dblevins
Administrator

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 <
> [hidden email]> 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 <[hidden email]>
>> 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
>>