Re: Error / Issue with OpenEJB 3.1.3 ?
Does that mean you noticed it as well ? -M On Fri, Oct 29, 2010 at 4:12 AM, David Blevins david.blev...@visi.com wrote: On Oct 27, 2010, at 10:34 AM, David Blevins wrote: On Oct 27, 2010, at 8:02 AM, Matthias Wessendorf wrote: Hi, I am seeing this error, when running OpenEJB 3.1.3 + OpenWebBeans + OpenJPA (2.x and 1.x) in Tomcat 6.x: org.apache.openjpa.persistence.ArgumentException: A JDBC Driver or DataSource class name must be specified in the ConnectionDriverName property. the persistence.xml is like: persistence-unit name=foobar providerorg.apache.openjpa.persistence.PersistenceProviderImpl/provider jta-data-sourcejava:openejb/Resource/My DataSource/jta-data-source non-jta-data-sourcejava:openejb/Resource/My UnmanagedDataSource/non-jta-data-source classnet.wessendorf.User/class properties property name=openjpa.Log value=DefaultLevel=TRACE / property name=openjpa.jdbc.SynchronizeMappings value=buildSchema(ForeignKeys=true) / /properties /persistence-unit /persistence With an older version, like OpenEJB 3.1.2 I was never seeing that error above.. and no, I never specified the ConnectionDriverName with the above (non-)jta-data-source settings. Am I missing some configuration, or is there an issue regarding this ? Not familiar with that error. If you can post some log output and the stacktrace that might shed some light. FYI, this one is on the radar for 3.1.4. Hopefully we can get to the bottom of it before we roll. -David -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: new feature: properties inside ejb-jar.xml
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
nour.moham...@gmail.com 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 thi...@veronezi.org
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-nameMessageReaderImpl/ejb-name
env-entry
descriptionemail user/description
env-entry-nameembedded.applicationejb.ejb.service.impl.message.MessageReaderImpl/user/env-entry-name
env-entry-typejava.lang.String/env-entry-type
env-entry-value*{0}*/env-entry-value
/env-entry
env-entry
descriptionemail password/description
env-entry-nameembedded.applicationejb.ejb.service.impl.message.MessageReaderImpl/password/env-entry-name
env-entry-typejava.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
Re: Error / Issue with OpenEJB 3.1.3 ?
On Oct 28, 2010, at 11:14 PM, Matthias Wessendorf wrote: Does that mean you noticed it as well ? No, more the head-scratching kind. We don't add any connection properties to persistence units, though I have had the opposite thought that one of these days we should write code that removes them if the user mistakenly adds them -- OpenJPA will ignore the connections we give it and try to create its own, which is bad. -David -M On Fri, Oct 29, 2010 at 4:12 AM, David Blevins david.blev...@visi.com wrote: On Oct 27, 2010, at 10:34 AM, David Blevins wrote: On Oct 27, 2010, at 8:02 AM, Matthias Wessendorf wrote: Hi, I am seeing this error, when running OpenEJB 3.1.3 + OpenWebBeans + OpenJPA (2.x and 1.x) in Tomcat 6.x: org.apache.openjpa.persistence.ArgumentException: A JDBC Driver or DataSource class name must be specified in the ConnectionDriverName property. the persistence.xml is like: persistence-unit name=foobar providerorg.apache.openjpa.persistence.PersistenceProviderImpl/provider jta-data-sourcejava:openejb/Resource/My DataSource/jta-data-source non-jta-data-sourcejava:openejb/Resource/My UnmanagedDataSource/non-jta-data-source classnet.wessendorf.User/class properties property name=openjpa.Log value=DefaultLevel=TRACE / property name=openjpa.jdbc.SynchronizeMappings value=buildSchema(ForeignKeys=true) / /properties /persistence-unit /persistence With an older version, like OpenEJB 3.1.2 I was never seeing that error above.. and no, I never specified the ConnectionDriverName with the above (non-)jta-data-source settings. Am I missing some configuration, or is there an issue regarding this ? Not familiar with that error. If you can post some log output and the stacktrace that might shed some light. FYI, this one is on the radar for 3.1.4. Hopefully we can get to the bottom of it before we roll. -David -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: new feature: properties inside ejb-jar.xml
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.moham...@gmail.com 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 thi...@veronezi.org
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-nameMessageReaderImpl/ejb-name
env-entry
descriptionemail user/description
env-entry-nameembedded.applicationejb.ejb.service.impl.message.MessageReaderImpl/user/env-entry-name
env-entry-typejava.lang.String/env-entry-type
env-entry-value*{0}*/env-entry-value
/env-entry
env-entry
descriptionemail password/description
env-entry-nameembedded.applicationejb.ejb.service.impl.message.MessageReaderImpl/password/env-entry-name
env-entry-typejava.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
