Are you setting the 'openjpa.RuntimeUnenhancedClasses' property to
'supported', if so don't?
You could also try using
@TransactionManagement(TransactionManagementType.BEAN) and manage your own
transaction.
@Resource
private UserTransaction transaction;
...
transaction.begin();
...
delete
...
tra
Was getting this same error attempting to do the same thing (SLF4J -
LOGBack).
Either removing the xercesImpl-2.9.1.jar from the lib directory
or setting
openejb.classloader.forced-skip=org.xml.saxr
..resolved the error. Which is the preferred solution?
Andy.
--
View this message in contex
On the client side try setting these system/context properties to higher
values before creating the InitialContext.
openejb.client.connection.pool.timeout//Default 1000 ms
openejb.client.connection.pool.size //Default 5
Set timeout to 5000 and size to to 50 for example, but play with
Without '-Dopenejb.classloader.forced-skip=org.xml.sax' we get the following
stacktrace on the first call to LoggerFactory.getLogger:
Failed to instantiate [ch.qos.logback.classic.LoggerContext]
Reported exception:
java.lang.LinkageError: loader constraint violation: when resolving
overridden met
Here is a complete list of jars used when this error occurs:
swizzle-stream-1.6.1.jar
sxc-jaxb-core-0.8-SNAPSHOT.jar
sxc-runtime-0.8-SNAPSHOT.jar
woodstox-core-asl-4.0.8.jar
wsdl4j-1.6.2.jar
wss4j-1.6.8.jar
xalan-2.7.1.jar
xbean-asm-shaded-3.13-SNAPSHOT.jar
xbean-bundleutils-3.13-SNAPSHOT.jar
xbea
Running as a win service using daemon, so embedded. Here is the batch, less a
few irrelevant entries. Adding the last line prevents the stacktrace.
%proc% //IS//AServer ^
--DisplayName="AServer" ^
--Install=%proc% ^
--Startup auto ^
--StartPath=%openejb% ^
-
I will try to get you something, just really bogged down with work. I hope I
can get some time tomorrow (Friday).
If you have an idea or pointers as to why this issue is arising then maybe I
can fix it in the process. Why does the following option fix it?
openejb.classloader.forced-skip=org.xml.s
A quick fix would be removing, renaming or replacing the
slf4j-jdk14-1.7.2.jar with the logback-classic-1.0.11.jar. Also ensure you
have logback-core-1.0.11.jar on the classpath.
Really we shouldn't be shipping slf4j-jdk14 or any other binding in the
tomee/lib directory (http://slf4j.org/faq.html#
Maybe the slf4j-jdk14 is being picked up by the TestNG plugin?
--
View this message in context:
http://openejb.979440.n4.nabble.com/slf4j-jdk14-1-7-2-jar-overrides-logback-tp4662958p4662971.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Here are a few tips that will help track down issues with the service
installation.
In the service.bat modify or add the following options (uninstall and
reinstall, and check logs):
--LogLevel=Debug
--LogJniMessages=1
Those options will reveal much more about what is going on during the
install
The choice is open for you to use just about any JDBC supported database.
Personally I am using (and have used for several years) Derby for an
embedded mode application and PostgreSQL for a remote version of the same
application. Both have proven to be extremely stable in production.
Andy.
--
Would you like to share some code to help you solve this problem.
Andy
--
View this message in context:
http://openejb.979440.n4.nabble.com/redelivery-of-MDB-with-BMT-tp4666382p4666387.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
OK, so this seems like a bad design to me.
@ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue =
"Auto-acknowledge"
So the chances are the message is acknowledged and dequeued if all
subscribers have it. This can also be asynchronous, so you have no control
over the message
Something else that may help is to override the default broker option:
useAsyncSend=false
This will ensure that the acknowledge is sent in-line.
--
View this message in context:
http://openejb.979440.n4.nabble.com/redelivery-of-MDB-with-BMT-tp4666382p4666427.html
Sent from the OpenEJB User ma
OK, I am wrong here:
CLIENT_ACKNOWLEDGE is not really supported on an EJB, so it must be the
'useAsyncSend=false' that is required to get this working the way you want.
I think the client URL parameter is 'async=false'.
Andy.
--
View this message in context:
http://openejb.979440.n4.nabble.co
Could you share the relevant code for the persist? Are you calling 'flush' on
the EntityManager at all?
Andy.
--
View this message in context:
http://openejb.979440.n4.nabble.com/Postgres-XA-transaction-rollback-tp4666429p4666430.html
Sent from the OpenEJB User mailing list archive at Nabble.c
No you're correct. Calling flush does just that, so a rollback is not
possible. That's what I was probing for , to make sure that was not the
case.
I do think that this.remoteService.test(); will be in it's own transactional
context and will not be affected by the rollback though? When
this.remote
Do not use a repeating timer, and then only restart the timer when your
method completes.
@Resource
private TimerService timerService;
@PostConstruct
public void postConstruct() {
this.timerService.createSingleActionTimer(5 minutes...
@Timeout
public void onTimeout(final Timer timer) {
...d
Provide a flag, something like this:
private final AtomicBoolean running = new AtomicBoolean(false);
@Override
public final void run() {
running.set(true);
while(running.get()){
.do something and regularly check 'running'
}
}
@PreDestroy
public void preDestroy() {
For a local context:
Get rid of Context.PROVIDER_URL and "openejb.ejbd.authenticate-with-request"
properties.
...and use Context.INITIAL_CONTEXT_FACTORY,
"org.apache.openejb.core.LocalInitialContextFactory" rather than
"org.apache.openejb.client.LocalInitialContextFactory"
Andy.
--
View this
Kalyan,
What you are describing is starting to feel like a fundamental design issue.
You may need to go back to the drawing board a little.
Passing an *EJB* into another thread will never work as you will loose all
context related data that is bound to the calling/request thread - You
cannot hand
21 matches
Mail list logo
