[jira] [Updated] (OPENEJB-1393) override ejb-jar.xml using system properties

["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