Re: @ApplicationException(rollback=true) ignored from external API
On Jun 25, 2008, at 9:38 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I run a test which provokes an application exception. The exception is defined in the same module and annotated with @ApplicationException(rollback=true). The Exception is rolled back. Fine. Another test checks also an exception. The exception is not from an EJB module, but from an imported API. The exception has the same annotation, but the transaction is not rolled back. It seams to me that the annotation in this class is ignored. We definitely don't check the annotations at runtime, simply because you can override them via the deployment descriptor so the merged set of meta data is the only safe thing to execute against at runtime (not if we expect to pass the tck anyway ;). But as you point out we just check the module itself for @ApplicationException annotated classes. Hmm... Is the annotated exception class listed in any of the throws clauses of the business interface methods in module B? (where module A has the exception class, module B does not) If so, we could expand our support to looking there too in addition to scraping the module jar. -David
Re: EJBContext cannot be injected in 3.1-SNAPSHOT
On Jun 27, 2008, at 7:24 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, I can inject the session context successfully with: @Resource private SessionContext ctx; But when I only what to have the EJBContext @Resource private EJBContext ctx; it cannot be injected. Is this intended? Well, SessionContext is fine, but I was wondering why the super interface cannot be injected. In general, we don't check isAssignable on injection types, primarily cause it gets very hairy around business interfaces. But we could probably support this particular use case. -David
Re: AW: @ApplicationException(rollback=true) ignored from external API
I think there was something with the binaries I published. Had to clean out all the old snapshots and redeploy to a clean repo before I could get the updates to come down. Try it again. (clean out the openejb section of your repo for good measure). -David On Jun 27, 2008, at 8:45 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: No, does not work. See the attached sample project. In the API is the annotated ServiceAddressException class. But the unit tests fails. Regards, Karsten -Ursprüngliche Nachricht- Von: David Blevins [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 27. Juni 2008 07:32 An: users@openejb.apache.org Betreff: Re: @ApplicationException(rollback=true) ignored from external API On Jun 25, 2008, at 4:42 PM, Karsten Ohme wrote: David Blevins schrieb: On Jun 25, 2008, at 9:38 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I run a test which provokes an application exception. The exception is defined in the same module and annotated with @ApplicationException(rollback=true). The Exception is rolled back. Fine. Another test checks also an exception. The exception is not from an EJB module, but from an imported API. The exception has the same annotation, but the transaction is not rolled back. It seams to me that the annotation in this class is ignored. We definitely don't check the annotations at runtime, simply because you can override them via the deployment descriptor so the merged set of meta data is the only safe thing to execute against at runtime (not if we expect to pass the tck anyway ;). But as you point out we just check the module itself for @ApplicationException annotated classes. I don't have them annotated in the deployment descriptor. This would be very uncomfortable, because each module which uses the exception from the other module would have to do this. Agree, that would be an unnecessary pain. Hmm... Is the annotated exception class listed in any of the throws clauses of the business interface methods in module B? Yes, it is. (where module A has the exception class, module B does not) If so, we could expand our support to looking there too in addition to scraping the module jar. Would be nice. Ok. Implemented that technique. Should you decide to override the app exception in the deployment descriptor of module B, for example, that will work too. New 3.1-SNAPSHOT binaries have been published. Give it a try and let us know if it works out. -David applicationexceptiontest.zip
Re: Timestamp ignored
Hi Julia,
OpenEJB is an EJB implementation itself, like JBoss. If you're
willing to give OpenEJB a try we can definitely see if we can help you
get your code running.
-David
On Jun 30, 2008, at 3:06 PM, Julia O wrote:
Hi,
I am using jboss 4.2.0 GA and MySQL 5.0. And cannot get a timestamp to
persist to the database.
I have an @Entity bean with 3 fields: boolean, int. and
java.sql.Timestamp.
Everything persists except for the timestamp. In fact, i added some
trace
statements and the getter method for my timestamp is never being
accessed.
Here is what my getter looks like:
@Id
@Temporal(TemporalType.TIMESTAMP)
@Column(name=report_timestamp)
public Timestamp getReportTimestamp()
{
m_log_.info(RETURNING TIMESTAMP + m_reportTimetamp);
return m_reportTimetamp;
}
The field maps to a column in mysql database called report_timestamp
of type
DATETIME. I also used TIMESTAMP without any progress. The persistance
manager keeps inserting nulls into that column.
Additionally, i tried the following mysql drivers in my jboss
configuration:
mysql-connector-java-5.0.8-bin.jar and mysql-connector-java-5.1.6-
bin.jar.
Any help would be greatly appreciated.
--
View this message in context:
http://www.nabble.com/Timestamp-ignored-tp18205416p18205416.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: ClassCastException on JNDI lookup
On Jul 8, 2008, at 8:47 AM, chawax wrote: And two interfaces, generated everytime too : - @javax.ejb.Local interface EmployeeServiceLocal extends EmployeeService - interface EmployeeService [...] I also have a ejb-jar.xml file with EJB defined as following : session ejb-nameEmployeeServiceBean/ejb-name localt4.core.employee.EmployeeServiceLocal/local ejb-classt4.core.employee.EmployeeServiceBean/ejb-class session-typeStateless/session-type transaction-typeContainer/transaction-type /session The issue is local must refer to interfaces that extend javax.ejb.EJBLocalObject, i.e. the old style EJB 2.x interfaces. You just need to update your descriptor to use the business-local element instead as in: session ejb-nameEmployeeServiceBean/ejb-name business-localt4.core.employee.EmployeeServiceLocal/business- local ejb-classt4.core.employee.EmployeeServiceBean/ejb-class session-typeStateless/session-type transaction-typeContainer/transaction-type /session That should fix the issue. Alternatively, you can let the annotation do the work and leave EmployeeServiceLocal out of your ejb-jar.xml entirely. I'm surprised you didn't get a validation failure. We aggressively check for all sorts of possible mistakes, such as using business- local where local should be used or using local where local- home should be used, etc. You just happened to find one we didn't check for :) Looks like a pretty important one too! We will definitely add it for the next release. Thanks in advance for your help ;) No problem! And congratulations for the good job made on OpenEJB. I tried to use other embedded containers (JBoss Embedded, Glassfish embedded, EJB3Unit, ...) and met so many bugs I could not make them work. I am not far to succeed with Open EJB ! Thank you very much for the positive feedback, we definitely appreciate it. -David
Re: EJBContext cannot be injected in 3.1-SNAPSHOT
On Jul 5, 2008, at 2:06 PM, Jacek Laskowski wrote: On Fri, Jun 27, 2008 at 10:33 PM, David Blevins [EMAIL PROTECTED] wrote: In general, we don't check isAssignable on injection types, primarily cause it gets very hairy around business interfaces. But we could probably support this particular use case. I think we have to as 16.15 EJBContext References is pretty clear on it: The container must make a component's EJBContext interface available either through injection using the Resource annotation or in JNDI under the name java:comp/EJBContext. The authenticationType and shareable elements of the Resource annotation must not be specified. and further on: The Bean Provider is responsible for requesting injection of an EJBContext object using a Resource annotation or using the defined name to lookup the EJBContext object. and finally: The Container Provider is responsible for providing an appropriate EJBContext object to the referencing component. The object returned must be of the appropriate specific type for the bean requesting injection or performing the lookup—that is, the container provider must return an instance of the SessionContext interface to referencing session beans and an instance of the MessageDrivenContext interface to message-driven beans. When the spec says a component's EJBContext interface or an appropriate EJBContext it's referring to SessionContext, MessageDrivenContext or EntityContext specifically. It isn't a requirement that @Resource EJBContext be injectable, but we can certainly support it as a feature. -David
Re: PersistenceContext and Hibernate session
Hi Olivier,
This document may help you understand how things work from a high level.
http://cwiki.apache.org/OPENEJBx30/jpa-concepts.html
The section of bullet points for With persistence-unit transaction-
type=TRANSACTION has a good description of what's going on. When
reading it, in your mind substitute every occurrence of
PersistenceContext/Cache with HibernateEntityManager instance.
-David
On Jul 11, 2008, at 8:55 AM, Dain Sundstrom wrote:
JtaEntityManager is a wrapper around the raw EntityManager instance
we get from the JPA provider. JtaEntityManager performs the task
required by the EJB spec such as committing the flushing the JPA
data at the end of the transaction and assuring that all access to
the same persistence unit in a transaction uses the same raw
EntityManager. You can get access to the raw underlying
EntityManager by calling getDelegate(), but be careful. You should
not cache the results of getDelegate() as the raw EntityManager
instance will change for each transaction. You'll want to do
something like this:
@javax.persistence.PersistenceContext(unitName = t4Seam)
protected javax.persistence.EntityManager emanager;
public HibernateEntityManager getHibernateSession() {
return (HibernateEntityManager) emanager.getDelegate();
}
public void doIt() {
getHibernateSession().doSomething();
}
-dain
On Jul 11, 2008, at 8:09 AM, chawax wrote:
I tried this :
protected org.hibernate.ejb.HibernateEntityManager emanager;
@javax.persistence.PersistenceContext(unitName = t4Seam)
public void setEntityManager(javax.persistence.EntityManager
entityManager) {
this.emanager = (org.hibernate.ejb.HibernateEntityManager)
entityManager;
}
But I have a ClassCastException :
java.lang.ClassCastException:
org.apache.openejb.persistence.JtaEntityManager
Is there a place where I could configure the entity manager to use
Hibernate
one instead of OpenEJB one ?
--
View this message in context:
http://www.nabble.com/PersistenceContext-and-Hibernate-session-tp18404318p18406052.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Problem with HelloWorld
On Jul 15, 2008, at 10:35 AM, Andrej Trifkovic wrote: Hi, I have a problem with OpenEJB. I try to run HelloWorld example in Eclipse with standalone OpenEJB and I get message like this : /HelloBeanRemote does not exist in the system. Check that the app was successfully deployed. In addition I send you openejb.log. Thanks for the log! Looks like the hello.jar was found, but there doesn't appear to be any EJBs in it. Can you run this command on the command line and send the output: jar tvf C:\openejb-3.0\apps\hello.jar You should see something like: 0 Sat Jul 12 16:47:06 PDT 2008 META-INF/ 127 Sat Jul 12 16:47:04 PDT 2008 META-INF/MANIFEST.MF 0 Sat Jul 12 16:47:04 PDT 2008 org/ 0 Sat Jul 12 16:47:04 PDT 2008 org/acme/ 0 Sat Jul 12 16:47:04 PDT 2008 org/acme/ 10 Sat Jul 12 16:47:04 PDT 2008 META-INF/ejb-jar.xml 168 Sat Jul 12 16:47:04 PDT 2008 org/acme/Hello.class 275 Sat Jul 12 16:47:04 PDT 2008 org/acme/HelloBean.class -David
Re: PersistenceContext and Hibernate session
On Jul 15, 2008, at 6:11 AM, chawax wrote:
I finally could make it work with JBoss AS ... but it doesn't work
the same
as Open EJB !
On JBoss AS the getDelegate method returns Hibernate session, while it
returns Hibernate entity manager on Open EJB.
Congrats, glad you got it to work in both platforms!
So to make it work, I made
this :
protected javax.persistence.EntityManager emanager;
protected org.hibernate.Session hibernateSession;
@javax.persistence.PersistenceContext(unitName = t4Seam)
public void setEntityManager(javax.persistence.EntityManager
entityManager) {
this.emanager = entityManager;
if (entityManager.getDelegate() instanceof
org.hibernate.ejb.HibernateEntityManager) {
this.hibernateSession =
((org.hibernate.ejb.HibernateEntityManager)
entityManager.getDelegate()).getSession();
}
else {
this.hibernateSession = (org.hibernate.Session)
entityManager.getDelegate();
}
}
So I have a question : which one is right with this, Open EJB or
JBoss AS ?
Or maybe the JPA specifications are not clear about this, so there
can be
different implementations for this method ?
The spec simply says The result of this method is implementation
specific. So either version is valid strictly speaking.
On that note, we could add a flag that would have our getDelegate()
detect if it's hibernate and return the hibernate session if that
would make your life easier.
-David
Re: ClassCastException on JNDI lookup
On Jul 9, 2008, at 2:34 AM, chawax wrote: Yes, that was the problem ! I replaced local with business-local and everything works perfect now ! Thanks a lot David. Looks like we did have some validation logic in there for checking usage of the remote and local elements, but it only kicked in if you also specify the related home or local-home interface. I've fixed that and also made the code check for this very specific mistake and issue an appropriate message. We now have about 44 different error messages we're prepared to issue in regards to misuse of either the home, remote, local-home, local, business- local and business-remote elements. That should be enough :) -David David Blevins wrote: The issue is local must refer to interfaces that extend javax.ejb.EJBLocalObject, i.e. the old style EJB 2.x interfaces. You just need to update your descriptor to use the business-local element instead as in: session ejb-nameEmployeeServiceBean/ejb-name business-localt4.core.employee.EmployeeServiceLocal/business- local ejb-classt4.core.employee.EmployeeServiceBean/ejb-class session-typeStateless/session-type transaction-typeContainer/transaction-type /session That should fix the issue. Alternatively, you can let the annotation do the work and leave EmployeeServiceLocal out of your ejb-jar.xml entirely. -- View this message in context: http://www.nabble.com/ClassCastException-on-JNDI-lookup-tp18342366p18357709.html Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Problem with openjpa enhancer - using runtime enhancement
I wonder if this is simply an issue that the Entity classes are loaded *before* OpenEJB starts and is able to hand the persistence.xml data to OpenJPA. If there are imports for the Entities in the TestCase then this is likely what's happening. You might try moving the test code around a bit to see if you can't separate the bootstrapping of OpenEJB (and thus OpenJPA) from the code that consumes the Entities. Putting the OpenEJB bits in a super class to the TestCase might work. Or maybe putting the test bits in an inner class. -David On Jul 17, 2008, at 1:40 AM, Gareth Davies wrote: Kevin, This is the trace output from our build with all the OpenJPA options set to TRACE and RuntimeUnenhancedClasses set to unsupported, it looks like it finds the classes but fails to enhance any of them. One slightly odd thing about this is that it mentions that it is scanning the resources META-INF/orm.xml for persistent types but this file doesn't exist, all the persistent types are listed in the persistence.xml file, I don't know if this has any significance. I have also put in the test report from the initial test case that fails. Thanks Gareth *** Build *** 575 warehouse TRACE [main] openjpa.jdbc.JDBC - t 22413802, conn 18248114 [2 ms] close 643 warehouse TRACE [main] openjpa.MetaData - Scanning resource META-INF/orm.xml for persistent types. 645 warehouse TRACE [main] openjpa.MetaData - parsePersistentTypeNames() found [com.par.impl.HandheldDevice, com.par.impl.AbstractMessage, com.par.impl.AssetMessage, com.par.impl.Product, com.par.impl.TrainingQualification, com.par.impl.HandheldMessageType, com.par.impl.LiveTableColumn, com.par.impl.ClientNote, com.par.impl.BusinessFormInstance, com.par.impl.ObjectGroup, com.par.impl.LiveTable, com.par.impl.ClientModificationRecord, com.par.impl.Location, com.par.impl.Category, com.par.impl.Asset, com.par.impl.LocationType, com.par.impl.Department, com.par.impl.TemperatureReading, com.par.impl.AssetTransport, com.par.impl.Permission, com.par.impl.AssetReservation, com.par.impl.ObjectForm, com.par.impl.TemperatureDevice, com.par.impl.Domain, com.par.impl.SearchFormElement, com.par.impl.Client, com.par.impl.AccessCategory, com.par.impl.WarehouseRoleUser, com.par.impl.UserTrainingQualification, com.par.impl.HandheldMessage, com.par.impl.AssetLocation, com.par.impl.ClientAddress, com.par.impl.ObjectElement, com.par.impl.SearchForm, com.par.impl.DomainRoleUser, com.par.impl.Country, com.par.impl.BusinessFormAnswer, com.par.impl.BusinessForm, com.par.impl.ActionMessage, com.par.impl.UserDetails, com.par.impl.SpecialRequirement, com.par.impl.AssetStorageRule, com.par.impl.JobTitle, com.par.impl.SystemConstant, com.par.impl.Role, com.par.impl.AssetSerialNumber, com.par.impl.WarehouseProductPriceHistory, com.par.impl.User, com.par.impl.ObjectElementType, com.par.impl.HandheldSession, com.par.impl.AssetFate, com.par.impl.AccessRight, com.par.impl.AssetMessageType, com.par.impl.AssetType, com.par.impl.BusinessFormQuestion, com.par.impl.SystemMessageType, com.par.impl.RoleUser, com.par.impl.SystemMessage]. 661 warehouse TRACE [main] openjpa.MetaData - Found 58 classes with metadata in 23 milliseconds. 17:00:11 INFO [com.par.impl.SearchFormPersistenceTestCase] - Testing query... 17:00:12 INFO [com.par.impl.SearchFormPersistenceTestCase] - Unable to complete test case testSearchFormElement openjpa-1.1.0-r422266:659716 nonfatal user error org.apache.openjpa.persistence.ArgumentException: An error occurred while parsing the query filter Select searchFormElement from SearchFormElement searchFormElement. Error message: The name Search FormElement is not a recognized entity or identifier. Known entity names: [] at org .apache.openjpa.kernel.exps.AbstractExpressionBuilder.parseException( AbstractExpressionBuilder.java:118) at org .apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JP QLExpressionBuilder.java:180) at org .apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaDat a(JPQLExpressionBuilder.java:150) at org .apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaDat a(JPQLExpressionBuilder.java:225) at org .apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaDat a(JPQLExpressionBuilder.java:195) at org .apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(JP QLExpressionBuilder.java:188) at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access $600(JPQLExpr essionBuilder.java:69) at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder $ParsedJPQL.populate (JPQLExpressionBuilder.java:1754) at org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:56) at org .apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation(E xpressionStoreQuery.java:153) at org.apache.openjpa.kernel.QueryImpl.newCompilation(QueryImpl.java:657) at
Re: Stateless Pool and Stateful Pool Timeouts
On Jul 17, 2008, at 5:29 AM, the666pack wrote: Hello, i have a question regarding timeout values in openejb as the documentation is somewhat sparse: the timeout for the stateless pool is defined as: Specifies the time to wait between invocations. This value is measured in milliseconds. A value of 5 would result in a time-out of 5 milliseconds between invocations. A value of zero would mean no timeout. what exactly does the default value 0 now mean? It looks like that value is no longer used. It used to configure the amount of time a thread should block while waiting for a instance from the pool when strict pooling is used. Zero was meant to imply wait for as long as it takes, i.e. indefinitely. Agree that description is terrible. The code was updated between 3.0-beta-2 and 3.0 final to fix the enforcement of the StrictPooling option. Looks like the timeout got left out of that refactor. We definitely should update the code to use the configurable timeout again. the timeout for the stateful pool is defined as: Specifies the time to wait between invocations. This value is measured in minutes. A value of 5 would result in a time-out of 5 minutes between invocations. A value of zero would mean no timeout. is this the time before the bean is passivated or is this timeout before the bean gets removed from the container? It's the amount of inactive time to wait until the bean instance is destroyed. A value of zero would mean bean instances are never destroyed due to timeout. Passivation is triggered when reaching the PoolSize. At that point, the BulkPassivate value defines how many instances (oldest first) we will remove from the pool and passivate to disk. Afterwards the number of active instances will be X where 'X = PoolSize - BulkPassivate' We will definitely clean up those docs. Thanks for asking for clarification! -David
Re: need help getting quartz-ra.rar file to deploy
On Jul 18, 2008, at 5:09 PM, endium wrote: Thanks for your response. Right now I am using openejb embedded for unit testing. Is there a way to configure the inbound resource adapter without deploying an ear? In that case, give our latest snapshots a try. We added support to basically say treat my classpath as an ear, in which case you'd still get the same effect I described. If you're using maven, just update your openejb version to 3.1- SNAPSHOT. If you're using a server distro, this should work: http://people.apache.org/repo/m2-snapshot-repository/org/apache/openejb/openejb-standalone/3.1-SNAPSHOT/openejb-standalone-3.1-20080719.020443-5.zip -David David Blevins wrote: On Jul 18, 2008, at 7:50 AM, endium wrote: I am using JBoss' Quartz integration on one of my projects: http://wiki.jboss.org/wiki/QuartzSchedulerIntegration This works fine in a JBoss environment, however I haven't been able to figure out how to configure openejb to replicate this behavior. Is it possible to use openejb to use inbound resource adapters? We definitely do support inbound resource adapters. If you package that rar file and your ejb jar file into an ear and deploy it, everything should get auto configured and created for you and your MDBs hooked up to the resource adapter. -David -- View this message in context: http://www.nabble.com/need-help-getting-quartz-ra.rar-file-to-deploy-tp18531000p18539712.html Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: need help getting quartz-ra.rar file to deploy
On Jul 20, 2008, at 10:05 AM, endium wrote: I'm using maven. Do I need the openejb-core or openejb-standalone? Should be just openejb-core. The openejb-standalone pom has a handful of client/server related dependencies which you don't need for unit testing. Using openejb-core, it seems to be configuring and loading the rar, but later it's giving a ClassNotFoundException for the quartz activation spec: java.lang.ClassNotFoundException: org.jboss.resource.adapter.quartz.inflow.QuartzActivationSpec I'm setting my properties like this: properties.setProperty(Default MDB Container.MessageListenerInterface, org.quartz.Job); properties.setProperty(Default MDB Container.ActivationSpecClass, org.jboss.resource.adapter.quartz.inflow.QuartzActivationSpec); That looks right. I tried manually adding the activation spec class to the build path and I got this: javax.resource.NotSupportedException: That type of ActicationSpec not supported: class org.jboss.resource.adapter.quartz.inflow.QuartzActivationSpec Can't seem to find any code that throws that exception. Can you post the stack trace? -David David Blevins wrote: On Jul 18, 2008, at 5:09 PM, endium wrote: Thanks for your response. Right now I am using openejb embedded for unit testing. Is there a way to configure the inbound resource adapter without deploying an ear? In that case, give our latest snapshots a try. We added support to basically say treat my classpath as an ear, in which case you'd still get the same effect I described. If you're using maven, just update your openejb version to 3.1- SNAPSHOT. If you're using a server distro, this should work: http://people.apache.org/repo/m2-snapshot-repository/org/apache/openejb/openejb-standalone/3.1-SNAPSHOT/openejb-standalone-3.1-20080719.020443-5.zip -David David Blevins wrote: On Jul 18, 2008, at 7:50 AM, endium wrote: I am using JBoss' Quartz integration on one of my projects: http://wiki.jboss.org/wiki/QuartzSchedulerIntegration This works fine in a JBoss environment, however I haven't been able to figure out how to configure openejb to replicate this behavior. Is it possible to use openejb to use inbound resource adapters? We definitely do support inbound resource adapters. If you package that rar file and your ejb jar file into an ear and deploy it, everything should get auto configured and created for you and your MDBs hooked up to the resource adapter. -David -- View this message in context: http://www.nabble.com/need-help-getting-quartz-ra.rar-file-to-deploy-tp18531000p18539712.html Sent from the OpenEJB User mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/need-help-getting-quartz-ra.rar-file-to-deploy-tp18531000p18556369.html Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: need help getting quartz-ra.rar file to deploy
org.jboss.resource.adapter.quartz.inflow.QuartzActivationSpec: That type of ActicationSpec not supported: class org.jboss.resource.adapter.quartz.inflow.QuartzActivationSpec: javax.resource.NotSupportedException: That type of ActicationSpec not supported: class org.jboss.resource.adapter.quartz.inflow.QuartzActivationSpec: That type of ActicationSpec not supported: class org.jboss.resource.adapter.quartz.inflow.QuartzActivationSpec at org .apache .openejb.assembler.classic.EjbJarBuilder.deploy(EjbJarBuilder.java:75) at org .apache .openejb .assembler.classic.Assembler.createApplication(Assembler.java:548) ... 32 more Caused by: org.apache.openejb.OpenEJBException: javax.resource.NotSupportedException: That type of ActicationSpec not supported: class org.jboss.resource.adapter.quartz.inflow.QuartzActivationSpec: That type of ActicationSpec not supported: class org.jboss.resource.adapter.quartz.inflow.QuartzActivationSpec at org.apache.openejb.core.mdb.MdbContainer.deploy(MdbContainer.java:146) at org .apache .openejb.assembler.classic.EjbJarBuilder.deploy(EjbJarBuilder.java:73) ... 33 more Caused by: javax.resource.NotSupportedException: That type of ActicationSpec not supported: class org.jboss.resource.adapter.quartz.inflow.QuartzActivationSpec at org .apache .activemq .ra .ActiveMQResourceAdapter .endpointActivation(ActiveMQResourceAdapter.java:217) at org.apache.openejb.core.mdb.MdbContainer.deploy(MdbContainer.java:139) ... 34 more David Blevins wrote: On Jul 20, 2008, at 10:05 AM, endium wrote: I'm using maven. Do I need the openejb-core or openejb-standalone? Should be just openejb-core. The openejb-standalone pom has a handful of client/server related dependencies which you don't need for unit testing. Using openejb-core, it seems to be configuring and loading the rar, but later it's giving a ClassNotFoundException for the quartz activation spec: java.lang.ClassNotFoundException: org.jboss.resource.adapter.quartz.inflow.QuartzActivationSpec I'm setting my properties like this: properties.setProperty(Default MDB Container.MessageListenerInterface, org.quartz.Job); properties.setProperty(Default MDB Container.ActivationSpecClass, org .jboss.resource.adapter.quartz.inflow.QuartzActivationSpec); That looks right. I tried manually adding the activation spec class to the build path and I got this: javax.resource.NotSupportedException: That type of ActicationSpec not supported: class org.jboss.resource.adapter.quartz.inflow.QuartzActivationSpec Can't seem to find any code that throws that exception. Can you post the stack trace? -David David Blevins wrote: On Jul 18, 2008, at 5:09 PM, endium wrote: Thanks for your response. Right now I am using openejb embedded for unit testing. Is there a way to configure the inbound resource adapter without deploying an ear? In that case, give our latest snapshots a try. We added support to basically say treat my classpath as an ear, in which case you'd still get the same effect I described. If you're using maven, just update your openejb version to 3.1- SNAPSHOT. If you're using a server distro, this should work: http://people.apache.org/repo/m2-snapshot-repository/org/apache/openejb/openejb-standalone/3.1-SNAPSHOT/openejb-standalone-3.1-20080719.020443-5.zip -David David Blevins wrote: On Jul 18, 2008, at 7:50 AM, endium wrote: I am using JBoss' Quartz integration on one of my projects: http://wiki.jboss.org/wiki/QuartzSchedulerIntegration This works fine in a JBoss environment, however I haven't been able to figure out how to configure openejb to replicate this behavior. Is it possible to use openejb to use inbound resource adapters? We definitely do support inbound resource adapters. If you package that rar file and your ejb jar file into an ear and deploy it, everything should get auto configured and created for you and your MDBs hooked up to the resource adapter. -David -- View this message in context: http://www.nabble.com/need-help-getting-quartz-ra.rar-file-to-deploy-tp18531000p18539712.html Sent from the OpenEJB User mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/need-help-getting-quartz-ra.rar-file-to-deploy-tp18531000p18556369.html Sent from the OpenEJB User mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/need-help-getting-quartz-ra.rar-file-to-deploy-tp18531000p18558694.html Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: need help getting quartz-ra.rar file to deploy
(RemoteTestRunner.java: 196) Caused by: org.apache.openejb.OpenEJBException: Error deploying 'TimerJob'. Exception: class org.apache.openejb.OpenEJBException: Deployment 'TimerJob' has message listener interface org.quartz.Job but this MDB container only supports interface javax.jms.MessageListener: Deployment 'TimerJob' has message listener interface org.quartz.Job but this MDB container only supports interface javax.jms.MessageListener at org .apache .openejb.assembler.classic.EjbJarBuilder.deploy(EjbJarBuilder.java:75) at org .apache .openejb .assembler.classic.Assembler.createApplication(Assembler.java:548) ... 32 more Caused by: org.apache.openejb.OpenEJBException: Deployment 'TimerJob' has message listener interface org.quartz.Job but this MDB container only supports interface javax.jms.MessageListener at org.apache.openejb.core.mdb.MdbContainer.deploy(MdbContainer.java:119) at org .apache .openejb.assembler.classic.EjbJarBuilder.deploy(EjbJarBuilder.java:73) ... 33 more David Blevins wrote: Ok. On second thought, try removing these two parameters: properties.setProperty(Default MDB Container.MessageListenerInterface, org.quartz.Job); properties.setProperty(Default MDB Container.ActivationSpecClass, org .jboss.resource.adapter.quartz.inflow.QuartzActivationSpec); We should be auto-creating an MDB container and ResourceAdapter specifically for the in-bound connector. What happened here is that the properties for the Default MDB Container where changed for Quartz (listener interface and activationspec) but it's still pointing to the ActiveMQ ResourceAdapter. If you delete these two lines then we'll safely determine that there is no MDB container configured to handle the MessageListenerInterface of your MDB and one will be created using your Quartz ResourceAdapter. -David On Jul 20, 2008, at 1:55 PM, endium wrote: ERROR - Application could not be deployed: /Users/Hoshi/Documents/Programming/Hibernate/DaoProjectOpenEjb/ target/classes org.apache.openejb.OpenEJBException: Creating application failed: /Users/Hoshi/Documents/Programming/Hibernate/DaoProjectOpenEjb/ target/classes: Error deploying 'TimerJob'. Exception: class org.apache.openejb.OpenEJBException: javax.resource.NotSupportedException: That type of ActicationSpec not supported: class org.jboss.resource.adapter.quartz.inflow.QuartzActivationSpec: That type of ActicationSpec not supported: class org.jboss.resource.adapter.quartz.inflow.QuartzActivationSpec: javax.resource.NotSupportedException: That type of ActicationSpec not supported: class org.jboss.resource.adapter.quartz.inflow.QuartzActivationSpec: That type of ActicationSpec not supported: class org.jboss.resource.adapter.quartz.inflow.QuartzActivationSpec at org .apache .openejb .assembler.classic.Assembler.createApplication(Assembler.java:601) at org .apache .openejb .assembler.classic.Assembler.buildContainerSystem(Assembler.java: 342) at org.apache.openejb.assembler.classic.Assembler.build(Assembler.java: 259) at org.apache.openejb.OpenEJB$Instance.init(OpenEJB.java:149) at org.apache.openejb.OpenEJB.init(OpenEJB.java:291) at org.apache.openejb.OpenEJB.init(OpenEJB.java:270) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun .reflect .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun .reflect .DelegatingMethodAccessorImpl .invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java: 36) at org .apache .openejb .client .LocalInitialContextFactory.init(LocalInitialContextFactory.java:63) at org .apache .openejb .client .LocalInitialContextFactory.init(LocalInitialContextFactory.java:51) at org .apache .openejb .client .LocalInitialContextFactory .getInitialContext(LocalInitialContextFactory.java:40) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java: 667) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java: 247) at javax.naming.InitialContext.init(InitialContext.java:223) at javax.naming.InitialContext.init(InitialContext.java:197) at com.example.openejb.OpenEjbTest.setInitialContext(OpenEjbTest.java: 63) at com .example .service.ItemServiceTest.setUpBeforeClass(ItemServiceTest.java:25) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun .reflect .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun .reflect .DelegatingMethodAccessorImpl .invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.ClassRoadie.runBefores(ClassRoadie.java: 49) at org
Re: Web Service WSDL Location
On Jul 24, 2008, at 3:12 PM, endium wrote: I am doing some unit testing using web services. I tried following the example web service project as a guide. I am getting: Caused by: javax.wsdl.WSDLException: WSDLException: faultCode=PARSER_ERROR: Problem parsing 'http://localhost:4204/ZipCodeWidget?wsdl'.: java.net.ConnectException: Connection refused: connect I think this is because I am specifying the wrong wsdl location. I have no idea really what to specify, from the example project it looks like the default is the name of the webservice implementation class. That's not working for me though. Can you post your test case? Also, definitely make sure you keep the properties.setProperty(openejb.embedded.remotable, true); line from the example. -David
Re: embeding OpenEJB into WAR
On Jul 28, 2008, at 7:59 AM, Petr Pudlák wrote: Hi, I was searching through OpenEJB documentation, but I wasn't able to find an answer to my question: Is it possible to embed OpenEJB into a pure servlet application (so that I get EJBs, persistence, etc.) without installing OpenEJB in advance? I sucessfully used OpenEJB with the Tomcat plug-in, that works very nice. But best would be if I could create a single WAR that would contain everything and that could be simply deployed into Tomcat (or another container) without installing anything. Is this possible? Does anybody have an experience with it? We used to have that exact feature in OpenEJB 1.0, but we temporarily retired it as it isn't clear how to support some of the features like servlet dependency injection. I.e. you could package OpenEJB inside your war and have your own private EJB container inside the webapp. It would be possible to readd something like that and fully support EJBs in an embedded scenario like the one you describe, but the servlet side of things would more or less remain as is. The servlets would be able to look up ejbs and the ejbs themselves would have full support for JPA, JMS, WebServices, etc. but servlets would be plain servlets. This could be fine if you delegate most the work to ejbs. Would something like that be useful to you? -David
Re: need help getting quartz-ra.rar file to deploy
Ok. Finally got something working here. New zip available at http// issues.apache.org/jira/secure/attachment/12387373/quartz-app.zip Inside you'll see: . ./pom.xml ./quartz-beans ./quartz-beans/pom.xml ./quartz-beans/src ./quartz-beans/src/main ./quartz-beans/src/main/java ./quartz-beans/src/main/java/com ./quartz-beans/src/main/java/com/example ./quartz-beans/src/main/java/com/example/job ./quartz-beans/src/main/java/com/example/job/TimerJob.java ./quartz-beans/src/main/resources ./quartz-beans/src/main/resources/log4j.properties ./quartz-beans/src/test ./quartz-beans/src/test/java ./quartz-beans/src/test/java/com ./quartz-beans/src/test/java/com/example ./quartz-beans/src/test/java/com/example/job ./quartz-beans/src/test/java/com/example/job/QuartzMdbTest.java ./quartz-ra ./quartz-ra/pom.xml ./quartz-ra/src ./quartz-ra/src/main ./quartz-ra/src/main/resources ./quartz-ra/src/main/resources/META-INF ./quartz-ra/src/main/resources/META-INF/ra.xml ./quartz-ra.jar ./README.txt For some reason, Maven refuses to add .rar files to the test classpath. A .rar file is just a jar that contains other jars and a META-INF/ra.xml file, so I went ahead and created a maven module that has the ra.xml file and lists the appropriate jars as dependencies. All the jars were available online except the jar containing the JBoss Quartz Resource Adapter classes, so that jar has to be installed into your local maven repo manually (see the README.txt for the command). Last but not least, here is the maven test output for the quartz-beans module: --- T E S T S --- Running com.example.job.QuartzMdbTest 14:31:05,103 DEBUG QuartzMdbTest:19 - Set Initial Context Apache OpenEJB 3.1-SNAPSHOTbuild: 20080801-09:26 http://openejb.apache.org/ INFO - openejb.home = /private/tmp/work/quartz-app/quartz-beans INFO - openejb.base = /private/tmp/work/quartz-app/quartz-beans INFO - Configuring Service(id=Default Security Service, type=SecurityService, provider-id=Default Security Service) INFO - Configuring Service(id=Default Transaction Manager, type=TransactionManager, provider-id=Default Transaction Manager) INFO - Found EjbModule in classpath: /private/tmp/work/quartz-app/ quartz-beans/target/classes INFO - Found ConnectorModule in classpath: /private/tmp/work/quartz- app/quartz-ra/target/quartz-ra-0.0.1-SNAPSHOT.jar INFO - Beginning load: /private/tmp/work/quartz-app/quartz-beans/ target/classes INFO - Beginning load: /private/tmp/work/quartz-app/quartz-ra/target/ quartz-ra-0.0.1-SNAPSHOT.jar INFO - Extracting jar: /private/tmp/work/quartz-app/quartz-ra/target/ quartz-ra-0.0.1-SNAPSHOT.jar INFO - Extracted path: /private/tmp/work/quartz-app/quartz-ra/target/ quartz-ra-0.0.1-SNAPSHOT INFO - Configuring enterprise application: classpath.ear INFO - Configuring Service(id=quartz-ra-0.0.1-SNAPSHOT.jarRA, type=Resource, provider-id=quartz-ra-0.0.1-SNAPSHOT.jarRA) INFO - Configuring Service(id=quartz-ra-0.0.1-SNAPSHOT.jar- org.quartz.Job, type=Container, provider-id=Default MDB Container) INFO - Configuring Service(id=quartz-ra-0.0.1-SNAPSHOT.jar- org.quartz.StatefulJob, type=Container, provider-id=Default MDB Container) INFO - Enterprise application classpath.ear loaded. INFO - Assembling app: classpath.ear INFO - start quartz!!! DEBUG - endpointActivation, spec=jobName=job. 0.1217626266122,jobGroup=default,triggerName=trigger. 1.1217626266122,triggerGroup=default,cronTrigger=0/2 * * * * ? volatilityfalsedurabilityfalserecoverablefalse DEBUG - adding job: jobName=job. 0.1217626266122,jobGroup=default,triggerName=trigger. 1.1217626266122,triggerGroup=default,cronTrigger=0/2 * * * * ? volatilityfalsedurabilityfalserecoverablefalse INFO - Created Ejb(deployment-id=TimerJob, ejb-name=TimerJob, container=quartz-ra-0.0.1-SNAPSHOT.jar-org.quartz.Job) INFO - Deployed Application(path=classpath.ear) Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.084 sec Results : Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 Let us know how things go for you. If there's anything you'd like changed in how things work, feel free to make requests. -David
Re: Propblem with OpenEJB + Toplink unit tests
On Aug 4, 2008, at 2:49 AM, Marcin Kwapisz wrote: Hi, Configuration: OpenEJB 3.0, ToplinkEssentials 2.1, Maven2, JUnit 4, Derby 10.2.2 I have modified that example - http://openejb.apache.org/3.0/testing-transactions-example.html to use Toplink as persistence provider. The problem is, that Toplink does not persists entities at all. With OpenJPA or Hibernate all work fine. As You may see below, sequences are updated properly. [TopLink Finest]: 2008.08.04 11:17:31.359--ServerSession(13948523)-- Thread(Thread[main,5,main])--end deploying Persistence Unit barPU; state Deployed; factoryCount 1 [TopLink Finer]: 2008.08.04 11:17:31.406--ServerSession(13948523)-- Thread(Thread[main,5,main])--client acquired [TopLink Finest]: 2008.08.04 11:17:31.406--UnitOfWork(19780920)-- Thread(Thread[main,5,main])--Execute query DoesExistQuery() [TopLink Finest]: 2008.08.04 11:17:31.406--UnitOfWork(19780920)-- Thread(Thread[main,5,main])--PERSIST operation called on: pl.zsk.samples.ejbaccess.entities.Person[id=null;Marcin]. [TopLink Finest]: 2008.08.04 11:17:31.406--ClientSession(9876930)-- Thread(Thread[main,5,main])--Execute query DataModifyQuery() [TopLink Finest]: 2008.08.04 11:17:31.406--ClientSession(9876930)-- Thread(Thread[main,5,main])--reconnecting to external connection pool [TopLink Fine]: 2008.08.04 11:17:31.406--ClientSession(9876930)-- Connection(7789321)--Thread(Thread[main,5,main])--UPDATE SEQUENCE SET SEQ_COUNT = SEQ_COUNT + ? WHERE SEQ_NAME = ? bind = [50, PERSONENT] [TopLink Finest]: 2008.08.04 11:17:31.421--ClientSession(9876930)-- Thread(Thread[main,5,main])--Execute query ValueReadQuery() [TopLink Fine]: 2008.08.04 11:17:31.421--ClientSession(9876930)-- Connection(7789321)--Thread(Thread[main,5,main])--SELECT SEQ_COUNT FROM SEQUENCE WHERE SEQ_NAME = ? bind = [PERSONENT] [TopLink Finest]: 2008.08.04 11:17:31.421--ClientSession(9876930)-- Connection(7789321)--Thread(Thread[main,5,main])--local sequencing preallocation for PERSONENT: objects: 50 , first: 1, last: 50 [TopLink Finest]: 2008.08.04 11:17:31.421--UnitOfWork(19780920)-- Thread(Thread[main,5,main])--assign sequence to the object (1 - pl.zsk.samples.ejbaccess.entities.Person[id=null;Marcin]) 2008-08-04 11:17:31 pl.zsk.samples.ejbservice.AccountEntBeanTest testCreatePersonEnt INFO: Get Persons from Database. [TopLink Finest]: 2008.08.04 11:17:31.531--UnitOfWork(19780920)-- Thread(Thread[main,5,main])--Execute query ReportQuery(pl.zsk.samples.entities.PersonEnt) [TopLink Finest]: 2008.08.04 11:17:31.546--ServerSession(13948523)-- Thread(Thread[main,5,main])--reconnecting to external connection pool [TopLink Fine]: 2008.08.04 11:17:31.546--ServerSession(13948523)-- Connection(13305839)--Thread(Thread[main,5,main])--SELECT ID, FIRSTNAME, LASTNAME FROM PERSONENT [] 2008-08-04 11:17:31 pl.zsk.samples.ejbservice.AccountEntBeanTest testCreatePersonEnt INFO: [] When I call flush just after persist I get the EJBException: javax.ejb.EJBException: The bean encountered a non-application exception.; nested exception is: javax.ejb.EJBTransactionRolledbackException: The transaction has been marked rollback only because the bean encountered a non- application exception :javax.persistence.TransactionRequiredException : Exception Description: No transaction is currently active This is strange. Why transaction does not begin? Any suggestions how to configure Toplink to make it work. Thanks in advance It may be that TopLink doesn't know how to find our TransactionManager. OpenJPA finds it automatically by calling org.apache.openejb.OpenEJB.getTransactionManager(). For Hibernate, there's the TransactionManagerLookup which can be configured. Do you know if there's anything similar in TopLink? -David
Re: Propblem with OpenEJB + Toplink unit tests
On Aug 4, 2008, at 5:45 AM, Marcin Kwapisz wrote:
It may be that TopLink doesn't know how to find our
TransactionManager. OpenJPA finds it automatically by calling
org.apache.openejb.OpenEJB.getTransactionManager(). For Hibernate,
there's the TransactionManagerLookup which can be configured. Do you
know if there's anything similar in TopLink?
[Marcin Kwapisz]
Thanks David for the hint.
There is such feature and similar problem (solution also) is
described here:
http://forums.oracle.com/forums/thread.jspa?threadID=625250tstart=0messageID=2390496
and here:
http://www.jroller.com/guruwons/entry/use_glassfish_java_persistence_provider
The only one thing I had to find was TransactionManager jndi name:
java:comp/TransactionManager
public class OpenEJBTransactionController extends
JTATransactionController
{
public static final String JNDI_TRANSACTION_MANAGER_NAME =
java:comp/TransactionManager;
public OpenEJBTransactionController()
{
super();
}
@Override
protected TransactionManager acquireTransactionManager() throws
Exception
{
return (TransactionManager)
jndiLookup(JNDI_TRANSACTION_MANAGER_NAME);
}
}
and in persistence.xml
property name=toplink.target-server
value=pl.zsk.samples.ejbservice.OpenEJBTransactionController/
Fantastic, thank you!
Added some features for you and other TopLink/EclipseLink users. We
now generate an implement of JTATransactionController and will
automatically set the target-server property if we determine you are
using the TopLink or EclipseLink providers.
http://issues.apache.org/jira/browse/OPENEJB-880
http://issues.apache.org/jira/browse/OPENEJB-881
So when 3.1 comes out, you shouldn't need to set the toplink.target-
server property anymore and will be able to dump your custom
OpenEJBTransactionController, though it will continue to work if you
want to use it (i.e. we won't override the property if we see you've
set it to a custom class).
Sort of a conceptual copy of what we did for hibernate:
http://issues.apache.org/jira/browse/OPENEJB-801
-David
Re: Shutdown an embedded instance of OpenEJB programatically
On Aug 4, 2008, at 5:41 AM, Martin Vysny wrote:
On Sat, 2008-08-02 at 15:23 -0700, David Blevins wrote:
On Jul 30, 2008, at 12:34 AM, Martin Vysny wrote:
Hello,
currently we are starting OpenEJB as an embedded service (by
performing a lookup of
org.apache.openejb.client.LocalInitialContextFactory in JNDI
InitialContext). Is there a way to perform a clean shutdown of this
embedded instance? We are using OpenEJB in testing environment and I
need to shutdown OpenEJB cleanly, for example to stop uncanceled
timers.
Hi Martin,
If you don't mind being tied to some OpenEJB code you could try
something like this:
import org.apache.openejb.loader.SystemInstance;
import org.apache.openejb.assembler.classic.Assembler;
import org.apache.openejb.assembler.classic.AppInfo;
import org.apache.openejb.OpenEJB;
public class Shutdown {
public static void shutdown() throws Exception {
Assembler assembler =
SystemInstance.get().getComponent(Assembler.class);
for (AppInfo appInfo : assembler.getDeployedApplications()) {
assembler.destroyApplication(appInfo.jarPath);
}
OpenEJB.destroy();
}
}
We could probably wrap this up into a better package and allow it to
be called from the initialContext.close() method so you don't have to
have any OpenEJB code in your test case.
Let me know if this does the trick for you and we'll get the cleaner
version in.
-David
Hi David,
thanks for the solution, it works for me! The timers are canceled
correctly in our project now. However the shutdown code is not perfect
yet. Out of curiosity I tried the following scenario: start OpenEJB,
stop it and start it again in the same VM. The following exception was
thrown:
[stacktrace attachment]
This is probably just a corner case (I can't imagine why would anyone
need to start, stop and start the OpenEJB again in same VM :), it's
just
for the sake of completeness.
Thanks, Martin! I'll definitely get that issue cleaned up.
In fact, we are adding a close() method to the EJB 3.1 API version
(getting a good embeddable EJB container requirement into the EJB 3.1
spec is one of my top priorities), so this is good feedback. You're
right on the bleeding edge! :)
My thoughts for adding a close() method was basically for @Singleton
beans as the @PreDestroy method is only called when the container is
shutdown, but canceling timers is definitely another good reason. If
you see it mentioned in the EJB 3.1 spec, you can know definitively
you're responsible :)
-David
Re: Propblem with OpenEJB + Toplink unit tests
Marcin, Do you happen to know what the TopLink property is for automatically creating all the required tables? In OpenJPA it's: property name=openjpa.jdbc.SynchronizeMappings value=buildSchema(ForeignKeys=true)/ In Hibernate it's: property name=hibernate.hbm2ddl.auto value=create-drop/ -David
Re: Shutdown an embedded instance of OpenEJB programatically
On Aug 5, 2008, at 12:36 AM, Martin Vysny wrote: On Mon, 2008-08-04 at 15:44 -0700, David Blevins wrote: Thanks, Martin! I'll definitely get that issue cleaned up. David, I must thank you, for your quick answers and solutions! It's really a pleasure to work with OpenEJB being backed by such a good helpdesk :-) Thank you! It's users like you who make things better for everyone. Each question and request helps pave the way for future users. Case in point, I'm pretty sure you were the first person to ask about getting OpenEJB 3.0 beta 1 and Hibernate working together. Every current and future OpenEJB/Hibernate user owes you thanks in one form or another. No small contribution. In fact, we are adding a close() method to the EJB 3.1 API version (getting a good embeddable EJB container requirement into the EJB 3.1 spec is one of my top priorities), so this is good feedback. You're right on the bleeding edge! :) This is most interesting! Do you mean that all heavyweight J2EE servers (which are to be compliant to EJB 3.1) will be available as embeddable containers as well? Exactly. Pretty amazing isn't it? When we launched OpenEJB off as an embeddable EJB container years ago we never dreamed that it would cause this kind of a change. We couldn't be more excited or more proud. My thoughts for adding a close() method was basically for @Singleton beans as the @PreDestroy method is only called when the container is shutdown, but canceling timers is definitely another good reason. If you see it mentioned in the EJB 3.1 spec, you can know definitively you're responsible :) Wow, I might get my salary increased :-p Let's hope so :) Course I'll expect a beer in return. -David
Re: Lazy fields issue with Hibernate/OpenEJB
On Aug 6, 2008, at 10:28 AM, Dain Sundstrom wrote: I believe this this the JIRA for the issue: https://jira.jboss.org/jira/browse/EJBTHREE-440 It appears that Hibernate requires a custom ObjectInputStream to work properly. They claim the root cause is this VM bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4171142 It seems strange that is could be the cause of the bug. David, what do you think? We did have that bug in 3.0 final. It's since been fixed: http://issues.apache.org/jira/browse/OPENEJB-832 http://svn.apache.org/viewvc?view=revrevision=672429 (the fix) http://svn.apache.org/viewvc?view=revrevision=672444 (the tests) Sami, what version of the openejb-client.jar are you using? -David On Aug 6, 2008, at 9:53 AM, Sami Jaber wrote: Hi all, I try to get the couple JPA(Hibernate) and OpenEJB works with an application that uses lazy fields in Pojo. My application is pretty simple, I have an inheritance and some lazy fields are declared FetchMode.LAZY. When I run a client remotely, i get the same error before any call : javax.ejb.EJBException: Unknown Container Exception: java.rmi.RemoteException: Error reading response from server (OEJP/ 3.0) : cannot assign instance of org.hibernate.proxy.pojo.javassist.SerializableProxy to field mypackage.Pojo.controleur of type mypackage.domain.user.User in instance of mypackage.OtherPojo; nested exception is: java.lang.ClassCastException: cannot assign instance of org.hibernate.proxy.pojo.javassist.SerializableProxy to field mypackage.Pojo.controleur of type mypackage.domain.user.User in instance of mypackage.OtherPojo OtherPojo inherits from Pojo. With all kind of combination (remotable=true, local-copy/true or false, ), switching to cglib-javaassist, I get desperately the same exception. Note that with LocalInitialContext, all works perfectly. As soon as I run cross JVM calls thru RemoteInitialContext, it hangs. My problem is very close to this issue : http://www.jboss.com/index.html?module=bbop=viewtopict=76737postdays=0postorder=ascstart=0 any clue? this is very frustrating ... Or, if anybody can provide me with a test case that makes OpenEJB and Hibernate work with lazy fields, i would really appreciate Sami ps : here is my server stacktrace when the error raises 2008-08-06 18:39:02,975 - FATAL - Couldn't write EjbResponse to output stream java.net.SocketException: Software caused connection abort: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java: 136) at java.io.ObjectOutputStream $BlockDataOutputStream.drain(ObjectOutputStream.java:1838) at java.io.ObjectOutputStream $BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1747) at java .io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java: 1249) at java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java: 1203) at java .io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java: 1387) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) at java .io.ObjectOutputStream.writeFatalException(ObjectOutputStream.java: 1538) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:329) at org .apache.openejb.client.EJBResponse.writeExternal(EJBResponse.java: 133) at org .apache .openejb .server .ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:215) at org .apache .openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:164) at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:122) at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:84) at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:60) at org.apache.openejb.server.ServicePool $2.run(ServicePool.java:78) at org.apache.openejb.server.ServicePool $3.run(ServicePool.java:101) at java.util.concurrent.ThreadPoolExecutor $Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor $Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619)
Re: Configure OpenEJB Container to use external activemq.xml file
On Aug 7, 2008, at 6:48 AM, rde8026 wrote: Hi David, Thanks for the reply. I've tried using the fully qualified path and I get the same exception - Failed to startup an embedded broker: openejb:xbean:(D:/opt/openejb-3.0/lib/activemq.xml)? persistent=false, due to: org.springframework.beans.factory.BeanDefinitionStoreException: Could not resolve bean definition resource pattern [(D:/opt/openejb-3.0/lib/activemq.xml)?persistent=false]; nested exception is java.io.FileNotFoundException: class path resource [(D:/opt/openejb-3.0/lib/] cannot be resolved to URL because it does not exist I'm curious do you know if anyone has successfully gotten this to work or is it a bug? Any ideas would be much appreciated. I think I've tried this before, but I could be imagining things. Looking at the exception though, it seems that we might need to make the path a valid URL. Try this one: file:///D:/opt/openejb-3.0/lib/activemq.xml If that doesn't work, post your activemq.xml (or some version of it) and I'll give it a try. If that *does* work, then we can add examples as well as wrap this activemq functionality with something that tries harder to make things work and gives a better error message when they can't. -David David Blevins wrote: On Aug 6, 2008, at 12:47 PM, rde8026 wrote: I've been trying to get the openEJB container to allow me to use an external activemq.xml file for a while now and have been unsuccessful. Below is my resource config Resource id=ActiveMQRA type=ActiveMQResourceAdapter # Broker configuration URI as defined by ActiveMQ # see http://activemq.apache.org/broker-configuration-uri.html #BrokerXmlConfig broker:(tcp://localhost:61616)?useJmx=false BrokerXmlConfig xbean:activemq.xml # Broker address #ServerUrl vm://localhost?async=true ServerUrl tcp://localhost:61616 # DataSource for persistence messages DataSource MessageDataStore /Resource With the activemq.xml file placed in the lib directory Hmmm... Try using an absolute path to the activemq.xml file and see if that doesn't make activemq happier. Not sure if that will work, but worth a try. -David -- View this message in context: http://www.nabble.com/Configure-OpenEJB-Container-to-use-external-activemq.xml-file-tp18858260p18870919.html Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Problem between OpenEJB embedded threading model and Swing Threading model
We can certainly hack up something in this regard.
Quick question, what kind of security tracking would be good for you?
I.e. are we talking concurrent users or one user at a time?
We've got some code in the openejb-client package that's pretty useful
for switching to different modes of tracking the user and I was just
thinking just the other day that it wouldn't be a bad idea to port it
to the server side as well for embedded scenarios.
Also, I assume this is sort of wrapped up in the other two security
related posts. If not, let me now if there's something more specific
I should be looking at there.
-David
On Aug 7, 2008, at 10:24 AM, Sami Jaber wrote:
Hello all (once more :-)),
After the deployments.ear property and the custom ObjectInputStream,
I have
found another issue which is IMHO more annoying, maybe a structural
design
problem that David will resolve for sure ;-).
I have a pretty big Swing Application that relies on OpenEJB over a
remote
mode (integration platform) and local mode (dev platform).
After digging into the openejb source code (I find them really well
coded
btw), it appear that over LocalInitialContextFactory, the user context
(security, tx, ...) is hold on the ThreadLocal. Not sure but it
seems to be
done in the ClientSecurity.java class thru this code :
public static void login(String username, String password, boolean
threadScoped) throws FailedLoginException {
Object clientIdentity = directAuthentication(username,
password,
server);
if (threadScoped) {
threadClientIdentity.set(clientIdentity);
} else {
staticClientIdentity = clientIdentity;
}
identityResolver = new SimpleIdentityResolver();
}
The problem is that with Swing Application (or any multi-threaded
front-end), you cannot assume that the thread that initiates the new
InitialContext() is the one that will be used to lookup. In my case
I have
implemented (as every smart boy ;-)) a smart proxy pattern which
consist in
keeping the context in a singleton and reusing it between calls. The
issue
is that the lookup is made inside a Swing Action, the Event Thread
Dispatcher raises a new Thread and all credential information are
lost.
That's why in my previous message, I told you that I get randomly
guest as
the getCallerPrincipal().
The fix would have been to instantiate a new InitialContext for every
lookup, but not only it kills the performance but you get also an
error
message saying that you cannot assign twice the ThreadLocal.
The last solution that works for me is to write that code for each
lookup,
this is ugly but it does the job :
public static void setInitialContext()
{
try
{
context = new InitialContext(env);
}
catch (Exception e)
{
// if TLS exists Ignore the exception, otherwise, it will set
a new
one in the current thread
}
}
David ?
Sami
OT: Facebook group if you're interested
Totally off-topic and non-critical, but there's a facebook group if you'd like to join up: http://www.new.facebook.com/group.php?gid=2658865898 -David
Re: Custom Resource Factory
On Aug 8, 2008, at 11:11 AM, lupu.slobodu wrote: Here it is what I've been trying: 1)Resource Factory configuration in tomcat context.xml Resource name=bean/ParamsFactory auth=Container type=sample.jndi.ResourceBean factory=sample.jndi.GenericObjectFactory value=ContextResource / 2)test web application's web.xml resource-env-ref description Object factory for ResourceBean instances. /description resource-env-ref-name bean/ParamsFactory /resource-env-ref-name resource-env-ref-type sample.jndi.ResourceBean /resource-env-ref-type /resource-env-ref I can look it up successfully from a servlet like this Context initCtx = new InitialContext(); Context envCtx = (Context) initCtx.lookup(java:comp/env); ResourceBean bean = (ResourceBean) envCtx.lookup(bean/ ParamsFactory); The same look up fails when performed inside a session bean. I tried to integrate the declarations in the openejb web module web.xml descriptor also but with no success. If you can look it up from a Servlet, we're not too far! Post the ejb- jar.xml you using if you can. You would need an identical resource- env-ref in there for your session bean. -David
Re: OpenEJB 3.0.1 release date
I really really hope we can get something released in the next 2-3 weeks. -David On Aug 11, 2008, at 6:41 AM, Martin Vysny wrote: Hi guys, can you please tell me when the 3.0.1 is planned to be released? (preferable with fixed bug: https://issues.apache.org/jira/browse/OPENEJB-806 :-) Thanks, Martin
Re: MDB
On Aug 11, 2008, at 10:29 AM, lupu.slobodu wrote: Trying to run the MDB sample form http://svn.apache.org/viewvc/openejb/trunk/openejb3/examples/simple-mdb-with-descriptor/?pathrev=678070 It looks up the ConnectionFactory but it crashes when calling connectionFactory.createConnection(); javax.jms.JMSException: Could not create Transport. Reason: java.io.IOException: Transport scheme NOT recognized: [vm] . . . Caused by: java.lang.ClassCastException: org.apache.activemq.transport.vm.VMTransportFactory cannot be cast to org.apache.activemq.transport.TransportFactory I'm unable to get this error, but I suspect that there might have been an issue with the maven 2 snapshot repository. I cleaned it out and rebuilt it and think things might be better now. I ran the example successfully with a completely clean repo like so: $ cd examples/simple-mdb-with-descriptor $ mkdir temp-repo $ mvn clean install -Dmaven.repo.local=temp-repo Everything downloaded fine and the example ran without issues. -David
Re: need help getting quartz-ra.rar file to deploy
On Aug 12, 2008, at 9:28 AM, endium wrote: Thanks for this David! For some reason, I didn't get an email notifying me of your reply. I am trying to implement this right now. Was the maven configuration for openejb changed at all? This may be an unrelated problem, but since today it doesn't seem that maven is correctly identifying all of the dependencies. I am getting this error: java.lang.NoClassDefFoundError: org/apache/openejb/loader/ OpenEJBInstance at org .apache .openejb .client .LocalInitialContextFactory.init(LocalInitialContextFactory.java:59) at org .apache .openejb .client .LocalInitialContextFactory.init(LocalInitialContextFactory.java:51) at org .apache .openejb .client .LocalInitialContextFactory .getInitialContext(LocalInitialContextFactory.java:40) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java: 667) I just ran into this error myself trying to reproduce a different issue. It seems the maven 2 snapshot repo got corrupted on people.apache.org. I've just finished rebuilding the openejb section of the repo and things look much better now. You may need to remove part of your local maven repo (the repository/org/apache/openejb part) to get a clean build from the snapshots. One way to try without having to delete anything is to build with a temporary empty repo like so: $ mkdir temp-repo $ mvn clean install -Dmaven.repo.local=temp-repo -David
Re: Custom Resource Factory
That definitely should work. Let me see if I can't reproduce this. -David On Aug 12, 2008, at 1:45 PM, lupu.slobodu wrote: If I declare my session bean in ejb-jar.xml, together with the resource-env-ref like this session ejb-nameCalculatorImpl/ejb-name business-localsample.CalculatorLocal/business-local ejb-classsample.CalculatorImpl/ejb-class transaction-typeContainer/transaction-type resource-env-ref description Object factory for MyBean instances. /description resource-env-ref-name bean/ParamsFactory /resource-env-ref-name resource-env-ref-type sample.jndi.ResourceBean /resource-env-ref-type /resource-env-ref /session it crashes at deploy time like this: org.apache.openejb.OpenEJBException: No provider available for resource-ref 'null' of type 'sample.jndi.ResourceBean' for 'CalculatorImpl'. at org .apache.openejb.config.AutoConfig.autoCreateResource(AutoConfig.java: 1292) at org.apache.openejb.config.AutoConfig.getResourceId(AutoConfig.java: 1285) at org.apache.openejb.config.AutoConfig.getResourceId(AutoConfig.java: 1236) at org .apache.openejb.config.AutoConfig.processResourceRef(AutoConfig.java: 781) at org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:706) at org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:133) at org.apache.openejb.config.ConfigurationFactory $Chain.deploy(ConfigurationFactory.java:148) at org .apache .openejb .config .ConfigurationFactory.configureApplication(ConfigurationFactory.java: 440) at org .apache .openejb .tomcat.catalina.TomcatWebAppBuilder.start(TomcatWebAppBuilder.java: 233) at org .apache .openejb .tomcat .catalina .GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:58) at org .apache .catalina .util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) at org.apache.catalina.core.StandardContext.start(StandardContext.java: 4252) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java: 1045) at org.apache.catalina.core.StandardHost.start(StandardHost.java:719) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java: 1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java: 516) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:578) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) David Blevins wrote: On Aug 8, 2008, at 11:11 AM, lupu.slobodu wrote: Here it is what I've been trying: 1)Resource Factory configuration in tomcat context.xml Resource name=bean/ParamsFactory auth=Container type=sample.jndi.ResourceBean factory=sample.jndi.GenericObjectFactory value=ContextResource / 2)test web application's web.xml resource-env-ref description Object factory for ResourceBean instances. /description resource-env-ref-name bean/ParamsFactory /resource-env-ref-name resource-env-ref-type sample.jndi.ResourceBean /resource-env-ref-type /resource-env-ref I can look it up successfully from a servlet like this Context initCtx = new InitialContext(); Context envCtx = (Context) initCtx.lookup(java:comp/env); ResourceBean bean = (ResourceBean) envCtx.lookup(bean/ ParamsFactory); The same look up fails when performed inside a session bean. I tried to integrate the declarations in the openejb web module web.xml descriptor also but with no success. If you can look it up from a Servlet, we're not too far! Post the ejb- jar.xml you using if you can. You would need an identical resource- env-ref in there for your session bean. -David -- View this message in context: http://www.nabble.com/Custom-Resource-Factory-tp18852971p18952298.html Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Externalize db access data for junit-testing
Hi Per,
On Aug 12, 2008, at 2:38 AM, Newgro wrote:
first thanks to the openejb team for this great product. It helps
alot for
ejb3. Wiki pages and forum support are great.
Thanks! A very large percent of the docs come straight from the list,
so a big thanks to all the people with questions/requests. It's very
appreciated.
But i would like to externalize these parameters to an xml or
properties
file.
Is there a way to put my datasources to a place where openejb is
come along
automatically? My tries to add them to openejb.xml failed.
Documentation
point would help to (If this is already in the wiki - didn't found a
paper).
Sure, try this. Create an openejb.xml file in any directory that gets
added to your test classpath. For maven, something that winds up
directly under target/classes/ or target/test-classes/ will work
just fine. Then in your test case do this:
protected void setUp() throws Exception {
Properties properties = new Properties();
properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,
org.apache.openejb.client.LocalInitialContextFactory);
URL config =
this.getClass().getClassLoader().getResource(openejb.xml);
properties.setProperty(openejb.configuration,
config.toExternalForm());
initialContext = new InitialContext(properties);
}
The file itself doesn't have to be called openejb.xml, you could
have a few different files like that for different testing scenarios
each with a name that describes the basic setup.
-David
Re: Quality Improvement [Virus checked]
Moved this to the dev list.
On Aug 12, 2008, at 2:08 AM, [EMAIL PROTECTED] wrote:
Hi List,
I am not sure, the following will concern all of you. On the other
hand, I
expect some of the developers listening here. Also this may be a known
issue.
The problem is when running a test using eclipse maven, the results
differ, depending on the location in the file system.
A BLANK (' ') in the file location (e.g.: of the configuration)
makes the
difference.
This is not new, but nevertheless often forgotten:
There is a difference between URL and URI: a URL must mask BLANKS
(with '%20'). A well formed file location is NOT a well formed URL!
A file location can be converted to an URL: file.toURI().toURL()
which yields something like 'file:/C:/openejb.xml'.
You have to catch (MalformedURLException e) in this case.
Eclipse file search on openejb3 source code (677505) found 51
occurences of 'toURL()' and only 1 toURI().toURL().
Is this totally wacko? Any comemnts ?
Can I help ?
Is this fixed in some version ? Is it gonna be fixed ?
Is it feature ?
mit freundlichen Grüßen/best regards
Wolfgang Schrecker
In mathematics, to exist is to be construed.
from Shapiro: The Oxford Handbook of PHILOSOPHY OF MATHEMATICS AND
LOGIC S.
19
--
--
Atos Worldline Processing GmbH
Hahnstrasse 25
60528 Frankfurt/Main
Germany
Phone: +49 69/6657-1176
mailto:[EMAIL PROTECTED]
http://www.atosworldline.com
Geschäftsführer: Erik Munk Koefoed
Aufsichtsratsvorsitzender: Didier Dhennin
Sitz der Gesellschaft: Frankfurt/Main
Handelsregister: Frankfurt/Main HRB 40 417
--
Atos Worldline Processing GmbH
Hahnstraße 25
60528 Frankfurt/Main
Germany
Phone: +49 69/6657-1176
Fax :
mailto: [EMAIL PROTECTED]
http://www.atosworldline.com
Geschäftsführer: Erik Munk Koefoed
Aufsichtsratsvorsitzender: Didier Dhennin
Sitz der Gesellschaft: Frankfurt/Main
Handelsregister: Frankfurt/Main HRB 40 417
* * * * * * * * L E G A LD I S C L A I M E R * * * * * * * *
This e-mail is destined for the above mentioned recipient. In case you
received this e-mail by accident, we would appreciate it if you could
contact the sender and delete all copies stored on your computer.
Please be aware that the security and confidentiality of electronic
data
transmitted by e-mail is not completely guaranteed and that data may
be seen,
copied, downloaded or changed by third persons during transmission.
Atos Origin accepts no liability for the security and
confidentiality of
data and documents sent by e-mail. Please make sure that all important
messages will be confirmed in writing by means of a telefax or a
letter.
* * * * * * * * L E G A LD I S C L A I M E R * * * * * * * *
Re: MDB
On Aug 13, 2008, at 12:52 PM, lupu.slobodu wrote: I had the activemq jars in my web application also(WebContent/WEB- INF/lib). As soon as I took them out, it works fine. Sorry to have you spend time on this... No problem. This is a good note for the lists. I bet we could scan the webapp classloader and look for issues like this. Not sure we can get it in for the next release, but I bet that might be a useful timesaver. -David David Blevins wrote: On Aug 11, 2008, at 10:29 AM, lupu.slobodu wrote: Trying to run the MDB sample form http://svn.apache.org/viewvc/openejb/trunk/openejb3/examples/simple-mdb-with-descriptor/?pathrev=678070 It looks up the ConnectionFactory but it crashes when calling connectionFactory.createConnection(); javax.jms.JMSException: Could not create Transport. Reason: java.io.IOException: Transport scheme NOT recognized: [vm] . . . Caused by: java.lang.ClassCastException: org.apache.activemq.transport.vm.VMTransportFactory cannot be cast to org.apache.activemq.transport.TransportFactory I'm unable to get this error, but I suspect that there might have been an issue with the maven 2 snapshot repository. I cleaned it out and rebuilt it and think things might be better now. I ran the example successfully with a completely clean repo like so: $ cd examples/simple-mdb-with-descriptor $ mkdir temp-repo $ mvn clean install -Dmaven.repo.local=temp-repo Everything downloaded fine and the example ran without issues. -David -- View this message in context: http://www.nabble.com/MDB-tp18930176p18970017.html Sent from the OpenEJB User mailing list archive at Nabble.com.
User Blog: Toplink as your OpenEJB Persistence Provider
Quintin Beukes wrote up a great blog entry on setting up Toplink as the persistence provider for OpenEJB 3.0. http://qbeukes.blogspot.com/2008/08/toplink-as-your-openejb-persistence.html -David
Re: Shutdown an embedded instance of OpenEJB programatically
On Aug 2, 2008, at 3:23 PM, David Blevins wrote: We could probably wrap this up into a better package and allow it to be called from the initialContext.close() method so you don't have to have any OpenEJB code in your test case. Ok. I implemented the initialContext.close() logic. It only works on the InitialContext, calling close on any subcontexts will do nothing. As well it only works on the initialContext that booted OpenEJB, subsequent initialContext only refer to the already booted OpenEJB and therefore have to authority/ability to shutdown the container. Give it a try if you get the chance. New snapshots are being uploaded as we speak. I have noticed an ActiveMQ shutdown issue (doesn't fully shutdown so restart is not possible), but aside from that it should be pretty functional. -David
Re: Problem between OpenEJB embedded threading model and Swing Threading model
On Aug 7, 2008, at 5:42 PM, David Blevins wrote: We can certainly hack up something in this regard. Quick question, what kind of security tracking would be good for you? I.e. are we talking concurrent users or one user at a time? We've got some code in the openejb-client package that's pretty useful for switching to different modes of tracking the user and I was just thinking just the other day that it wouldn't be a bad idea to port it to the server side as well for embedded scenarios. Ok... Hacked on this quite a bit and got something working that should suit your needs. It essentially changes the per-thread login module to default to a new per-vm login model. This only affects logging into an embedded container, clients accessing a container remotely (RemoteInitialContextFactory) have these models and more as in the past. I investigated a per-InitialContext security-tracking method for clients of an embeddable container. This is possible to do, but a little tricky as there is no clear way to sandbox a set of proxies to an InitialContext. VM-scoped and thread-scoped are far easier. I've also removed the limitation that you cannot login twice via an InitialContext on the same thread. As well I've added the ability for the InitialContext.close() method to log you out if that InitialContext instance performed a login when it was created. New 3.1-SNAPSHOTs are available in http://people.apache.org/repo/m2-snapshot-repository/ as well as built a new server image at: http://people.apache.org/repo/m2-snapshot-repository/org/apache/openejb/openejb-standalone/3.1-SNAPSHOT/openejb-standalone-3.1-20080821.003247-2.zip In addition, I also hacked up a new example showing the improved LocalInitialContext login/logout functionality: http://svn.apache.org/repos/asf/openejb/trunk/openejb3/examples/testing-security-2/ Let us know how things look on your end and we can make any tweaks you need. -David
Re: Web Admin for OpenEJB3
On Aug 18, 2008, at 2:39 AM, Nithiraj wrote: I'm a new user to OpenEJB3. Can some one here please let me know where I can get the webadmin module for OpenEjb3? I'm not sure what state it's in for the standalone server. However there's nearly an identical copy of it in the Tomcat integration's openejb.war file. The version 3.0 has some limitations which have all been fixed in the latest code. You can pull down a snapshot copy here: http://people.apache.org/repo/m2-snapshot-repository/org/apache/openejb/openejb-tomcat-webapp/3.1-SNAPSHOT/openejb-tomcat-webapp-3.1-20080 821.003247-2.war Just make sure you rename it to openejb.war before you deploy it so all the documentation will match up. -David
Docs: EJB 3.1 Singleton documentation
All, We've implemented the new EJB 3.1 javax.ejb.Singleton bean type. Singletons are a new type of Session bean being added to the EJB 3.1 specification. They provide some much needed functionality to the world of EJB and will be part of the coming OpenEJB 3.1 release. http://openejb.apache.org/singleton-beans.html http://openejb.apache.org/singleton-example.html Enjoy the first ever @Singleton bean implementation! A large part of our motivation for implementing this early is to gather feedback for the specification itself. This is one of those rare times where you can not only give feedback about our implementation but about the actual API as well! Give it a try and let us know what you think! -David Example source code: svn co http://svn.apache.org/repos/asf/openejb/trunk/openejb3/examples/simple-singleton/
Re: Docs: EJB 3.1 Singleton documentation
Hi Martin, On Aug 25, 2008, at 4:33 AM, Martin Vysny wrote: Hi David, impressive work indeed, thank you very much! I am especially grateful for the Singleton and Startup functionality which I missed. Thanks! It's definitely great to have a standard way to do this in the EJB world. I have one question: in your example (the ComponentRegistryBean example) a simple HashMap is used which is thread unsafe. Does that mean that only a single thread (the one which created the bean) will access the bean? Nope, that's not it - multiple threads can access methods with Lock.READ. What does the specification say about the thread safety/multithreading issues? Must the bean be thread-safe or container will mark all methods as synchronized? Can the user code rely on some locking mechanisms (or invariants) performed by the container (for example, will Lock.WRITE always perform lock on the bean class?) Sorry if it is a dumb question and I'm missing something obvious :) Good feedback. Thank you for sending it! Clearly my explanation is not doing what it should :) I do see a bug too now that I look closer, too. The getComponents() method should return a copy of components.values() or someone could get a ConcurrentModificationException. I've changed/expanded on the text in the example. Pasted it here below as well. Let me know if it's any better. We'll keep trying till we get something that's easy to understand and doesn't leave the reader with a bunch of questions. Unless specified explicitly on the bean class or a method, the default @Lock value is @Lock(WRITE). The code above uses the @Lock(READ) annotation on bean class to change the default so that multi-threaded access is granted by default. We then only need to apply the @Lock(WRITE) annotation to the methods that modify the state of the bean. Essentially @Lock(READ) allows multithreaded access to the Singleton bean instance unless someone is invoking an @Lock(WRITE) method. With @Lock(WRITE), the thread invoking the bean will be guaranteed to have exclusive access to the Singleton bean instance for the duration of its invocation. This combination allows the bean instance to use data types that are not normally thread safe. Great care must still be used, though. In the example we see ComponentRegistryBean using a java.util.HashMap which is not synchronized. To make this ok we do three things: 1. Encapsulation. We don't expose the HashMap instance directly; including its iterators, key set, value set or entry set. 2. We use @Lock(WRITE) on the methods that mutate the map such as the put() and remove() methods. 3. We use @Lock(READ) on the get() and values() methods as they do not change the map state and are guaranteed not to be called at the same as any of the @Lock(WRITE) methods, so we know the state of the HashMap is no being mutated and therefore safe for reading. The end result is that the threading model for this bean will switch from multi-threaded access to single-threaded access dynamically as needed depending on the which methods are being invoked. This gives Singletons a bit of an advantage over Servlets for processing multi-threaded requests. http://cwiki.apache.org/OPENEJBx30/singleton-example.html Feel free to kick it back with changes/tweaks or other questions. Sometimes a word added here or there can make things more clear. These docs are likely going to be a primary source of singleton information for a while so we definitely want them to be as informative as possible. -David
User Blog: Rapid EJB Development with Unit Tests
Quintin Beukes has written an inspiring blog post about his experience discovering the world of embedded EJB unit testing using OpenEJB and the time it has saved him. He also goes into detail on how to setup OpenEJB in Netbeans starting from downloading OpenEJB to navigating the Netbeans menus to running your first test case. http://qbeukes.blogspot.com/2008/08/rapid-ejb-development-with-unit-tests.html As usual, if you like the post (even if you find it in the archives at some point in the future) feel encouraged to leave a positive comment on his blog! Enjoy! -David
Re: Docs: EJB 3.1 Singleton documentation
On Aug 26, 2008, at 5:23 AM, Martin Vysny wrote: Many thanks for clarifying on how the locks works! One more question, just to be 100% sure :) . Recently I studied the java memory model a bit (there is beautiful FAQ located at [1]) and I'd like to ask: Let's assume that the execution exited some method m1 protected by Lock.READ (or Lock.WRITE) and is about to enter some method m2 (in the same Singleton bean) protected by Lock.WRITE. Is any operation invoked in method m1 guaranteed to happen-before any operation invoked in method m2? Those details are better described on this page: http://cwiki.apache.org/OPENEJBx30/singleton-beans.html I've slightly tweaked it to make the connection with ReadWriteLock stronger and to explicitly mention we use a ReentrantReadWriteLock. Hopefully people will follow those links. Here are a couple quotes from those docs that answer your questions a little more specifically: All ReadWriteLock implementations must guarantee that the memory synchronization effects of writeLock operations (as specified in the Lock interface) also hold with respect to the associated readLock. That is, a thread successfully acquiring the read lock will see all updates made upon previous release of the write lock. -- http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/ReadWriteLock.html Reentrancy also allows downgrading from the write lock to a read lock, by acquiring the write lock, then the read lock and then releasing the write lock. However, upgrading from a read lock to the write lock is not possible. -- http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html We could probably quote some of those two javadocs if there were one or two really critical things we think people should know above all else. If you have any thoughts on that regard that'd be great. -David
Re: Unit-Testing with JMS using embedded openjpa
Hi Josef,
Swear I sent this yesterday, but here it is :)
On Aug 26, 2008, at 7:01 AM, [EMAIL PROTECTED] wrote:
testing my first JMS-experiences in Geronimo 2.1.1, I thought why
not test
it with the openjpa embedded container. We have a lot of stateless
session
beans which work wonderful in the embedded container openejb 3.0,
but for
the injection of the JMS-ConnectionFactory in my test-cases I need a
hint.
The Testclass should write a Textmessage in a JMS-Queue:
public class MyTest {
@Resource
private ConnectionFactory factory;
@Resource
private Queue receivingQueue;
...
@Test
public void sendMessage() throws Exception{
Connection connection = null;
MessageProducer messageProducer = null;
Session sess = null;
connection = factory.createConnection();
sess = connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
TextMessage msg = sess.createTextMessage(Hallo
World!!
);
messageProducer = sess.createProducer(receivingQueue);
messageProducer.send(msg);
System.out.println((client) Test Request Send);
}
[...]
My Problem is that factory and receivingQueue are always null, there
is no
Resource-Injection. I tried also:
@Resource(name=MyConnectionFactoryName)
private ConnectionFactory factory;
We don't yet support injection for the test case itself. One way to
do it would be to use an inner class ejb inside the TestCase, such as:
public static class MyTest {
@Test
public void testHelloMessage() throws Exception {
Properties props = new Properties();
props.setProperty(Context.INITIAL_CONTEXT_FACTORY,
org.apache.openejb.client.LocalInitialContextFactory);
InitialContext context = new InitialContext(props);
MyTestLocal testBean =
(MessagingClientBean.MyTest.MyTestLocal)
context.lookup(MyTestBeanLocal);
testBean.sendMessage(Hallo World!!);
}
@Stateless
public static class MyTestBean implements MyTestLocal {
@Resource
private ConnectionFactory factory;
@Resource
private Queue receivingQueue;
public void sendMessage(String message) throws Exception {
Connection connection = null;
MessageProducer messageProducer = null;
Session sess = null;
connection = factory.createConnection();
sess = connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
TextMessage msg = sess.createTextMessage(message);
messageProducer = sess.createProducer(receivingQueue);
messageProducer.send(msg);
System.out.println((client) Test Request Send);
}
}
public static interface MyTestLocal {
public void sendMessage(String message) throws Exception;
}
}
Then just add an META-INF/ejb-jar.xml to your test classes dir. (in
maven it's src/test/resources/META-INF/ejb-jar.xml)
If you're looking to test MDBs we have a basic example for that here
which might be useful:
http://svn.apache.org/repos/asf/openejb/trunk/openejb3/examples/simple-mdb/
-David
Re: Custom JAAS LoginModule: Principal with empty name provided
That's pretty much right. The exact code looks like this:
try {
// Perform a login attempt (which should fail)
// simply to excercise the initialize code of any
// LoginModules that are configured.
// They should have a chance to perform any special
// boot-time code that they may need.
login(,);
} catch (Throwable e) {
}
We can probably create a flag you could set to disable that behavior
if you'd rather not get the call.
-David
On Sep 4, 2008, at 9:44 AM, Dain Sundstrom wrote:
IIRC, OpenEJB performs a single fake login after installing the
security service in an effort to cause the login module to
initialize early. The security service performs this in a try catch
that ignores any exceptions.
-dain
On Sep 3, 2008, at 6:46 AM, Martin Vysny wrote:
Hello guys,
we tried to supply our custom JAAS LoginModule to OpenEJB. It works
beautifully, I have just one question.
When the OpenEJB is created (using the new InitialContext(properties)
construct), it invokes this LoginModule and the handler supplies an
empty string as an username in NameCallback. This isn't surprising
though: I do not provide any username nor credentials to the
InitialContext. What should I do?
- should I expect empty string in LoginModule and throw
LoginException?
- or should I provide some username/password? This is probably rather
weird as no ejb method is being called...
Thanks!
Martin
ps: please see attached stack trace for quick reference.
stacktrace.txt
Re: Unit Tests hangs on getting connection
On Sep 5, 2008, at 7:47 AM, Newgro wrote: Hi again, i solved it myself. I created multiple tables on @BeforeClass. But i didn't closed the connection after table create statement was executed. It seems that i've got 10 pooled connections and then the manager was waiting for next free connection. I now close the connection after every create table and it works now. Sorry for annoying the list :-) No worries. It might help some future archive searcher. -David
Re: Unit tests for concurrent transactions
On Sep 8, 2008, at 4:25 AM, Marcin Kwapisz wrote: I would like to make unit tests for concurrent transactions, for example to check optimistic locking. Is it possible to perform such tests with embedded OpenEJB? If the answer is: yes, how can I control the order of operations in two concurrent transactions. It's definitely possible to do. At minimum you'd need one thread per transaction. You might want to dig into the java.util.concurrent package to guarantee that everything is happening in the exact way you want. Basically anytime you find yourself adding Thread.sleep statements, you'll be far better off with one or two of the basic tactics that the java.util.concurrent package offers. Here's an example of using java.util.concurrent.CountDownLatch which might help you: http://svn.apache.org/viewvc/openejb/trunk/openejb3/container/openejb-core/src/test/java/org/apache/openejb/core/stateless/StatelessInstanceManagerPoolingTest.java?view=markuppathrev=686447 You could hand your bean a CountDownLatch initialized to 1 and have it do some work in a transaction and call countDownLatch.await() so the method doesn't exit and the transaction stays open. Then invoke another bean that attempts to work with the same data. When it completes, your test code can call countDownLatch.countDown() and the bean that is blocking on the await() call will wake up and continue with its transaction. Definitely would make for a cool example/blog post/article (one of the three). Feel free to ask for all the help you need. -David
Re: Local server is not initialized
On Sep 10, 2008, at 1:38 AM, Andreas Karalus wrote: I want to test code that performs itself a InitialContext ctx = new InitialContext(). This works well with jboss.embedded, but fails with openejb. For jboss.embedded we use a jndi.properties as configuration. so if the file is present in classpath, new IntialContext() works fine. I wonder if there is a similar configuration in openejb? [...] p.s. here is the data in jndi.properties java.naming.factory.initial=org.jnp.interfaces.LocalOnlyContextFactory java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces Right, it's the java.naming.factory.url.pkgs line that's causing the problem. A snippet from the InitialContext javadoc: JNDI determines each property's value by merging the values from the following two sources, in order: 1. The first occurrence of the property from the constructor's environment parameter and (for appropriate properties) the applet parameters and system properties. 2. The application resource files (jndi.properties). The vm is picking JBoss's org.jboss.naming and org.jnp.interfaces packages for all java: lookups instead of ours because the values of the jndi.properties file are getting merged with your InitialContext properties. You could either delete your jndi.properties file completely or you could update it as follows: java .naming .factory.initial=org.apache.openejb.client.LocalInitialContextFactory java.naming.factory.url.pkgs=org.apache.openejb.core.ivm.naming Just make sure that you don't use these settings in an actual remote client running in a different VM than the server. There you'd use these settings: java .naming .factory.initial=org.apache.openejb.client.RemoteInitialContextFactory java.naming.factory.url.pkgs=org.apache.openejb.client -David
Re: Bind Datasource to specific jndi name
On Sep 9, 2008, at 5:53 AM, Andreas Karalus wrote: hello, i've configured a datasource like this Resource id=operativDS type=DataSource JdbcDriver oracle.jdbc.driver.OracleDriver JdbcUrl jdbc:oracle:thin:@localhost:1521:orcl UserNamescott Passwordtiger /Resource is it possible to bind the datasource to a specific jndi name? especially, I would like to bind the datasource to java:/operativDS Everything in the config is bound to something that closely matches its path in the openejb.xml file. So for example: openejb Resource id=operativDS ... Is bound to: new InitialContext().lookup(java:openejb/Resource/operativDS); If you wanted to make it available at a different name, you could easily add the link yourself with some code like this after OpenEJB has been embedded: InitialContext context = new InitialContext(); context.bind(java:operativDS, new javax.naming.LinkRef(java:openejb/Resource/operativDS)); -David
Re: Active MQ 5.1 support
On Sep 9, 2008, at 1:25 PM, rde8026 wrote: Is it possible to use active mq 5.1 with the openejb container rather than 4.1? It should be possible, though I'm not sure if anyone has tried. If so what does it take to make this change. Are you in maven or are you using the lib directory of a standalone zip/tar? -David
Re: Active MQ 5.1 support
On Sep 15, 2008, at 3:45 PM, rde8026 wrote: I'm using the standard lib form a zip file... Ok. In terms of general library upgrading, we generate two files (dependencies.xml and dependencies.txt) that we put inside of every openejb-*.jar that says what dependencies the jar has. The data is nested to show a tree view to make it easier to see what dependencies are pulled in only by third party libraries. Here is the top part of dependencies.txt for openejb-core-3.1- SNAPSHOT.jar: activemq-core-4.1.1.jar activeio-core-3.0.0-incubator.jar backport-util-concurrent-2.1.jar activemq-ra-4.1.1.jar asm-2.2.3.jar asm-commons-2.2.3.jar asm-tree-2.2.3.jar asm-finder-3.1-SNAPSHOT.jar commons-cli-1.1.jar commons-collections-3.2.jar . So you should only need to remove activemq-core-4.1.1.jar, activemq- ra-4.1.1.jar and any libraries they depend on, which are activeio- core-3.0.0-incubator.jar and backport-util-concurrent-2.1.jar. As far as replacing them, you'll definitely need activemq-core-5.1.0.jar and activemq-ra-5.1.0.jar. http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/activemq/activemq-core/5.1.0/activemq-core-5.1.0.jar http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/activemq/activemq-ra/5.1.0/activemq-ra-5.1.0.jar .. plus their non-optional depenencies. The activemq-core-5.1.0.pom shows these required deps (versions are in activemq-parent-5.1.0.pom). http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/activemq/activeio-core/3.1.0/activeio-core-3.1.0.jar http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/camel/camel-core/1.3.0/camel-core-1.3.0.jar The activeio-core pom lists backport-util-concurrent as a dependency, but I couldn't find any use of it in their source. I'd try getting by without it. Definitely let us know how it goes. -David
Re: Bind Datasource to specific jndi name
On Sep 16, 2008, at 3:42 AM, Andreas Karalus wrote: Hi David, thank you for your hint, I tried this, but still got exception: In the code for intialisation of openejb: initialContext.bind(java:operativDS, new javax.naming.LinkRef(java:openejb/Resource/operativDS)); In the test Code: // this is ok DataSource operativDS = (DataSource) initialContext.lookup(java:openejb/operativDS); // this one fails, but this is the lookup I need DataSource operativDS = (DataSource) initialContext.lookup(java:/operativDS); So is there a possibility to bind directly to java: and not to java:openejb? It seems to me like java:openejb is kind of hardcoded? Right, internally we depend on things being at a known place (java:openejb). We could bind things to additional places but we will still need to maintain the java:openejb namespace. The use of LinkRef should allow you to have all the extra JNDI names you need, we just need to figure out what might be happening. Is it possible you can post the complete initialization stacktrace as long as some sample code that shows how you are constructing the InitialContext you are using to do the binding/lookup? -David
Re: Problem during deployment with ejb-jar.xml
On Sep 18, 2008, at 3:21 AM, Fred59 wrote: Hi all, I'm using OpenEJB 3.0. I try to override a persistence context defined in a session. Hereafter the ejb-jar.xml content ?xml version=1.0 encoding=UTF-8? ejb-jar xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd; version=3.0 enterprise-beans session ejb-nameMySessionImpl/ejb-name persistence-context-ref persistence-context-ref-namecore.impl.MySessionImpl/em/ persistence-context-ref-name persistence-unit-namemyDomainExt/persistence-unit- name /persistence-context-ref /session /enterprise-beans /ejb-jar It's fine to leave the ejb-class tag off as the annotated bean with the same name can fill in that data, but in this case it looks like there is no bean with the ejb-name MySessionImpl and therefore it isn't overriding anything. -David
Fwd: Application Period Opens for Travel Assistance to ApacheCon US 2008
Begin forwarded message: Resent-From: [EMAIL PROTECTED] From: Gavin [EMAIL PROTECTED] Date: September 25, 2008 8:36:44 AM CDT To: [EMAIL PROTECTED] Subject: Application Period Opens for Travel Assistance to ApacheCon US 2008 Reply-To: [EMAIL PROTECTED] Dear PMCs, Please could you forward the below message to your user@ and dev@ mailing lists, thanks in advance. - The Travel Assistance Committee is taking in applications for those wanting to attend ApacheCon US 2008 between the 3rd and 7th November 2008 in New Orleans. The Travel Assistance Committee is looking for people who would like to be able to attend ApacheCon US 2008 who need some financial support in order to get there. There are VERY few places available and the criteria is high, that aside applications are open to all open source developers who feel that their attendance would benefit themselves, their project(s), the ASF and open source in general. Financial assistance is available for flights, accomodation and entrance fees either in full or in part, depending on circumstances. It is intended that all our ApacheCon events are covered, so it may be prudent for those in Europe and or Asia to wait until an event closer to them comes up - you are all welcome to apply for ApacheCon US of course, but there must be compelling reasons for you to attend an event further away that your home location for your application to be considered above those closer to the event location. More information can be found on the main Apache website at http://www.apache.org/travel/index.html - where you will also find a link to the application form and details for submitting. Time is very tight for this event, so applications are open now and will end on the 2nd October 2008 - to give enough time for travel arrangements to be made. Good luck to all those that will apply. Regards, The Travel Assistance Committee
Re: OpenEJB with JUnit from NetBeans: NameNotFoundException
On Oct 8, 2008, at 3:26 AM, Bernhard Humm wrote: I am trying to use OpenEJB with JUnit from NetBeans IDE. This is what I have done: 1. Download openejb-3.0.zip and openejb-examples-3.0.zip from openejb.apache.org and unzip. 2. Open new NetBeans Java Project with Existing Sources (source and test directories from openejb-examples) 3. Add openejb-3.0/lib/* as source and test libraries (also needs libs as source libraries for compilation 4. Execute build.xml (default) The project is being built and the JUnit tests start running. However, I get an javax.naming.NameNotFoundException for all EJBs. The EJBs seem not to be registered in the name server. Providing an JNDI name using (MappedName=...) does not help either. Instead of using the ant build.xml in NetBeans, try having NetBeans run the test case directly. -David
Re: Unknown error in Assembler for MessageDriven bean
On Oct 3, 2008, at 8:01 AM, Zog wrote: Hi Unfortunately I cant' post the code - but I solved the issue by just adding a messaging-typejavax.jms.MessageListener/messaging-type in ejb-jar.xml for all my MDBs. One thing to note though is that my MDBs do not directly imlpement this interface, they extend a class that does - could it be possible that you're using Class.getDeclaredClasses() instead of getClasses() to introspect the class ? That's definitely what we are doing. Couple notes on that. For EJb 2.1 and prior the messaging-type is a required xml element -- autodiscovery via introspection is an EJB 3.0 feature. If you were to grab an old version of weblogic, the bean would likely not deploy without the messaging-type declared. Something to keep in mind if you intend your app to be an EJB 2.1 compliant app. In EJB 3.0 there are some things that the vendor must look into the superclasses for such as @PostConstruct, @PreDestroy, @Resource, and @EJB. But others like @Stateless, @MessageDriven, @Stateful, @Local, @Remote as well as business interfaces (including message listener interfaces) are only supported in the bean class itself, not the super class. Some vendors may support searching in super classes for business interfaces, but this is not a compliant behavior and other platforms are not guaranteed to do the same. A very special note here is that apps that rely on non-compliant auto-discovery of business interfaces in the super class may actually *break* as in EJB 3.1 any ejb that doesn't declare any business interfaces in the bean class itself will be considered a no-interface bean. This won't affect MDBs, but is something to be aware of. -David Dain Sundstrom wrote: Can you post the code for you message driven bean or at the very least the class declaration with any extends clause, implements clause and class annotations? My guess is the MDB class is not-spec-compliant and Weblogic has some special logic to guess the proper message listener interface. Or, we have a bug :) -dain On Sep 30, 2008, at 10:34 AM, Jacques-Olivier Goussard wrote: Hi, I'm trying to deploy a bunch of MDBs on openejb and encounter this error: 2008-09-30 15:52:51,328 - ERROR - FATAL ERROR: Unknown error in Assembler. Plea se send the following stack trace and this message to [EMAIL PROTECTED] : java.lang.IllegalStateException: When annotating a bean class as @MessageDriven without declaring messageListenerInterface, the bean must implement exactly one interface, no more and no less. beanClass=com.oz.shared.transcoding.sti.protoco l.ejb.TranscodingProviderMessageListenerBean interfaces= at org.apache.openejb.config.AnnotationDeployer $ProcessAnnotatedBeans.de ploy(AnnotationDeployer.java:854) (see full stack below) Those EJB were deployed successfully in weblogic, and I didn't yet properly create the corresponding Deployment descriptors for openejb – but this error seems an internal one and given My EJB are 2.0 (no annotations), I find it strange it complains about this annotation. Any ideas someone ? /jog 2008-09-30 15:52:51,328 - ERROR - FATAL ERROR: Unknown error in Assembler. Plea se send the following stack trace and this message to [EMAIL PROTECTED] : java.lang.IllegalStateException: When annotating a bean class as @MessageDriven without declaring messageListenerInterface, the bean must implement exactly one interface, no more and no less. beanClass=com.oz.shared.transcoding.sti.protoco l.ejb.TranscodingProviderMessageListenerBean interfaces= at org.apache.openejb.config.AnnotationDeployer $ProcessAnnotatedBeans.de ploy(AnnotationDeployer.java:854) at org.apache.openejb.config.AnnotationDeployer $ProcessAnnotatedBeans.de ploy(AnnotationDeployer.java:489) at org .apache.openejb.config.AnnotationDeployer.deploy(AnnotationDeploye r.java:169) at org.apache.openejb.config.ConfigurationFactory $Chain.deploy(Configura tionFactory.java:148) at org .apache.openejb.config.ConfigurationFactory.configureApplication(C onfigurationFactory.java:440) at org .apache.openejb.config.ConfigurationFactory.configureApplication(C onfigurationFactory.java:391) at org .apache.openejb.config.ConfigurationFactory.getOpenEjbConfiguratio n(ConfigurationFactory.java:309) at org .apache.openejb.assembler.classic.Assembler.build(Assembler.java:2 49) at org.apache.openejb.OpenEJB$Instance.init(OpenEJB.java: 149) at org.apache.openejb.OpenEJB.init(OpenEJB.java:288) at org.apache.openejb.server.Server.init(Server.java:63) at org.apache.openejb.server.Main.initServer(Main.java:155) at org.apache.openejb.server.Main.main(Main.java:128) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun .reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun
Re: JNDI lookup in Tomcat
On Oct 8, 2008, at 12:37 PM, Zog wrote: I installed the openejb.war in tomcat-6.0.18 and my ear as a collapsed ear. When I lookup objects in the JNDI tree, I realized that I can freely look up injected resources (I use the resource-ref in ejb-jar.xml for ex for data sources), but non injected are failing - is this normal ? Specifically, one of my ejb is doing InitialContext ic = new InitialContext(); // Properly initialized with the OpenEJB ICfactory ic.lookup(openejb/TransactionManager); and this always throws a NameNotFoundException. Hmm. If it was created with the LocalInitialContextFactory as so.. Properties properties = new Properties(); properties.setProperty(Context.INITIAL_CONTEXT_FACTORY, org.apache.openejb.client.LocalInitialContextFactory); InitialContext initialContext = new InitialContext(properties); Then it should definitely work. If it was done as so... InitialContext initialContext = new InitialContext(); Then I'm not as confident that it will work. We have code in the integration to add the openejb subcontext into the webapp's jndi context, or so I thought. I added code along these lines, but it's been while and I can't recall the details. Maybe in this second case you have to lookup java:openejb/TransactionManager. Can you verify which technique you are using? -David
Re: Override annotations in ejb-jar.xml for a test case
On Sep 22, 2008, at 5:33 AM, Marcin Kwapisz wrote: Hi, I would like to add an interceptor to my EJB but only in a test. I have separate ejb-jar.xml for tests and all my EJBs are annotated. We don't have any functionality for supplying an alternate ejb-jar.xml for testing purposes. It's not a bad idea and is something we might be able to add after we get the 3.1 release out the door. When ejb-jar.xml is empty everything works fine. When I change ejb- jar and add for example: assembly-descriptor interceptor-binding ejb-nameStudentEndpointBean/ejb-name interceptor- classpl.zsk.sos.interceptor.TestInterceptor/interceptor-class /interceptor-binding /assembly-descriptor automatic configuration does not find my EJBs and I get javax.naming.NameNotFoundException This might be because the ejb-jar.xml is with the ejbs that are annotated. A small workaround might be to add an interceptor to your main app and have it look for a special system property of your creation in its constructor. The system property can be the name of an interceptor class that it should delegate to. If the system property is not specified then it does nothing. The test case could set the special system property to point to pl.zsk.sos.interceptor.TestInterceptor or any other interceptor you wish to write for a given test case. You could potentially then have an interceptor dedicated to each test case to help with testing yet still only have one active at a time. -David
Re: Rollback transactions in unit testing
On Sep 29, 2008, at 8:39 AM, Glauber Ferreira wrote: Hi all. I need to rollback transactions in order to revert all data modified (deleted, updated, created) by my tests. How can I do that in the test code listed in this link: http://openejb.apache.org/3.0/unit-testing-transactions.html Suggestions in this thread are pretty good. A couple additional possibilities to throw on the stack.. If you throw a runtime exception from the TransactionBean call method the container will rollback the transaction. Another option is to call the setRollbackOnly() method on the javax.ejb.SessionContext object. A session ejb can have it injected with a field declared like @Resource SessionContext sessionContext; -David
Re: EntityManager not picking up Map properties
On Sep 18, 2008, at 10:28 PM, rde8026 wrote: I'm using Hibernate as my JPA provider in a Stateless EJB. I need to add the hibernate.default_catalog property to the EntityManager based on the dialect being used (i.e. SQL Server = dbo). I'm injecting the EntityManagerFactory and trying to construct an EntityManager based off that but passing a HashMap to it with that single property...and its not pre-pending the sql statements correctly. If I do it via the persistence.xml file it worksany thoughts? Here is a code snippet.. MapString, String props = new HashMapString, String(); props.put(hibernate.default_catalog, dbo); em = emf.createEntityManager(props); Likely a bug in hibernate as that call goes directly to them. We get the hibernate EntityManagerFactory via a call like: PersistenceProvider persistenceProvider = (PersistenceProvider) clazz.newInstance(); EntityManagerFactory emf = persistenceProvider.createContainerEntityManagerFactory(unitInfo, new HashMap()); And the persistence.xml data is in the PersistenceUnitInfo implementation we create and hand to the persistence provider (Hibernate in this case). Seems they only support that property (or perhaps all properties) via the call above and not via the EntityManagerFactory createEntityManager method. -David
Re: Override annotations in ejb-jar.xml for a test case
On Oct 9, 2008, at 3:16 AM, Marcin Kwapisz wrote: Correct me if I am wrong: when ejb-jar is empty OpenEJB process all class files (in classes and test-classes) and looks for annotated EJBs. When ejb-jar is modified, OpenEJB process that file and looks for annotated EJBs in test-classes only. We look for annotated ejbs in classes/ if we find a classes/META-INF/ ejb-jar.xml file and the ejb-jar.xml file does not have 'metadata- complete' attribute set to 'true'. Aside from the metadata-complete attribute, the contents of the ejb-jar.xml do not prevent searching for annotations or annotated ejbs. The classes/ directory is treated as a single ejb jar and the contents of the classes/META-INF/ejb- jar.xml apply only to the beans in classes/. The same rule applies for test-classes/. Specifically, we look for annotated ejbs in test-classes/ if we find a test-classes/META-INF/ejb- jar.xml file and the ejb-jar.xml file does not have 'metadata- complete' attribute set to 'true' and the test-classes/ directory is treated as a single ejb jar, separate from classes/, and the contents of the test-classes/META-INF/ejb-jar.xml apply only to the beans in test-classes/. Hope that helps. -David
Re: OpenEJB with JUnit from NetBeans: NameNotFoundException
On Oct 8, 2008, at 2:09 PM, Bernhard Humm wrote: This is what I did first, with the same effect: NameNotFoundException Could you post the log output from the test run? -David
Re: OpenEJB with JUnit from NetBeans: NameNotFoundException
On Oct 9, 2008, at 4:32 AM, Bernhard Humm wrote:
init:
deps-jar:
compile:
compile-test:
Testsuite: org.superbiz.calculator.CalculatorTest
Apache OpenEJB 3.0build: 20080408-04:13
http://openejb.apache.org/
INFO - openejb.home = C:\temp\NetBeans\OpenEJBTest
INFO - openejb.base = C:\temp\NetBeans\OpenEJBTest
INFO - Configuring Service(id=Default Security Service,
type=SecurityService, provider-id=Default Security Service)
INFO - Configuring Service(id=Default Transaction Manager,
type=TransactionManager, provider-id=Default Transaction Manager)
INFO - Configuring Service(id=Default JDK 1.3 ProxyFactory,
type=ProxyFactory, provider-id=Default JDK 1.3 ProxyFactory)
Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 5,234 sec
It doesn't look like the app is getting discovered with the way it's
setup in NetBeans. OpenEJB will search for directories or jars
containing a META-INF/ejb-jar.xml file and load those directories and
jars as individual ejb jars. We have NetBeans users, so I know it's
capable of putting both the classes and the META-INF/ejb-jar.xml in
the same directory so that OpenEJB can discover them together as an
app. We just need to figure out what might be happening with this
particular setup.
Run this in your test case and see if your classpath is setup right.
There should be a META-INF/ejb-jar.xml file in any directories that
contain ejb classes that should be deployed by OpenEJB.
EnumerationURL ejbJars =
this.getClass().getClassLoader().getResources(META-INF/ejb-jar.xml);
while (ejbJars.hasMoreElements()) {
URL url = ejbJars.nextElement();
System.out.println(app = + url);
}
-David
Re: OpenEJB in an OSGi container
Guillaume is the one who's done most the work in this area in regards to his use of OpenEJB in the OSGi-based ServiceMix 4. What boot technique did you use in ServieMix? -David On Oct 9, 2008, at 2:08 PM, Zog wrote: Hi So, I managed to get my EJB app running just fine in Tomcat/ OpeneEJB. Now that it validates the J2EE support I need from OpenEJB, I'd like to move all this to an OSGi container. Any hints on where I should look for information ? I scanned through the web and although it's stated everywhere that OpenEJB is packaged as OSGi bundled, I couldn't find information on how to start openejb in osgi. I tried a simple approach where I load everything in openejb/lib from the system classpath, but got a mysterious exception: Caused by: org.apache.openejb.core.ivm.naming.NamingException: Cannot initailize OpenEJB: null at org.apache.openejb.core.ivm.naming.InitContextFactory.initializeOpenE JB(InitContextFactory.java:88) at org.apache.openejb.core.ivm.naming.InitContextFactory.getInitialConte xt(InitContextFactory.java:35) at org.apache.openejb.client.LocalInitialContextFactory.getIntraVmContex t(LocalInitialContextFactory.java:114) That's most probably related to the way OSGi does classloading, and I'm investigating. Should I look at the way you embedded OpenEJB for Tomcat ? Or should I look elsewhere ? Any clue welcomed :) /Zog PS: Btw, finding http://openejb.apache.org/apidocs is not very easy on the openejb site - I had to scan through the forums to find that one. -- View this message in context: http://www.nabble.com/OpenEJB-in-an-OSGi-container-tp19905326p19905326.html Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: OpenEJB in an OSGi container
Thanks, Guillaume. That gives me a pretty good idea on what the pieces are. Zog, let me know what OSGi kernel and version you're using and I'll see if I can't whip up some boot code for you. If you've got any starter code you can share, feel free to zip it up and attach it do a JIRA (created a jira for you here https://issues.apache.org/jira/browse/OPENEJB-921) -David On Oct 9, 2008, at 2:47 PM, Guillaume Nodet wrote: It's been a long time since I work on that and I still have not found the time to continue this integration work. Anyway, the code I used is available at: http://svn.apache.org/repos/asf/servicemix/smx4/features/branches/ ejb3 It uses a spring-powered bundle to set up OpenEJB: http://svn.apache.org/repos/asf/servicemix/smx4/features/branches/ejb3/deployer/src/main/resources/META-INF/spring/openejb-spring.xml and the related java classes are available at: http://svn.apache.org/repos/asf/servicemix/smx4/features/branches/ejb3/deployer/src/main/java/org/apache/servicemix/ejb3/deployer/ Unfortunately, this may be a bit outdated :-( Anyway, the idea was to be able to listen to newly installed bundles and discover EJB inside those so that they are automatically configured as plain EJB or web services. Though, this was in the context of ServiceMix, where the EJBs were to be exposed on the JBI bus and eventually through HTTP/SOAP too. On Thu, Oct 9, 2008 at 9:26 PM, David Blevins [EMAIL PROTECTED] wrote: Guillaume is the one who's done most the work in this area in regards to his use of OpenEJB in the OSGi-based ServiceMix 4. What boot technique did you use in ServieMix? -David On Oct 9, 2008, at 2:08 PM, Zog wrote: Hi So, I managed to get my EJB app running just fine in Tomcat/ OpeneEJB. Now that it validates the J2EE support I need from OpenEJB, I'd like to move all this to an OSGi container. Any hints on where I should look for information ? I scanned through the web and although it's stated everywhere that OpenEJB is packaged as OSGi bundled, I couldn't find information on how to start openejb in osgi. I tried a simple approach where I load everything in openejb/lib from the system classpath, but got a mysterious exception: Caused by: org.apache.openejb.core.ivm.naming.NamingException: Cannot initailize OpenEJB: null at org .apache.openejb.core.ivm.naming.InitContextFactory.initializeOpenE JB(InitContextFactory.java:88) at org .apache.openejb.core.ivm.naming.InitContextFactory.getInitialConte xt(InitContextFactory.java:35) at org .apache.openejb.client.LocalInitialContextFactory.getIntraVmContex t(LocalInitialContextFactory.java:114) That's most probably related to the way OSGi does classloading, and I'm investigating. Should I look at the way you embedded OpenEJB for Tomcat ? Or should I look elsewhere ? Any clue welcomed :) /Zog PS: Btw, finding http://openejb.apache.org/apidocs is not very easy on the openejb site - I had to scan through the forums to find that one. -- View this message in context: http://www.nabble.com/OpenEJB-in-an-OSGi-container-tp19905326p19905326.html Sent from the OpenEJB User mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://open.iona.com
Re: OpenEJB with JUnit from NetBeans: NameNotFoundException
On Oct 9, 2008, at 9:42 PM, franz see wrote:
I figured out what the solution is,
The setUp() of the test cases are missing this line
properties.setProperty(openejb.deployments.classpath.include,
.*simple-stateless/target/classes.*);
I don't know why though ( I don't know how openejb works ). But the
interceptors example works and it has that line.
That solution definitely works and is the way you get a module
discovered when there is no simple-stateless/target/classes/META-INF/
ejb-jar.xml file.
I ran the 3.0 examples against various Java 1.5.0_x versions on maven
2.0.8 with a clean repo on FreeBSD 6.2, Linux 2.6.24, and OSX 10.5.4
and all ran fine except the simple-webservices test on FreeBSD.
Can you run this little script and attach the output (build.log) to
the jira you created?
---begin---
#!/bin/bash
{
wget -q
http://archive.apache.org/dist/maven/binaries/apache-maven-2.0.8-bin.tar.gz
wget -q http://www.apache.org/dist/openejb/3.0/openejb-examples-3.0.tar.gz
tar xzf apache-maven-2.0.8-bin.tar.gz
tar xzf openejb-examples-3.0.tar.gz
cd openejb-examples-3.0/simple-stateless
uname -a
../../apache-maven-2.0.8/bin/mvn -X -Dmaven.repo.local=tmp clean install
} | tee build.log
---end---
-David
Re: OpenEJB with JUnit from NetBeans: NameNotFoundException
On Oct 11, 2008, at 9:39 AM, franz see wrote: Good day, The script you gave me passed with no problem. And after comparing with my failing copy, I found out what the reason is. My `meta-inf` were in all small caps, and because of that openejb failed to detect `META-INF/ejb-jar.xml`. After renaming my `meta-inf` to `META-INF`, the test passes ( except for simple-webservices ). Wow, that's very interesting. We can probably do a search for both uppercase and lowercase just in case this sort of scenario happens again. Added a JIRA for that http://issues.apache.org/jira/browse/OPENEJB-923 Do you have any theories on how it got named lowercase meta-inf? Maybe something we can document. -David
Re: OpenEJB Tomcat Deployments
Hi Thiago, We do in fact scan all of WEB-INF/lib/ and WEB-INF/classes for ejbs. The openejb.deployments.classpath.include property applies to boot- time scanning of the system classpath, but we could probably rig up something that allows you to set that and similar flags for an individual webapp. Filed a jira on it: https://issues.apache.org/jira/browse/OPENEJB-925 (for notifications: https://issues.apache.org/jira/secure/ViewIssue.jspa?id=12406545watch=true) -David On Oct 15, 2008, at 4:29 PM, Thiago Antônio Marafon wrote: Hello Reza! Thanks for helping me again. I made a simple application, using no jars, with only one annotated EJB, and Tomcat loads in +- 25 seconds. If I make this app depend on Hibernate, Struts and some others jars (20 jars total), still with only one EJB, then Tomcat takes 55 seconds to start. I´ve tried to use the openejb.xml to describe the deployments, tried the openejb.deployments.classpath.include system property, and I even tried to put the EJB .class files in a jar with an empty ejb- jar.xml file, but Tomcat still takes more than 50 seconds to start. We can´t use all of these jars in Tomcat lib because there are many applications running together and each one using different versions of the libs. Even Hibernate, some of them uses 3.1.3, others 3.2.5. Frequently, the apps are so big that we don´t have time to migrate for the new vesions. It would be possible to put Struts and some others jars in Tomcat/ lib, but that is not really nice, specially during development. It is better to have them within the application, so they stay together in the repository (we still don´t use Maven. I hope we do soon). .. you can always disable class-path scanning by setting the metadata-complete attribute to true in the deployment descriptor. However, that will also turn off annotations processing completely. You mean I would have to describe the EJBs using XML? Regards, Thiago Reza Rahman escreveu: Thiago, What kind of boot times are you seeing? How many jars do you have? Do you need them all in the app or can some of them go in Tomcat/ lib instead? I have to say I haven't seen much of an issue on this, but I am using OpenEJB for unit testing only, not with Tomcat. If performance is a very critical issue, you can always disable class-path scanning by setting the metadata-complete attribute to true in the deployment descriptor. However, that will also turn off annotations processing completely. That should improve performance, right David? Are there any other OpenEJB specific techniques? I am curious to know myself... Cheers, Reza Thiago Antônio Marafon wrote: Hi all, I´m evaluation OpenEJB 3.0 with Tomcat 6. Everything is ok, my test application is working great. But, I noticed that the more jars the application has, longer is the Tomcat bootstrap time. Then I saw this: http://openejb.apache.org/3.0/application-discovery-via-the-classpath.html And tried all the alternatives, but it looks like that in Tomcat these don´t work. My beans are annotated, there isn´t a ejb-jar.xml, and the .class files are not in a jar. Any help? Cheers, Thiago
Re: persistence.xml in a Jar in Tomcat Common classloader (ERROR : PersistenceUnit already deployed)
Hi Maxime, It should be possible to put the service.jar in the Tomcat lib/ directory without a persistence.xml in it and then include that persistence xml in your webapp. You should be able to include a jar- file element in the unit declaration that points to the C:/tomcat6/ lib/service.jar so all the entities will be discovered without having to explicitly list them via the class element. You'd have to include the same persistence.xml in each webapp that wanted to reuse the classes in service.jar. Not entirely sure though if that's really what you're after. We don't currently have any support for global persistence units. Meaning say a persistence unit declared outside of an ear at server level and available to all ears/apps deployed. It might be something we could add if that's really what you're after. -David On Oct 16, 2008, at 12:25 AM, Maxime Thieu wrote: Hello everybody, I am developping ejb-jar module (let's call it service.jar) which contains EJB, Entity, Service and persistence.xml (in META-INF). I am developping webapp module (let's call it test.war) which contains Servlets who are calling some Service in service.jar (using entityManager to persist some data). I am trying to make this work under Tomcat 6.xx using OpenEJB 3.1 (build: 20081009-03:31). A.jar is present in the common classloader of Tomcat (in lib directory) in order to be visible by all webapps. In this case, during Tomcat starting, OpenEJB show the following Error : ERROR - Unable to deploy collapsed ear in war /test: Exception: Creating application failed: C:\tomcat6\webapps\test: PersistenceUnit already deployed: /C:/tomcat6/lib/service.jar If service.jar is present in the WEB-INF/lib of test.war, everything works well, but this is not I want (classes of service.jar should be visible by all webapps). Do I miss something? Is this possible with OpenEJB? I make several try and search but I do not find how to solve this (and I am a beginner in OpenEJB). Thanks in advance, any help would be appreciated. Maxime here is the complete StackTrace of the Error in the log : ERROR - Unable to deploy collapsed ear in war /test: Exception: Creating application failed: C:\tomcat6\webapps\test: PersistenceUnit already deployed: /C:/tomcat6/lib/service.jar org.apache.openejb.OpenEJBException: Creating application failed: C:\tomcat6\webapps\test: PersistenceUnit already deployed: /C:/tomcat6/lib/service.jar at org .apache .openejb .assembler.classic.Assembler.createApplication(Assembler.java:650) at org .apache .openejb .assembler.classic.Assembler.createApplication(Assembler.java:447) at org .apache .openejb .tomcat.catalina.TomcatWebAppBuilder.start(TomcatWebAppBuilder.java: 241) at org .apache .openejb .tomcat .catalina.TomcatLoader.processRunningApplications(TomcatLoader.java: 228) at org .apache.openejb.tomcat.catalina.TomcatLoader.init(TomcatLoader.java: 139) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun .reflect .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun .reflect .DelegatingMethodAccessorImpl .invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.openejb.loader.Embedder.init(Embedder.java:75) at org.apache.openejb.tomcat.loader.TomcatHook.hook(TomcatHook.java:98) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun .reflect .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun .reflect .DelegatingMethodAccessorImpl .invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org .apache .openejb.tomcat.loader.TomcatEmbedder.embed(TomcatEmbedder.java:74) at org .apache.openejb.tomcat.loader.LoaderServlet.init(LoaderServlet.java: 44) at org .apache .catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1161) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java: 981) at org .apache .catalina.core.StandardContext.loadOnStartup(StandardContext.java: 4055) at org.apache.catalina.core.StandardContext.start(StandardContext.java: 4361) at org .apache .catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java: 771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org .apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java: 626) at org .apache .catalina.startup.HostConfig.deployDescriptors(HostConfig.java:553) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488) at org.apache.catalina.startup.HostConfig.start(HostConfig.java: 1138) at org .apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java: 311) at org .apache .catalina
Re: How to remove stateful sessions programmatically ?
On Oct 17, 2008, at 5:57 AM, Jean-Sébastien Scrève wrote: Hi all, I'd like to remove stateful sessions beans by calling a method from OpenEJB itself and I don't see how I can do that. I don't want to call a method with @Remove annotation because I did not create the stateful myself. Is there a way I can do that ? More generally, how I can interact with the container at runtime ? If the bean had a 2.x home/remote interface that'd be easy as you could call remove on the home interface and pass in the stateful bean reference. Aside from that, not sure it can be done. The code we have for removing stateful beans is very much tied to the invoking of the remove method, calling the predestroy methods of the interceptors and bean, taking care of the transaction settings for the method, handling the exceptions thrown from the method, etc. We don't have a second way to remove stateful beans. The only other way I can think of is via an interceptor. If an interceptor method throws a runtime exception then the bean is destroyed. -David
Re: How to remove stateful sessions programmatically ?
On Oct 17, 2008, at 1:49 PM, David Blevins wrote: On Oct 17, 2008, at 5:57 AM, Jean-Sébastien Scrève wrote: Hi all, I'd like to remove stateful sessions beans by calling a method from OpenEJB itself and I don't see how I can do that. I don't want to call a method with @Remove annotation because I did not create the stateful myself. Is there a way I can do that ? More generally, how I can interact with the container at runtime ? If the bean had a 2.x home/remote interface that'd be easy as you could call remove on the home interface and pass in the stateful bean reference. Aside from that, not sure it can be done. The code we have for removing stateful beans is very much tied to the invoking of the remove method, calling the predestroy methods of the interceptors and bean, taking care of the transaction settings for the method, handling the exceptions thrown from the method, etc. We don't have a second way to remove stateful beans. The only other way I can think of is via an interceptor. If an interceptor method throws a runtime exception then the bean is destroyed. Feel free to elaborate on the use case. Might be an alternate way of looking at the problem that could also solve the issue. -David
Re: How to remove stateful sessions programmatically ?
On Oct 20, 2008, at 2:21 AM, Jean-Sébastien Scrève wrote:
Well, I don't see any simple way of doing it.
I'm gonna do like in Seam : lookup for a method annotated @Remove
with no
parameters and call it if present.
If you don't mind being bound to OpenEJB internals, you could grab the
CoreDeploymentInfo object for the bean and call this method:
public ListMethod getRemoveMethods() {
return removeMethods;
}
Then invoke one of those methods on the stateful bean proxy. This of
course won't work if the bean didn't declare any remove methods via
annotation in it or it's parent class or via the xml deployment
descriptor.
But as I stated before, if you had some sort of need to be able to
flush instances without the consent of the bean developer we might be
able to think of something if you wanted to describe the motivation of
the use case (tooling issue, runtime thing, memory management issue,
etc. etc.)
-David
[ANN] OpenEJB 3.1 Released
Download binaries here: http://openejb.apache.org/download.html Highlights - Major new features: - EJB 3.1 Singleton Support - EJB Constructor Injection - Spring Integration - Multicast Client-Server Discovery Significant Improvements: - EAR-style classpath application discovery groups individual modules as an EAR allowing sharing of persistence units and improved connector and custom MDB deployment. - Detection of EclipseLink, TopLink, and Hibernate as JPA providers to automatically adds the right persistence unit property to for wiring in the OpenEJB TransactionManager. - System Property and InitialContext property overriding now applies to persistence-unit properties and logging levels. - Login/logout now possible in an embedded scenario via InitialContext params and initialContext.close() respectively. - Complete overhaul of all client/server connection management dramatically increases performance. - Several new checks added to Application Validation ruleset, some reworked to give even more details. Full changelog - New Features: * [OPENEJB-836] Singleton Session Beans * [OPENEJB-839] Singleton Read and Write method locking * [OPENEJB-841] Singleton @DependsOn load ordering * [OPENEJB-840] Singleton @Startup load-on-startup * [OPENEJB-837] Singleton Bean-Managed Concurrency * [OPENEJB-838] Singleton Container-Managed Concurrency * [OPENEJB-821] EAR-style aggregation of modules discovered in the classpath * [OPENEJB-920] JDBC/DataSource based login module * [OPENEJB-913] Client Connection Failover and Request Retry * [OPENEJB-912] Client-side Connection Pool * [OPENEJB-857] Client connection KeepAlive * [OPENEJB-911] Graceful shutdown of client/server connections * [OPENEJB-903] Multicast discovery and grouping * [OPENEJB-905] PersistenceUnit property overriding * [OPENEJB-898] Property overriding for logging configuration * [OPENEJB-897] LocalInitialContext.close() to logout of embedded container * [OPENEJB-894] LocalInitialContext.close() to shutdown embedded container * [OPENEJB-896] VM-scoped Security for embedded scenarios * [OPENEJB-805] JMS runs port-free in embedded mode * [OPENEJB-785] EJBd protocol over SSL * [OPENEJB-881] Automatically set eclipselink.target-server for EclipseLink * [OPENEJB-880] Automatically set toplink.target-server for TopLink * [OPENEJB-801] Automatically set hibernate.transaction.manager_lookup_class for Hibernate Improvements: * [OPENEJB-893] Improved JavaAgent/JPA enhancement for Unit Tests * [OPENEJB-826] Improved detection of testing and embedded scenarios * [OPENEJB-899] Improved classpath configuration searching * [OPENEJB-831] PersistenceModule discoverable via the classpath * [OPENEJB-892] Remove ASM dependency * [OPENEJB-813] Example: CMP2 EntityBean * [OPENEJB-348] Example: Minimal MessageDriven Bean via @MessageDriven * [OPENEJB-850] Example: Singleton bean with bean vs container concurrency * [OPENEJB-359] Example: Using JMS * [OPENEJB-848] Validation: @TransactionAttribute mistakenly used on beans with Bean-Managed Transactions * [OPENEJB-855] Validation: Init/Remove annotations not used on MessageDriven, Stateless, or Singleton beans * [OPENEJB-677] Validation: PrePassivate/PostActivate not used on MessageDriven or Stateless * [OPENEJB-844] Validation: Singleton @Lock annotation not used with Bean-Managed Concurrency * [OPENEJB-846] Validation: Singleton mistakenly using @PrePassivate and @PostActivate * [OPENEJB-808] Validation: Unused ejbCreate methods * [OPENEJB-809] Validation: Unused ejbPostCreate methods * [OPENEJB-859] Improved validation for home, remote, local- home, local, business-local and business-remote elements * [OPENEJB-817] ID portion of property overriding no longer case sensitive * [OPENEJB-856] Upgrade to OpenJPA 1.1.0 * [OPENEJB-904] Pluggable Client/Server connection strategies and factories * [OPENEJB-799] Support META-INF/env-entry.properites as an alternative to META-INF/env-entries.properies * [OPENEJB-800] Default env-entry-type to java.lang.String * [OPENEJB-823] Print Service properties on debug * [OPENEJB-825] Eliminate possible mismatch of TxRecovery flag between TransactionManager and Resources * [OPENEJB-829] Automatically add an @DeclareRole ref for any role listed in @RolesAllowed * [OPENEJB-828] @EJB(name) value used to resolve ambiguous refs * [OPENEJB-818] CMP1.1 and CMP2.x beans not required to implement javax.ejb.EntityBean * [OPENEJB-807] CMP2 EntityBean interface methods auto-implemented * [OPENEJB-814] CMP2 cmp-field declarations are optional * [OPENEJB-810] CMP ejbPostCreate methods made optional * [OPENEJB-812] Explicitly check for CMP/BMP ejbHome.remove(ejbObject) mistake * [OPENEJB-916] Local Client java:comp/ TransactionSynchronizationRegistry lookup *
Re: persistence.xml in a Jar in Tomcat Common classloader (ERROR : PersistenceUnit already deployed)
On Oct 28, 2008, at 2:08 AM, Henri Gomez wrote: Could it be done for 3.1 release ? Hi to all, In the 3.1 release changelog I could see : EAR-style classpath application discovery groups individual modules as an EAR allowing sharing of persistence units and improved connector and custom MDB deployment. Did it what we discussed in this thread ? That's actually a different feature. This was another long release cycle (binaries were rolled on the 9th). The global persistence unit feature might be a little tricky to turn around, but I'm sure we can get it in. Filed a jira for it here: https://issues.apache.org/jira/browse/OPENEJB-932 (get notifications - https://issues.apache.org/jira/secure/ViewIssue.jspa?id=12407377watch=true) -David
Re: How to remove stateful sessions programmatically ?
On Oct 22, 2008, at 4:11 AM, Jean-Sébastien Scrève wrote: Ok thanks for the tip David. What I try to implement is conversation between Tapestry and OpenEJB. This conversation concept is already implemented into Seam. Very interesting. I store the stateful instance into a web session and I'd like to remove the instance as soon as the session expires. That's why I thought that an API that would allow us to remove stateful could be helpful. Another trick is to have an interceptor associated with the stateful bean that throws a runtime exception when you want to remove the stateful bean. Any unchecked exception not marked as an @ApplicationException will cause the stateful bean (and the interceptors instances associated with it) to be discarded. Not quite the same as @Remove as the @PreDestroy method of the stateful bean won't be called. But is something you could use as a last resort. I know it already exists in OpenEJB but a standard API to parse deployment information outside sessions beans could also be a nice thing. What do you think ? I've actually been wanting to implement something similar, basically Stateful Session beans where the instance itself is tracked within the scope of the http session under the covers. A Stateful Bean whose state is tied to the HTTP Session. A Stateful HTTP Session Bean. A Servlet could have a reference to one injected, not have to store it in it's HttpSession, and when it uses the reference we would under the covers delegate the call to an instance stored in the http session or create one if one didn't exist. It would also make it so that several references to the same stateful bean in a webapp would all point to the same instance, rather than each getting it's own individual instance as they do now. -David
Re: Inspect database when using embedded OpenEJB
On Oct 22, 2008, at 3:15 AM, Bernhard Humm wrote:
David Blevins wrote:
In OpenEJB 3.0, when using the supplied HSQL datasource in a TestCase
we should be using an in memory database with the JdbcUrl of
jdbc:hsqldb:mem:hsqldb. In OpenEJB 3.0 that sometimes worked and
sometimes didn't (depending on if you had a conf/ directory in your
openejb.base path), in which case the files were written to disk and
the JdbcUrl ended up as jdbc:hsqldb:file:data/hsqldb/hsqldb which
would be relative to your openejb.base path as in ${openejb.base}/
data/hsqldb/hsqldb.
In OpenEJB 3.1 we have a better way of detecting when we are running
embedded and the JdbcUrl will always be jdbc:hsqldb:mem:hsqldb
unless explicitly changed.
...
Dear David,
thank you for your detailed answer. However, it indeed does not work
with
OpenEJB 3.0 in my case. Is there a way of getting OpenEJB 3.1 to test
whether it works with the new release?
Wanted to respond to this earlier, but was swamped with finalizing the
release. Anyway, it's up now. Give it a try and hopefully things work.
If not post some config details and maybe we can spot something.
-David
Re: Help required with OpenEJB integration with JSF Hibernate and Spring
On Oct 21, 2008, at 7:00 PM, suhaas wrote: At this point in time, I have drilled down the problem to Spring 2.0 and OpenEJB 3.0 integration. As mentioned in the original problem statement older application (without OpenEJB) is using JSF - backing bean - service locator flow to call a DAO implementaion which is composed of HibernateTemplate ( org.springframework.orm.hibernate3.HibernateTemplate ). Hi Suhaas, As part of the OpenEJB 3.1 release we added some Spring integration code that should help to sew things together. We consider it a prototype and will be relying heavily on feedback to improve it. I've created an example which helps to show how it works. http://openejb.apache.org/3.0/spring-ejb-and-jpa.html We've also rewritten this page to detail some of the new functionality. http://openejb.apache.org/3.0/spring.html For use in a webapp, you won't want to use the ClassPathApplication or Application beans. For this first iteration you'll have to use the org.apache.openejb.spring.EJB bean to import the beans you want to make available to Spring. We would like to fix things up so the same automatic behavior works the same way in all settings; embedded, standalone, in tomcat. So the beans ClassPathApplication and Application will likely be deprecated and replaced with something that does exactly that. Anyway, give it a look over and try some things out. We are definitely open to feature requests on this functionality. -David
Re: Error Building OpenEJB Source File
Hi Suhaas,
I did try to build the 3.0 sources. I didn't get the error that you
got but I did find an issue with a missing dependency caused by the
maven-shade-plugin.
As 3.1 was just released, I tried again with that source to make sure
it could build from the src zip. Everything built cleanly. Here's
the command I used:
mvn clean install
Give that a try and feel free to post any issues.
-David
On Oct 21, 2008, at 10:20 AM, suhaas wrote:
Hi,
I wanted to build a jar out of Open EJB source code with Eclipse. So I
downloaded openejb-3.0-src.zip from the website and unzipped it. At
the root
of the unzipped directory, there is a pom.xml. When I run
mvn package or mvn clean package install I get the following
build error
[INFO] Error building POM (may not be this project's POM).
This is the Maven 2 Log
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] OpenEJB
[INFO] OpenEJB :: Dependencies
[INFO] OpenEJB :: Dependencies :: XBean Finder
[INFO] OpenEJB :: Dependencies :: XBean Reflect
[INFO] OpenEJB :: iTests
[INFO] OpenEJB :: iTests Beans
[INFO] OpenEJB :: iTests Servlets
[INFO] OpenEJB :: iTests Client
[INFO] OpenEJB :: iTests Interceptor Beans
[INFO] OpenEJB :: iTests App
[INFO] OpenEJB :: iTests Web
[INFO] OpenEJB :: Container
[INFO] OpenEJB :: Container :: Loader
[INFO] OpenEJB :: Container :: Java Agent
[INFO] OpenEJB :: Container :: Java EE
[INFO] OpenEJB :: Container :: Core
[INFO] OpenEJB :: Server
[INFO] OpenEJB :: Server :: Client
[INFO] OpenEJB :: Server :: Core
[INFO] OpenEJB :: Server :: EJBd
[INFO] OpenEJB :: Server :: Admin
[INFO] OpenEJB :: Server :: Http
[INFO] OpenEJB :: Server :: WebAdmin
[INFO] OpenEJB :: Server :: Telnet
[INFO] OpenEJB :: Server :: ActiveMQ
[INFO] OpenEJB :: Server :: CORBA
[INFO] OpenEJB :: Server :: Derby Network Service
[INFO] OpenEJB :: Server :: Hsql
[INFO] OpenEJB :: Server :: Webservices
[INFO] OpenEJB :: Server :: Axis
[INFO] OpenEJB :: Server :: Axis2
[INFO] OpenEJB :: Server :: CXF
[INFO] OpenEJB :: Examples :: Simple Stateful Pojo
[INFO] OpenEJB :: Examples :: Simple Stateless Pojo
[INFO] OpenEJB :: Examples :: Simple Webservice
[INFO] OpenEJB :: Examples :: EJB 2.1 Component Interfaces
[INFO] OpenEJB :: Examples :: @EJB Injection
[INFO] OpenEJB :: Examples :: @Resource env-entry Injection
[INFO] OpenEJB :: Examples :: @Resource DataSource Injection
[INFO] OpenEJB :: Examples :: @PersistenceContext EntityManager
Injection
[INFO] OpenEJB :: Examples :: Testing Transactions
[INFO] OpenEJB :: Examples :: Testing Security
[INFO] OpenEJB :: Examples :: Interceptors
[INFO] OpenEJB :: Examples :: Expanded support for Env Entries
[INFO] OpenEJB :: Examples :: Hello World - Weblogic
[INFO] OpenEJB :: Examples :: JPA with Hibernate
[INFO] OpenEJB :: Examples :: Telephone Stateful Pojo
[INFO] OpenEJB :: Web Examples :: EJB Examples War
[INFO] OpenEJB :: Web Examples
[INFO] OpenEJB :: Examples
[INFO]
[INFO] Building OpenEJB
[INFO]task-segment: [package]
[INFO]
[INFO] Setting property: classpath.resource.loader.class =
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on = 'false'.
[INFO] Setting property: resource.loader = 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound = 'false'.
[INFO] [remote-resources:process {execution: default}]
[INFO] [dependency-report:report {execution: default}]
[INFO] No dependencies to report
[INFO] [bundle:manifest {execution: bundle-manifest}]
[INFO] [site:attach-descriptor]
[INFO]
[INFO] Building OpenEJB :: Dependencies
[INFO]task-segment: [package]
[INFO]
[INFO] [remote-resources:process {execution: default}]
[INFO] [dependency-report:report {execution: default}]
[INFO] No dependencies to report
[INFO] [bundle:manifest {execution: bundle-manifest}]
[INFO] [site:attach-descriptor]
[INFO]
[INFO] Building OpenEJB :: Dependencies :: XBean Finder
[INFO]task-segment: [package]
[INFO]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error building POM (may not be this project's POM).
Project ID: org.apache.maven.plugins:maven-surefire-plugin
POM Location: C:\Documents and
Settings\Suhas.Valanjoo\.m2\repository\org\apache\maven\plugins
\maven-surefire-plugin\2.4\maven-surefire-plugin-2.4.pom
Reason: Not a v4.0.0 POM. for project
Re: [ANN] OpenEJB 3.1 Released
All, Just wanted to add that any mention of the 3.1 release in your blog (if you have one) is greatly appreciated and a very fine way to express thanks. Every little bit helps. And in many ways the voices of several individuals says much more than the one or two theserverside.com/ infoq.com posts we get a year. All the best, David On Oct 27, 2008, at 7:55 PM, David Blevins wrote: Download binaries here: http://openejb.apache.org/download.html Highlights - Major new features: - EJB 3.1 Singleton Support - EJB Constructor Injection - Spring Integration - Multicast Client-Server Discovery Significant Improvements: - EAR-style classpath application discovery groups individual modules as an EAR allowing sharing of persistence units and improved connector and custom MDB deployment. - Detection of EclipseLink, TopLink, and Hibernate as JPA providers to automatically adds the right persistence unit property to for wiring in the OpenEJB TransactionManager. - System Property and InitialContext property overriding now applies to persistence-unit properties and logging levels. - Login/logout now possible in an embedded scenario via InitialContext params and initialContext.close() respectively. - Complete overhaul of all client/server connection management dramatically increases performance. - Several new checks added to Application Validation ruleset, some reworked to give even more details. Full changelog - New Features: * [OPENEJB-836] Singleton Session Beans * [OPENEJB-839] Singleton Read and Write method locking * [OPENEJB-841] Singleton @DependsOn load ordering * [OPENEJB-840] Singleton @Startup load-on-startup * [OPENEJB-837] Singleton Bean-Managed Concurrency * [OPENEJB-838] Singleton Container-Managed Concurrency * [OPENEJB-821] EAR-style aggregation of modules discovered in the classpath * [OPENEJB-920] JDBC/DataSource based login module * [OPENEJB-913] Client Connection Failover and Request Retry * [OPENEJB-912] Client-side Connection Pool * [OPENEJB-857] Client connection KeepAlive * [OPENEJB-911] Graceful shutdown of client/server connections * [OPENEJB-903] Multicast discovery and grouping * [OPENEJB-905] PersistenceUnit property overriding * [OPENEJB-898] Property overriding for logging configuration * [OPENEJB-897] LocalInitialContext.close() to logout of embedded container * [OPENEJB-894] LocalInitialContext.close() to shutdown embedded container * [OPENEJB-896] VM-scoped Security for embedded scenarios * [OPENEJB-805] JMS runs port-free in embedded mode * [OPENEJB-785] EJBd protocol over SSL * [OPENEJB-881] Automatically set eclipselink.target-server for EclipseLink * [OPENEJB-880] Automatically set toplink.target-server for TopLink * [OPENEJB-801] Automatically set hibernate.transaction.manager_lookup_class for Hibernate Improvements: * [OPENEJB-893] Improved JavaAgent/JPA enhancement for Unit Tests * [OPENEJB-826] Improved detection of testing and embedded scenarios * [OPENEJB-899] Improved classpath configuration searching * [OPENEJB-831] PersistenceModule discoverable via the classpath * [OPENEJB-892] Remove ASM dependency * [OPENEJB-813] Example: CMP2 EntityBean * [OPENEJB-348] Example: Minimal MessageDriven Bean via @MessageDriven * [OPENEJB-850] Example: Singleton bean with bean vs container concurrency * [OPENEJB-359] Example: Using JMS * [OPENEJB-848] Validation: @TransactionAttribute mistakenly used on beans with Bean-Managed Transactions * [OPENEJB-855] Validation: Init/Remove annotations not used on MessageDriven, Stateless, or Singleton beans * [OPENEJB-677] Validation: PrePassivate/PostActivate not used on MessageDriven or Stateless * [OPENEJB-844] Validation: Singleton @Lock annotation not used with Bean-Managed Concurrency * [OPENEJB-846] Validation: Singleton mistakenly using @PrePassivate and @PostActivate * [OPENEJB-808] Validation: Unused ejbCreate methods * [OPENEJB-809] Validation: Unused ejbPostCreate methods * [OPENEJB-859] Improved validation for home, remote, local- home, local, business-local and business-remote elements * [OPENEJB-817] ID portion of property overriding no longer case sensitive * [OPENEJB-856] Upgrade to OpenJPA 1.1.0 * [OPENEJB-904] Pluggable Client/Server connection strategies and factories * [OPENEJB-799] Support META-INF/env-entry.properites as an alternative to META-INF/env-entries.properies * [OPENEJB-800] Default env-entry-type to java.lang.String * [OPENEJB-823] Print Service properties on debug * [OPENEJB-825] Eliminate possible mismatch of TxRecovery flag between TransactionManager and Resources * [OPENEJB-829] Automatically add an @DeclareRole ref for any role listed in @RolesAllowed * [OPENEJB-828] @EJB(name) value used to resolve ambiguous refs * [OPENEJB-818] CMP1.1 and CMP2.x beans not required to implement javax.ejb.EntityBean * [OPENEJB-807] CMP2
Additional OpenEJB 3.1 Release notes
We had a few items that didn't make it into the auto-generated release notes. We've gone through and manually added in some missing entries. The RELEASE-NOTES.txt for the 3.1 release has been updated, but for your convenience here are the items that have been added: New Features: * [OPENEJB-126] Constructor Injection * [OPENEJB-935] Spring Integration * [OPENEJB-933] Injection Support for JSF 1.2 ManagedBeans * [OPENEJB-941] ConnectorModule discoverable via the classpath (rar files) Improvements: * [OPENEJB-900] Example: Testing Security via InitialContext login/ logout * [OPENEJB-936] Log Tomcat resources imported into OpenEJB * [OPENEJB-943] Improved support for non-JMS Connectors * [OPENEJB-940] Severely improved client performance over ejbd * [OPENEJB-946] Optimized annotation scanner to determine if a jar is an ejb jar more quickly * [OPENEJB-939] Write the cmp mappings when openejb.descriptors.output is set to true * [OPENEJB-944] Allow value of server service only_from property to use comma, tab and newline as a separator * [OPENEJB-938] Improved the validation check on methods to look for mismatched arguments or conflicting case * [OPENEJB-934] Better support for external activemq.xml configuration * [OPENEJB-937] Improved StatefulContainer instance caching * [OPENEJB-948] Container AccessTimeout and TimeOut values expressible as text 200ms, 1 hour, 5 min, etc. * [OPENEJB-947] Command line tool for monitoring multicast heartbeat Bugs: * [OPENEJB-797] Unable to load servlet class: javax.faces.webapp.FacesServlet * [OPENEJB-874] SystemInstance is not updated with the properties defined in conf/system.properties * [OPENEJB-945] Should call stop() on the remaining ResourceAdapters during destroy() * [OPENEJB-873] Deploying the same ejb in two different webapps causes a DuplicateDeploymentIdException * [OPENEJB-901] Fixed broken isCallerInRole when using Tomcat JAASRealm with the TomcatSecurityService * [OPENEJB-942] Fixed potential NullPointerException scanning servlets that have no servlet class (i.e. are JSPs) -David
Re: Help: Eclipse RCP as remote OpenEJB client
This is a tricky one. Both the
org.apache.openejb.client.RemoteInitialContextFactory and
org.apache.openejb.client.EJBObjectProxy are in the same jar so should
be available equally.
I wonder if eclipse is changing the thread context classloader to one
that doesn't contain the openejb-client library. Right before your
lookup call, execute some code like this to see what is there.
ClassLoader cl = Thread.currentThread().getContextClassLoader();
cl.loadClass(org.apache.openejb.client.EJBObjectProxy);
We use the thread context classloader to deserialize the objects that
come off the wire, so if it's changed to a classloader that doesn't
contain your app and the openejb-client jar than nothing will work.
-David
On Oct 30, 2008, at 5:43 AM, Wilingson wrote:
I have an eclipse RCP application based on eclipse 3.4. I want it to
connect
remotely to and openejb server. I have openejb-client-3.0.jar on the
classpath. My connection and lookup code is as follows:
try {
Properties properties = new Properties();
properties.put(Context.INITIAL_CONTEXT_FACTORY,
org.apache.openejb.client.RemoteInitialContextFactory);
InitialContext ctx = new InitialContext(properties);
Server s = (Server) ctx.lookup(Server.class.getName()
+Remote);
} catch (Exception e) {
e.printStackTrace();
}
This piece of code bombs out at the line : Server s = (Server)
ctx.lookup(Server.class.getName()+Remote);
with the following stack trace:
java.lang.IllegalArgumentException: interface
org.apache.openejb.client.EJBObjectProxy is not visible from class
loader
at java.lang.reflect.Proxy.getProxyClass(Proxy.java:353)
at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:581)
at
org
.apache
.openejb
.client
.proxy.Jdk13ProxyFactory.newProxyInstance(Jdk13ProxyFactory.java:118)
at
org
.apache
.openejb
.client.proxy.ProxyManager.newProxyInstance(ProxyManager.java:107)
at
org
.apache
.openejb
.client.EJBObjectHandler.createEJBObjectProxy(EJBObjectHandler.java:
102)
at
org
.apache
.openejb.client.JNDIContext.createBusinessObject(JNDIContext.java:207)
at org.apache.openejb.client.JNDIContext.lookup(JNDIContext.java:248)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at
zw
.co
.synergy.supervision.SuperVisionPlugin.start(SuperVisionPlugin.java:
45)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl
$2.run(BundleContextImpl.java:1009)
at java.security.AccessController.doPrivileged(Native Method)
at
org
.eclipse
.osgi
.framework
.internal
.core.BundleContextImpl.startActivator(BundleContextImpl.java:1003)
at
org
.eclipse
.osgi
.framework
.internal.core.BundleContextImpl.start(BundleContextImpl.java:984)
at
org
.eclipse
.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:
346)
at
org
.eclipse
.osgi
.framework.internal.core.AbstractBundle.start(AbstractBundle.java:265)
at
org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:
400)
at
org
.eclipse
.core
.runtime
.internal
.adaptor
.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111)
at
org
.eclipse
.osgi
.baseadaptor
.loader.ClasspathManager.findLocalClass(ClasspathManager.java:427)
at
org
.eclipse
.osgi
.internal
.baseadaptor
.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:193)
at
org
.eclipse
.osgi
.framework
.internal.core.BundleLoader.findLocalClass(BundleLoader.java:368)
at
org
.eclipse
.osgi
.framework
.internal.core.BundleLoader.findClassInternal(BundleLoader.java:444)
at
org
.eclipse
.osgi
.framework.internal.core.BundleLoader.findClass(BundleLoader.java:397)
at
org
.eclipse
.osgi
.framework.internal.core.BundleLoader.findClass(BundleLoader.java:385)
at
org
.eclipse
.osgi
.internal
.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:87)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at
org
.eclipse
.osgi
.framework.internal.core.BundleLoader.loadClass(BundleLoader.java:313)
at
org
.eclipse
.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:
227)
at
org
.eclipse
.osgi
.framework
.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1274)
at
org
.eclipse
.core
.internal
.registry
.osgi
.RegistryStrategyOSGI
.createExecutableExtension(RegistryStrategyOSGI.java:160)
at
org
.eclipse
.core
.internal
.registry
.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:
867)
at
org
.eclipse
.core
.internal
.registry
.ConfigurationElement
.createExecutableExtension(ConfigurationElement.java:243)
at
org
.eclipse
.core
.internal
.registry
Re: JUnit question
On Nov 5, 2008, at 2:50 PM, ericp56 wrote:
That's already included in my classpath via openejb-core-3.0.jar (in
Geronimo
server).
Not sure I follow. The embeddable EJB container functionality for
unit testing doesn't use the Geronimo server. Also Geronimo doesn't
use commons-dbcp as it has it's own connection management code.
You could try something like this in your test case to see what is in
our classpath, assuming the Eclipse classloader is a subclass of
URLClassLoader (good chance of that).
ClassLoader classLoader =
Thread.currentThread().getContextClassLoader();
System.out.println(classLoader + classLoader);
System.out.println(classLoader.class +
classLoader.getClass().getName());
if (classLoader instanceof URLClassLoader) {
URLClassLoader urlClassLoader = (URLClassLoader) classLoader;
URL[] urls = urlClassLoader.getURLs();
for (URL url : urls) {
System.out.println(url = + url.toExternalForm());
}
}
-David
Re: Inspect database when using embedded OpenEJB
On Oct 29, 2008, at 3:58 AM, Bernhard Humm wrote: thanks a lot for your response. I have installed the new release. However, I still can't find database values on disk. All JUnit test cases that create and retrieve entity beans run fine (OpenEJB is really a great product :-)). In my NetBeans project there is a path with HSQL database files: C:\temp\NetBeans\LibraryX\tmp\testing\data\hsqldb\hsqldb.* However, after running the test cases, the files don't seem to be touched (old file date). I can connet to this database from the NetBeans database viewer: Database URL: jdbc:hsqldb:file:/temp/NetBeans/LibraryX/tmp/testing/data/hsqldb/ hsqldb Driver : org.hsqldb.jdbcDriver Schema: PUBLIC Product:HSQL Database Engine User: sa Password: Database product name: HSQL Database Engine Database product version: 1.8.0 However, there are no current values. To my surpise, the database contained tables and values from earlier tests. But the values were not updated by current tests. After deleting the tables, they were not re-created. If there were values from older tests that's a good sign. Figuring out why new updates aren't showing up may be a process of elimination. I suspect that the issue may be what I mentioned previously that I'm not sure more than one VM (i.e. more than on hsql) can be using the HSQL database files at the same time. So if the Netbeans database viewer is running while the test is running, that might be the issue. One simple test would be to write a test case that uses the java.sql.DriverManager and JDBC directly to add and update a table (any made up table), then see if you can see it in the NetBeans database viewer. -David
Re: PersistenceContext problems after upgrade to 3.1
Hi Oliver, In OpenEJB 3.0, each module (ejb-jar) that we discovered in the classpath was treated as if it had been deployed individually as a standalone app. This put the restriction in there that any persistence units you referenced had to be in the same app (ejb-jar module) and were not visible in other apps. In OpenEJB 3.1, each module (ejb-jar, persistence archive, or resource arcive) that we discover in the classpath will be treated by default as if it had been deployed together as an ear. This allows for a more straight forward way of sharing persistence units across all modules. So persistence units can be reused without the need to redeclare them. As well, they can be in a module all by itself, no ejbs or ejb-jar.xml required. To get OpenEJB 3.1 to act like OpenEJB 3.0 in this regard, set the new openejb.deployments.classpath.ear property to false. That will get everything working as it did in 3.0 and you can explore new options with a functioning build. With the new functionality some of those options would be to only declare the persistence.xml in either t4-core-utils or t4-core-commons and have it reused in both, or move it it to third module say t4-core- persistence and reuse it in both. Seems the t4Seam unit in t4-core- commons and t4-core-utils aren't exactly the same, so not sure which would be the one you reuse and which you delete. Another clever approach might be to put the persistence.xml files in the maven test-classes/ directory where maven will ensure it's only visible when the tests for that module are run (using the jar-file element where needed). Hope this helps and hope you find the new options useful. -David On Nov 10, 2008, at 5:05 AM, chawax wrote: Hi, I used OpenEJB 3.0 as embedded EJB3 container for unit tests in a Maven project. Now I try to upgrade to OpenEJB 3.1 but I encounter problems I had not seen before. Actually for some development organization reasons, my EJB3 entities are in many Maven projects, each one having its persistence.xml file with the same persistence unit. There are dependencies between these projects. For example I have two projects : t4-core-utils and t4-core-commons. The second one depends on the first one. So in the persistence.xml for t4-core-commons, I use jar-file tag. The persistence.xml file for t4-core-commons is like this : persistence xmlns=http://java.sun.com/xml/ns/persistence; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd; version=1.0 persistence-unit name=t4Seam providerorg.hibernate.ejb.HibernatePersistence/provider jta-data-sourcejava:/jdbc/t4Seam/jta-data-source jar-file../test-classes/lib/t4-core-utils-core.jar/jar-file mapping-fileMETA-INF/orm-commons.xml/mapping-file mapping-fileMETA-INF/orm-utils.xml/mapping-file properties property name=hibernate.hbm2ddl.auto value=update/ property name=hibernate.show_sql value=false/ /properties /persistence-unit /persistence And the persistence.xml file for t4-core-utils is like this : persistence xmlns=http://java.sun.com/xml/ns/persistence; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd; version=1.0 persistence-unit name=t4Seam providerorg.hibernate.ejb.HibernatePersistence/provider jta-data-sourcejava:/jdbc/t4Seam/jta-data-source mapping-fileMETA-INF/orm-utils.xml/mapping-file properties property name=hibernate.hbm2ddl.auto value=update/ property name=hibernate.show_sql value=false/ /properties /persistence-unit /persistence But when my app starts, I have errors using @PersistenceContext annotation in my EJB3 session beans. For example : ERROR - FAIL ... EmployeeDaoImpl: @PersistenceContext unitName has multiple matches: unitName t4Seam has 2 possible matches. What has changed about this from 3.0 to 3.1 ? And what should I do to make it work as it used to work ? Thanks in advance, Olivier -- View this message in context: http://www.nabble.com/PersistenceContext-problems-after-upgrade-to-3.1-tp20419521p20419521.html Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: ServiceProvider Id in openejb.xml
On Nov 10, 2008, at 6:02 PM, ebmm_axis wrote: So,I've been playing around witht his a little bit more, but I still can't get it to work... On the OpenEJB site it states the following: The service-jar.xml should be placed not in the META-INF but somewhere in your package hierarchy (ours is in /org/apache/openejb/service- jar.xml) which allows the services in your service-jar.xml to be referenced by name (such as DefaultStatefulContainer) or more specifically by package and id (such as org.apache.openejb#DefaultStatefulContainer). I have a jar that I have copied to the lib subdirectory with a file called service-jar.xml. I don'tknow if the syntax of the service-jar.xml is right or not, but this is what I've found around the net... ServiceProvider id=myId provider-type=Resource class-name=org.myclass.myclass.TheClassIWantToUse /ServiceProvider In my openejb-jar.xml config file I have the following: Resource id=defaultResource type=TheClassIWantToUse provider=myId /Resource This is really close, you just need to add the package part to the 'provider' attribute. So if you put it at META-INF/com.foo/service- jar.xml, the provider id would be com.foo#myId. That said, there might be a simpler way to do what you want overall. The service-jar.xml stuff is really geared towards plugging in something that needs to be configurable. If you simply want an instance of a specific class injected you can create a property editor for it as described here: http://openejb.apache.org/3.0/custom-injection.html . Let us know if that helps. Also, feel free to go into detail on the kind of thing you're looking to add to the system as we definitely use that feedback to drive features. We've talked about enhancements to the service-jar.xml/openejb.xml functionality as well as specific enhancements for j2ee connector configuration and more. -David
Re: Global JNDI Destinations with ActiveMQ
On Nov 13, 2008, at 12:23 PM, ebmm_axis wrote: First and foremost, thanks to the openEJB team for all the efforts... I am running openEJB as a stand alone server and haven't dove into it's use with a full application server. My reasoning for this is to keep things simple and just learn the ins and outs of OpenEJB. Using the Default Resource Adapter I am able to use MDBs successfully throughout my application. BUT, if I want to access any destination (queue or topic) GLOBALLY from a 'stand alone' client, I'm not able to. (i.e. I would like to globally resolve via JNDI my JMSConnectionFactory and the queues/topics that I have set up in openejb.xml) I am failing to connect the dots with the configurations required that will provide the global JNDI name resolution. Any comments and direction would be much appreciated.
Re: How to maintain a schema per user?
On Nov 10, 2008, at 2:35 PM, Paul Spencer wrote: Dain, I am using OpenJPA. Do you know if, and how, they support per user connections? OpenJPA will use whatever DataSources we give it. You might be able to use the Commons DBCP PerUserPoolDataSource as Dain suggests but it'll take some patching to get it wired in. This is the class that creates the DataSources inside OpenEJB org.apache.openejb.resource.jdbc.DataSourceFactory http://svn.apache.org/viewvc/openejb/tags/openejb-3.1/container/openejb-core/src/main/java/org/apache/openejb/resource/jdbc/DataSourceFactory.java?view=markup You might be able to patch it to create PerUserPoolDataSource instead. -David Paul Spencer Dain Sundstrom wrote: Assuming you are using straight JDBC or a persistence framework designed for per-user connections, I believe that the org.apache.commons.dbcp.datasources.PerUserPoolDataSource pool can do what you want, but I've never used per-user pools myself. Also, I bet that c3p0 (http://sourceforge.net/projects/c3p0/) can do it also. -dain On Nov 10, 2008, at 11:55 AM, Paul Spencer wrote: I have an application that requires a logged in user be restricted to a schema within the database. For the sake of illustration, the application is an address book and their is one schema per user. The database structure of the table and views within each schema are exactly same. My questions: 1) How do insure that a logged in user will only access the data in their schema? 2) How can a new schema be automatically created when user is created? Paul Spencer
Re: UserTransaction injection
On Nov 11, 2008, at 6:57 PM, Carlos MacLeod wrote: 2008-11-12 00:40:55,155 - ERROR - Error merging OpenEJB JNDI entries in to war /Bunda: Exception: null java.lang.NullPointerException at java.util.Hashtable.put(Hashtable.java:394) at org .apache .catalina .deploy.NamingResources.addResourceEnvRef(NamingResources.java:320) at org .apache .openejb .tomcat.catalina.TomcatJndiBuilder.mergeRef(TomcatJndiBuilder.java: 416) at org .apache .openejb .tomcat.catalina.TomcatJndiBuilder.mergeJndi(TomcatJndiBuilder.java: 140) at org .apache .openejb .tomcat.catalina.TomcatWebAppBuilder.start(TomcatWebAppBuilder.java: 270) at org .apache .openejb .tomcat .catalina .GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:58) This seems to be the heart of the issue. Unfortunately looking at the code here what might be going on is not obvious. Is it possible you could create a small app that reproduces the problem so we can try it on our end? I've created a JIRA here for it: https://issues.apache.org/jira/browse/OPENEJB-960 -David
Re: EntityManager Propagation Problem under 3.1
On Nov 18, 2008, at 4:29 PM, JimOR wrote: Apologies in advance for cross-posting, but my post to OpenJPA ( http://n2.nabble.com/EntityManager-Propagation-with-Extended-PersistenceContext-td1495977.html http://n2.nabble.com/EntityManager-Propagation-with-Extended-PersistenceContext-td1495977.html ) hasn't gotten any hits. To repeat from that post, I have: A) Parent entity with LAZY OneToMany ListChild, cascade: PERSIST,MERGE,REFRESH B) Child entity with EAGER ManyToOne Parent, cascade: PERSIST,MERGE,REFRESH C)Abstract CRUD class with injected Extended PersistenceContext, and requisite CRUD methods D) Parent Stateful bean that extends CRUD E) Child Stateful bean that extends CRUD Classes are enhanced in place via ant prior to junit test run. Under OpenEJB3.0 (OpenJPA 1.0.1), Any/All managed entities show as managed by either bean, but under OpenEJB 3.1 (with deployed OpenJPA 1.1.0 AND 'latest binary' 1.2.0), only the bean responsible for the load/ persist/merge of an entity shows the entity as managed. The following snippet works fine under 3.0, but throws an exception under 3.1: Parent p = parentBean.insert(new Parent(Foo)); Child c = childBean.insert(new Child(Bar, p)); WARN org .apache .geronimo.transaction.manager.TransactionImpl.beforeCompletion(Ln 516) - Unexpected exception from beforeCompletion; transaction will roll back openjpa-1.1.0-r422266:659716 nonfatal user error org.apache.openjpa.persistence.ArgumentException: The given instance entity.Parent-6264 is not managed by this context. FailedObject: entity.Parent-6264 Hi Jim, I'm not sure what would cause this issue. We should try isolating things so we can figure out where to look. First thing would be either: a. swap out the OpenJPA version in your OpenEJB 3.1 install with OpenJPA 1.0.1, or b. take your working OpenEJB 3.0 install and upgrade your OpenJPA version from OpenJPA 1.0.1 to OpenJPA 1.1.0 or OpenJPA 1.2.0 I'd go with b. If that recreates the issue than you can rule out OpenEJB and update your post on the OpenJPA list saying you know it isn't an OpenEJB issue. If it doesn't recreate the issue than we know it's something on our end and we can dig deeper. -David
Re: EntityManager Propagation Problem under 3.1
On Nov 21, 2008, at 3:04 PM, JimOR wrote: David, Looks like OpenEJB3.1 is the culprit. EJB3.0 with JPA 1.0.1, 1.1, 1.2 and 1.3-SNAPSHOT work as expected, but 3.1 with any of the JPA jars fails. This sample http://www.nabble.com/file/p20631026/sample.zip sample.zip should give you a head start recreating the scenario. I had to remove the OpenJPA jars to fit within the file upload size limit, drop them into sample/lib and you should be good to go. The sample/test folder contains the junit xml results of the test case under the various classpaths. FYI, filled a JIRA for this: https://issues.apache.org/jira/browse/OPENEJB-970 (notifications: https://issues.apache.org/jira/secure/ViewIssue.jspa?id=12410384watch=true) Thanks for putting that sample together! -David
Re: OpenEJB on Oracle
(excuse the delay - vacation)
On Nov 22, 2008, at 6:54 AM, JensToerber wrote:
Hint:
If you try to run it as openejb-3.1.war you get trouble with the
installer.jsp, because the install-Button there expects ContextPath
/openejb. It's better to run it as openejb.xml, because otherwise
you get
several config files (openejb.xml and openejb-3.1.xml) in
conf/Catalina/localhost.
We'll have to make note of that somewhere.
Still have to test this for persistent Messages. But this is the
step after
the next step.
Let us know how that went.
In the Examples i could change the JpaServlet to
public class JpaServlet extends HttpServlet {
@Resource(name = OracleORCL, type = javax.sql.DataSource.class)
private javax.sql.DataSource ds;
@PersistenceUnit(name = jpa-example)
private EntityManagerFactory emf; // only injected if not in a
container?
@PersistenceContext(name = jpa-example)
private EntityManager em;
...
Now the DataSource ds is injected and working on Oracle.
Great.
But i don't get the EntityManager injected. It is always null. Don't
know
why.
Per spec, servlets aren't allowed @PersistenceContext injection as the
context propagation models (TRANSACTION and EXTENDED) don't really fit
for a servlet. Definitely something we should add a validation
message for so at the least you would get a warning saying it won't
work and why.
But my call to categoryDaoLocal.persist(category) fails with no ending
exceptions like:
http://localhost:8080/HotelWebProject/servlet/TestServletilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:233)
[...]
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:44
7)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.IllegalArgumentException: can't parse argument
number
at java.text.MessageFormat.makeFormat(MessageFormat.java:1330)
at java.text.MessageFormat.applyPattern(MessageFormat.java:450)
at java.text.MessageFormat.init(MessageFormat.java:350)
at org.apache.openejb.util.Logger$4.compute(Logger.java:108)
at org.apache.openejb.util.Logger$4.compute(Logger.java:107)
at org.apache.openejb.util.Memoizer$1.call(Memoizer.java:42)
at
[...]
An invalidly formatted i18n message text slipped into one of our
Messages.properties files right before the release went out. This has
been fixed in the coming 3.1.1 (https://issues.apache.org/jira/browse/OPENEJB-950
)
A workaround is to set the related logging category to ERROR:
log4j.category.Transaction = ERROR
Next steps then are:
- Get our application work (MyFaces 1.2, Facelets, Timer, MDBs with
persistent Messages on Tomcat Cluster hopefully with Openejb)
- try to change JPA-Provider to Hibernate (still haven't looked for
automatically database schema update in OpenJPA-Provider)
Let us know if you need any help with those.
-David
Re: JMS ConnectionFactory
On Dec 5, 2008, at 8:46 AM, Oliver Günther wrote: Also, if the server should use the same ConnectionFactory as the remote client (which is needed, then the client and and a server bean what to send/receive messages on the same topic/queue) the openejb.xml needs to be changed: Resource id=My JMS Resource Adapter type=ActiveMQResourceAdapter BrokerXmlConfig broker:(tcp://localhost:61616)?useJmx=false #ServerUrl vm://localhost?async=true ServerUrl tcp://localhost:61616 DataSource My Unmanaged DataSource /Resource Don't know if this can also be done via properties ?! Any of the properties in an openejb.xml can be overridden as stated in the docs. It gets a little clunky with spaces but is still doable: -DMy\ JMS\ Resource\ Adapter.ServerUrl=tcp://localhost:61616 -David
Re: Unit Testing with openEjb
Hi Sanga, Hoping the OpenJPA folks have some insight on the error. -David On Dec 9, 2008, at 2:35 AM, sanga lawalata wrote: Greetings, I know the problem is that there is no in my persistence XML. properties property name=openjpa.jdbc.SynchronizeMappings value=buildSchema(ForeignKeys=true) / /properties but I get problems here that in DB : Table User (number id, varchar name, number address_id). And the address_id can be null. Table Address(number id, varchar description) I map the User table into entity UserBean for example and set my addressId as null because I dont need it. if i delete in my persitence.xml the xml fragment upstair (property fragment), i will get error message openjpa-1.1.0-r422266:659716 nonfatal general error org.apache.openjpa.persistence.PersistenceException: null at org .apache .openjpa .jdbc.kernel.AbstractJDBCSeq.getConnection(AbstractJDBCSeq.java:162) at org .apache .openjpa.jdbc.kernel.NativeJDBCSeq.nextInternal(NativeJDBCSeq.java: 209) If I put in my persitence.xml the xml fragment upstair (property fragment), i will get error message openjpa-1.1.0-r422266:659716 nonfatal general error org.apache.openjpa.persistence.PersistenceException: Table User has a foreign key to table Address that has not been generated. You must run the schema generator on all inter-related tables at once. i just want to insert and delete into User table using UserEntity and set the addressId as null because later addressId can be taken from another class who deals with it. (I am working with already existing application and db). Any advice guys to deal with this situation ?? best regards sanga lawalata
Re: Asking about env.properties
On Dec 10, 2008, at 5:42 AM, Sanga Lawalata wrote: Greetings, OpenEjb allow us to do injection of env-entry. We can use ejb- jar.xml or env.properties which is on src/main/resource/META-INF directory. I use this injected value in my unit testing. My question, it is possible these injected values are used in real system considering all of them are inside src/main/resource/META-INF and not inside src/test/resource/META-INF which I try to avoid. Or it will be automatically override by the bean deployment by his own ejb-jar.xml or env.properties. I'm not entirely sure I understood the question, but I can clarify that in any ejb archive deployed to OpenEJB the archive/META-INF/ejb- jar.xml is read in first and the values of archive/META-INF/env- entries.properties are then applied to the copy of archive/META-INF/ ejb-jar.xml we in memory. Meaning we take the env-entries.properties data and turn them into env-entry elements which are then added to or override the env-entry elements in the ejb-jar.xml. This works in any environment where OpenEJB is the container, such as embedded unit testing, Tomcat, Geronimo, standalone, etc. Hope this helps! -David
Re: OpenEJB issue with Oracle Driver
On Dec 19, 2008, at 5:29 PM, ericp56 wrote: Well, I went back and made sure the demo was working, which it was. I created a simple EJB project and ran unit tests on that to make sure I had it all OK. There were problems with the Junit classloader (I don't know why I didn't run into this in my previous testing...) but got it all resolved. Now I'm back to the same spot. I removed some of the lines last time. Here they are in full: p.put(Context.INITIAL_CONTEXT_FACTORY, org.apache.openejb.client.LocalInitialContextFactory); p.put(OracleXA, new://Resource?type=DataSource); p.put(OracleXA.JdbcDriver, oracle.jdbc.OracleDriver); p.put(OracleXA.JdbcUrl, jdbc:oracle:thin:uid/pwd@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP) (Host=server)(Port=1521))(CONNECT_DATA=(SID=DBID; p.put(Oracle, new://Resource?type=DataSource); p.put(Oracle.JdbcDriver, oracle.jdbc.OracleDriver); p.put(Oracle.JdbcUrl,jdbc:oracle:thin:uid/p...@server: 1521:DBID); p.put(Oracle.JtaManaged, false); context = new InitialContext(p); And I'm still getting the invalid username/password message. If I change the DBID to something bogus, I get an appropriate message, so I know it recognizes the Oracle.JdbcUrl line. Now the openejb.xml file doesn't help. I'm getting the same invalid login message using that. Hi Eric, Try adding the username and password as so: p.put(Context.INITIAL_CONTEXT_FACTORY, org.apache.openejb.client.LocalInitialContextFactory); p.put(OracleXA, new://Resource?type=DataSource); p.put(OracleXA.JdbcDriver, oracle.jdbc.OracleDriver); p.put(OracleXA.JdbcUrl, jdbc:oracle:thin:uid/pwd@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP) (Host=server)(Port=1521))(CONNECT_DATA=(SID=DBID; p.put(OracleXA.Username, scott); p.put(OracleXA.Password, tiger); p.put(Oracle, new://Resource?type=DataSource); p.put(Oracle.JdbcDriver, oracle.jdbc.OracleDriver); p.put(Oracle.JdbcUrl,jdbc:oracle:thin:uid/p...@server: 1521:DBID); p.put(Oracle.JtaManaged, false); p.put(Oracle.Username, scott); p.put(Oracle.Password, tiger); context = new InitialContext(p); If that turns out to solve your issue, ideas on how to make that more clear are welcome. Maybe we should just include them in the examples even though it makes the config look larger. Thoughts? -David
Re: OpenEJB on Oracle
On Dec 28, 2008, at 2:12 PM, JensToerber wrote:
Hi again,
Hi Jens!
I did not manage to run OpenEJB on Oracle in JUnit-Test if i
configure it
like this:
p.put(DATASOURCE, new://Resource?type=DataSource);
p.put(DATASOURCE + .JdbcDriver, oracle.jdbc.OracleDriver);
// it is not working thin driver is complaining about missing
username and/or password
// p.put(DATASOURCE + .JdbcUrl, jdbc:oracle:thin: +
USERNAME +
/ + PASSWORD + @192.168.2.96:1521:ORCL);
p.put(DATASOURCE + .JdbcUrl, jdbc:oracle:thin: + USERNAME
+ /
+ PASSWORD + @192.168.2.99:1521:XE);
p.put(oracle.jdbc.user, USERNAME);
p.put(oracle.jdbc.username, USERNAME);
p.put(oracle.jdbc.password, PASSWORD);
p.put(user, openejb);
p.put(password, openejb);
p.put(DATASOURCE + .JdbcUsername, openejb);
p.put(DATASOURCE + .JdbcPassword, openejb);
// openejb always sets the username to sa and password to
You'll want to specify the username and password properties as
follows:
p.put(Oracle, new://Resource?type=DataSource);
p.put(Oracle.JdbcDriver, oracle.jdbc.OracleDriver);
p.put(Oracle.JdbcUrl, jdbc:oracle:thin:
192.168.2.99:1521:XE);
p.put(Oracle.Username, foo);
p.put(Oracle.Password, bar);
Or if you want to use a DATASOURCE variable as you showed in your
code then like this:
String DATASOURCE = Oracle;
String USERNAME = foo;
String PASSWORD = bar;
p.put(DATASOURCE, new://Resource?type=DataSource);
p.put(DATASOURCE + .JdbcDriver, oracle.jdbc.OracleDriver);
p.put(DATASOURCE + .JdbcUrl, jdbc:oracle:thin:
192.168.2.99:1521:XE);
p.put(DATASOURCE + .Username, USERNAME);
p.put(DATASOURCE + .Password, PASSWORD);
Note that all properties are not case-sensitive, so username and
password will work as will UsErNaMe and pAsSwOrD and so on.
With the way you have it configured, you should see these four
warnings in your log file saying that your guesses are not correct:
WARN - Property JdbcUsername not supported by Oracle
WARN - Property jdbc.username not supported by Oracle
WARN - Property JdbcPassword not supported by Oracle
WARN - Property jdbc.user not supported by Oracle
WARN - Property jdbc.password not supported by Oracle
Then i found something here to configure OpenEJB in JUnit-Tests via
openejb.xml:
Properties properties = getProperties();
URL config =
this.getClass().getClassLoader().getResource(META-INF/openejb.xml);
properties.setProperty(openejb.configuration,
config.toExternalForm());
Context retContext = null;
try {
retContext = new InitialContext(properties);
...
Then Oracle Datasource is working in JUnit-Tests.
Fine.
That's also a fine way to configure things for a test case.
Got Timer running in OpenEJB JUnit-Test. It's straight forward.
Great!
I tried to get an MDB running. This is working now in my JBoss
(without
OpenEJB), not yet tested in Tomcat with OpenEJB, but it is not
working in
OpenEJB-JUnit-Test.
Initialization is working, OpenEJB does not complain about missing
Queue in
configuration.
I don't know if it should work in JUnit-Test.
Here my inspection code:
obj = retContext.lookup(queue);
if (obj instanceof ActiveMQQueue) {
ActiveMQQueue activeMQQueue =
(ActiveMQQueue) obj;
String physicalName = activeMQQueue.getPhysicalName(); // value
of
destination of openejb.xml - Resource ...destination .../resource
log.debug(physicalName: +
physicalName);
String qualifiedName =
activeMQQueue.getQualifiedName(); //
queue://physicalName
log.debug(qualifiedName: +
qualifiedName);
String destinationTypeAsString =
activeMQQueue.getDestinationTypeAsString(); // Queue
log.debug(destinationTypeAsString: +
destinationTypeAsString);
// may throw JMSException:
String queueName =
activeMQQueue.getQueueName(); // equals to
physicalName (?)
log.debug(queueName: + queueName);
Map options =
activeMQQueue.getOptions(); // currently null
log.debug(options: + options);
Properties ps =
activeMQQueue.getProperties();
logProperties(ps);
log.debug(ps: + ps);
Re: Catching OpenJPA validation exceptions in OpenEJB
On Dec 23, 2008, at 8:06 AM, Luis Fernando Planella Gonzalez wrote: Hi all! I'm using OpenEJB 3.1 under Tomcat. When I try to persist an invalid entity, say, with a field annotated with @Basic(optional=false) with a null value, all I get is a javax.ejb.EJBTransactionRolledbackException. After a couple of hours in debug, I've noticed the cause in tomcat_home/logs/transaction.log: org.apache.openjpa.persistence.InvalidStateException: The field creationDate of instance Member#null contained a null value; the metadata for this field specifies that nulls are illegal. How can I catch such exceptions in order to display an user-friendly message? Not sure I have any good ideas. If I recall correctly, the exception is thrown by the transaction manager doesn't contain this information therefore we are unable to throw it to you as the nested cause of EJBTransactionRolledbackException. Very recently another user, Geoff Callender, requested the same thing: https://issues.apache.org/jira/browse/OPENEJB-782 I'm not too familiar with the Geronimo transaction manager (which is the one we use). Dain or David, either of you have any thoughts on this? Note in that JIRA issue Geoff suggests a clever workaround which is to call entityManager.flush() in a try/catch block, which will allow you to explicitly catch the InvalidStateException. Though I agree with Geoff that ideally this would be propagated with the EJBTransactionRolledbackException. -David
Re: Unauthenticated principal
On Dec 30, 2008, at 3:51 AM, Luis Fernando Planella Gonzalez wrote:
Well, my problem is not really configuring the default (or
unauthenticated)
username, but it's roles.
We should already be adding a role of the same name so that people
could do as you demonstrate below. I've checked the code to be sure
and it looks like that is the case.
I'd like to annotate EJB methods like this:
@RolesAllowed({public, broker})
public void x() {}
@RolesAllowed({public, admin})
public void y() {}
@RolesAllowed(admin)
public void z() {}
I tried this out in embedded mode using guest instead of public
and it worked fine. Should work the same way in Tomcat.
Give the code above a try in Tomcat but with guest in the
RolesAllowed instead of public. If that works as I suspect, than
making the change to allow the default username to be changed should
do the trick.
-David
Re: Issue with using JPA in openejb
On Jan 2, 2009, at 1:51 AM, Debarshi Sanyal wrote:
Hi All,
New Year greetings!
Happy new year to you too!
I was trying to execute the example on EJB entity-manager provided
at *
http://openejb.apache.org/3.0/injection-of-entitymanager-
example.html.*
I have replaced the test case with a standalone client that, however,
performs exactly the same steps. However, I observed that while
insertion to
the database is occurring perfectly, the deletion does not take place.
Movies movies = (Movies) context.lookup(MoviesLocal);
movies.addMovie(new Movie(Quentin Tarantino, Reservoir
Dogs, 1992));
movies.addMovie(new Movie(Joel Coen, Fargo, 1996));
movies.addMovie(new Movie(Joel Coen, The Big Lebowski,
1998));
ListMovie list = movies.getMovies();
assertEquals(List.size(), 3, list.size());
*for (Movie movie : list) {
movies.deleteMovie(movie);
}*
Even after the previous steps, *movies.getMovies().size()* returns 3
which
is very strange.
That is very strange. I'm not sure what could be happening. When in
doubt add a entityManager.flush() statement and hope for an error
message :) (useful debug tactic with JPA -- just make sure to remove
it in production as it will affect performance) In this case I'd add
it right after the entityManager.remove(movie); call.
Hopefully that will dig up something.
Also double check that one of your modifications did not involve
deleting PersistenceContextType.EXTENDED from the example. That
could cause the issue as well -- entityManager.remove(foo) only works
if the object passed in is still attached [1].
-David
[1] Attached/Detached explained here
http://openejb.apache.org/3.0/jpa-concepts.html
