Session Beans are replicated perfectly. I have tested my app earlier with TomEE
1.6.0-Snapshot and tomcat 7 and same CODI version. It was working fine. Could
you please check if it is not a Tomee issue?
-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
G
Hi.
I am trying to get session replication working in my JSF + CODI application
with TomEE 1.6.0. Replication of SessionScoped beans seems to be working fine,
but not CODI Window Scoped beans. The State of WindowScoped beans is lost after
first reload.
You can easily reproduce the issue with
It works!
Updating OWB has solved the issue.
Great work! Thank you.
-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Gesendet: Donnerstag, 31. Oktober 2013 16:14
An: users@tomee.apache.org
Betreff: Re: AW: Session replication in TomEE 1.6.0-SNAPSHOT
Hm
I am testing on latest tomee 1.6.0-SNAPSHOT from repository. There is OWB
1.2.1-SNAPSHOT in it. Is it latest version from trunk? Can I test on it? When
not, how can I replace OWB in tomee starting with tomee maven plugin?
-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannib
Oh. Thank you for correcting me. :)
I have commited corrections in Interceptor. Exception is still there:
java.lang.NullPointerException
org.apache.webbeans.intercept.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:55)
de.test.cdi.TestInterceptor.intercep
As far as I know it is allowed by spec. Anyway deleting @ApplicationScoped and
@Default from interceptor does not solve the issue.
-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Gesendet: Donnerstag, 31. Oktober 2013 15:12
An: users@tomee.apache.org
Bet
After rebuild I've got another exception:
java.lang.NullPointerException
org.apache.webbeans.intercept.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:55)
de.test.cdi.TestInterceptor.intercept(TestInterceptor.java:28)
sun.reflect.NativeMethodAccesso
Got it! A have reproduced the issue. See my test app:
https://github.com/eiskonzept/tomee
AbstractDelegatingMap class was the cause. See PassivationCapableBean.
-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Gesendet: Donnerstag, 31. Oktober 2013 12:
I use only apache CODI 1.0.5. There are no other CDI extensions.
-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Gesendet: Donnerstag, 31. Oktober 2013 11:42
An: users@tomee.apache.org
Betreff: Re: AW: Session replication in TomEE 1.6.0-SNAPSHOT
do you u
No, there is no beans which are intercepting themselves.
I have tried different Bean/Interceptor combinations, but still can't reproduce
the issue in my sample app.
UserSettings is just usual Bean and I don't know why OWB trying to serialize it
as interceptor.
There is an exception which is
It looks like OWB is trying to serialize just regular CDI bean(which is not an
interceptor) as interceptor. Please note that it happens only when session is
replicated second time. That bean(UserSettings) is in interceptors map of
DefaultInterceptor handler with "null" key.
There is screenshot
Hi!
I have just tested replication in tomee-1.6.0-20131030.065404-219. OWB Bug
seems to be fixed, but there is new one.
The First replication works perfect, but after session migration to another
node I've got following exeception:
java.io.NotSerializableException: null is not serializable
Hi
There is the sample app: https://github.com/eiskonzept/tomee
Package the application and start two tomee instances with tomee maven plugin
(maven profiles "node1" and "node2"). Then open /index.xhtml from application
root.
The issue can be reproduced when replicated CDI bean is intercepted
I have tested replication with last 1.6.0-SNAPSHOT and got following exception:
java.io.NotSerializableException:
org.apache.webbeans.intercept.DefaultInterceptorHandler
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1180)
at
java.io.ObjectOutputStream.defaul
Thanks!
Will test it as soon as last version will be available in maven.
-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Gesendet: Freitag, 2. August 2013 16:15
An: users@tomee.apache.org
Betreff: Re: Session replication in TomEE 1.6.0-SNAPSHOT
Hi,
ju
Hi!
I have just tested session replication in TomEE 1.6.0-SNAPSHOT and got
following exception:
java.io.NotSerializableException:
org.apache.tomee.catalina.cdi.SessionNormalScopeBeanHandler$1
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1180)
at
java.io.O
Here it is: https://github.com/eiskonzept/tomee.git
There is preinitialized hsqldb database in the project.
To reproduce the issue:
1. package the project: mvn package
2. start tomee plugin with node1 profile: mvn tomee:run -P node1
3. open http://localhost:8080/tomee_replication-1.0/schedule.x
Integration test is needed to reproduce this issue, I think. Would be small
application enough for reproducing the issue on your side?
-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Gesendet: Sonntag, 21. April 2013 23:10
An: users@tomee.apache.org
Betr
Just tested with trunk version and JobStoreCMT. There is one limitation: timers
are executed after restart, but method TimerService.getTimers() returns empty
list, making it impossible to remove old timers. Are there any plans to fix
this limitation?
-Ursprüngliche Nachricht-
Von: Roma
That would be great. Is this functionality already implemented in TomEE?
Пользователь Romain Manni-Bucau писал:
Think we can persist stuff through quartz config
Le 19 avr. 2013 19:19, a écrit :
> Hello,
>
> I have a question in relation to Scheduling API in TomEE. As I know
> org.apache.opene
Hello,
I have a question in relation to Scheduling API in TomEE. As I know
org.apache.openejb.core.timer.DatabaseTimerStore is not implemented yet, and it
means that any task created with TimerService and persistent=true will be not
persisted over JVM restarts.
Is there any plans or estimations
Excellent! Thank you.
-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Gesendet: Dienstag, 5. März 2013 13:39
An: users@tomee.apache.org
Betreff: Re: AW: AW: CalendarTimers created with TimerService and
persistent=true are not persisted over tomee restart
But cron timers with persistent=true should be persisted over JVM restarts.
What is the purpose of persistent=true otherwise?
http://docs.oracle.com/javaee/6/api/javax/ejb/TimerConfig.html
"The persistent property determines whether the corresponding timer has a
lifetime that spans the JVM in
Yes, scheduler is stopped correctly.
-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Gesendet: Montag, 4. März 2013 23:51
An: users@tomee.apache.org
Betreff: Re: AW: AW: CalendarTimers created with TimerService and
persistent=true are not persisted over
I shutdown it normally. Not kill.
-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Gesendet: Montag, 4. März 2013 20:26
An: users@tomee.apache.org
Betreff: Re: AW: CalendarTimers created with TimerService and persistent=true
are not persisted over tomee r
You can see all SQL executed in test.db.log. I have tested it with DB2, and it
worked same.
I have purged DB, then restarted TomEE, scheduled a job and stopped TomEE after
a while. Here I've shared collected sql log:
https://docs.google.com/file/d/0B1jOAi2N2uY8eTVLblB0NUpaNmM/edit?usp=sharing
Shared file here:
https://docs.google.com/file/d/0B1jOAi2N2uY8eTVLblB0NUpaNmM/edit?usp=sharing
-Ursprüngliche Nachricht-
Von: John D. Ament [mailto:john.d.am...@gmail.com]
Gesendet: Montag, 4. März 2013 18:07
An: users@tomee.apache.org
Betreff: Re: CalendarTimers created with TimerServi
Here it is: https://github.com/eiskonzept/tomee.git
Just start tomee plugin with node1 profile, open /schedule.xhtml
and push "Schedule timer" Button.
Timer is scheduled(executed every second, see log) and listed on the page.
Restart application, open /schedule.xhtml again. There are no
schedu
I use TomEE 1.6.0-Snapshot(and have tested with 1.5.1 and 1.5.2-Snapshot too,
with same result).
Tried proposed configuration, with same result. There is my version with
adjusted jndi names and driverDelegateClass:
org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreCMT
org.quart
4 files are created in project root(I start tomee maven plugin here):
"\test.db.lck"
"\test.db.log"
"\test.db.properties"
"\test.db.script"
I have purged all this files, then restarted TomEE, scheduled a job and stopped
TomEE after a while. Please find attached test.db.log file.
-Ursprüng
Have changed to:
org.quartz.dataSource.testDS.jndiURL=openejb:Resource/jdbc/testDS
org.quartz.dataSource.testDSNonJta.jndiURL=openejb:Resource/jdbc/testDSNonJta
Have same result.
-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Gesendet: Montag, 4. März
Sorry, don't get your question. Which file do you mean? Test.db?
-Ursprüngliche Nachricht-
Von: John D. Ament [mailto:john.d.am...@gmail.com]
Gesendet: Montag, 4. März 2013 15:17
An: users@tomee.apache.org
Betreff: Re: CalendarTimers created with TimerService and persistent=true are
not
Hi.
CalenderTimers created with following code are not recovered after TomEE
restart. Are there some TomEE properties to make timers persistent across
restarts?
There is issue reproduction: https://github.com/eiskonzept/tomee.git
Just start tomee plugin with node1 profile, open /schedule.xhtml
Hi!
I am trying to start scheduled task with following code:
@Resource
private TimerService timerService;
...
public UUID createSingleActionTimer(long duration, Serializable info, Boolean
persistent, String userName) {
TimerIdentifier identifier = new TimerIdentifier(info, Type.single,
Hello!
We are using own version of quartz in our application. But tomee class loader
prevents loading of classes from our jar file (tomee scheduler initializes its
own quartz jar, before application start).
How is it possible to exclude, disable, or override class loading order of
tomee's qu
Did you start it with TomEE 1.5.2-Snapshot?
-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Gesendet: Donnerstag, 21. Februar 2013 14:43
An: users@tomee.apache.org
Betreff: Re: AW: Class loading problem in TomEE 1.5.1
did it and didnt get an exception :s
Sorry, forgot to mention: Session replication should be activated in both
server.xml:
-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Gesendet: Donnerstag, 21. Februar 2013 13:20
An: users@tomee.apache.org
Betreff: Re: AW: Class loading problem in TomE
Pages was really missing. Did you test it with
">pages/simpleRegistration/form.xhtml" ?
-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Gesendet: Donnerstag, 21. Februar 2013 13:20
An: users@tomee.apache.org
Betreff: Re: AW: Class loading problem in TomEE
I have managed to reproduce it with last TomEE Snapshot and this app:
https://docs.google.com/file/d/0B1jOAi2N2uY8ZWdxcmx6TjFvUEE/edit
Just deploy in cluster (apache + mod_jk + 2 nodes), open:
/simpleRegistration/form.xhtml and you will see the following
exception:
java.lang.RuntimeException:
There is the exception I got when TomEE have tried to replicate session with
CODI objects in it:
SEVERE: Manager [/hello-myfaces-codi-jsf20-example-1.0.5]: Unable to receive
message through TCP channel
java.lang.RuntimeException: by java.lang.NoClassDefFoundError:
org/apache/myfaces/extensions
Will it someday work in TomEE?
As far as understand, session replication in applications with Apache CODI is
not working because of same issue, right?
-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Gesendet: Donnerstag, 21. Februar 2013 10:29
An: users
Thank you for explanation.
I have used commons-lang for Serialization-Deserialization. Many other
libraries and applications are using it too, or deserializing objects without
respecting the TCCL.
Does it mean that all this Applications and libraries will not work in TomEE?
-Ursprüngli
Hi,
I have just reproduced an issue which I have in my Application.
Steps to reproduce:
*Checkout project from https://github.com/eiskonzept/tomee/
*Start TomEE maven plugin with node1 profile
*Open in browser: //index.xhtml
*Press submit button.
*Following code will be executed:
By
Hi,
I am trying to redirect absolutely all TomEE and application logs to log4j.
I have done following changes:
* Put log4j-1.2.17.jar, log4j.xml, slf4j-log4j12-1.7.2.jar,
tomcat-juli-adapters.jar into catalina_base/lib folder
* Replaced catalina_base/bin/tomcat-juli.jar with to
Yes, first stop current node then push save button.
Just tested with last snapshot and following cluster config:
got same exception. Additionally got exception after TomEE had tried to
replicate session:
SEVERE: Manager [/hello-myfaces-codi-jsf20-example-1.0.5]: Unable to receive
message t
I have just reproduced the issue with Apache CODI example app(here:
https://docs.google.com/file/d/0B1jOAi2N2uY8ZWdxcmx6TjFvUEE/edit?usp=sharing ).
To reproduce: install and open application context root, fill the form, stop
current node and press save button.
Exception:
java.lang.NullPointe
That was the issue. I become an exception in my application, but can't isolate
it in test app. CDI beans in real application are way complexer and something,
somewhere is not working.
I will try to reproduce it in the test app. I would appreciate any help.
-Ursprüngliche Nachricht-
Von
Did you mean openejb.session-context = http (not true) ?
I have checked that app is deployed on both nodes. Still have an exception.
Are there some specific settings for CDI beans replication?
-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Gesendet: Don
Hi,
Session replication is still not working. Just tested my application(JSF 2.0,
EJB, CDI, CODI) and got exception after TomEE has tried to replicate the
session.
I would like to reproduce this exception in test app, but have no idea how to
do it.
Could you also please summarize, which pro
What should I rebuild from sources? :)
I just replaced as proposed:
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger by
org.apache.commons.logging.Log=org.apache.openejb.log.commonslogging.Log4J4AppOpenEJB4ContainerLog
in my commons-logging.properties.
Or I got you wr
Just tried proposed workaround and got exception:
Error configuring application listener of class
com.opensymphony.webwork.lifecycle.SessionLifecycleListener
java.lang.ExceptionInInitializerError
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.ref
just have reproduced not exactly the same issue, but very similar, in my test
project: https://github.com/eiskonzept/tomee
Just package the app and start tomee-plugin with node1 profile.
Explanation:
I have two dependencies in my project: commons-logging and log4j. If I package
both librarie
I got further by copying log4j.jar in CATALINA_BASE/lib folder, but then I got
next NoClassDefFoundError.
Most confusing is that the same application deployed in TomEE Version 1.5.0
works perfectly.
I believe it is some kind of class loader issue. Are there some significant
class loader change
I have tried both: with commons-logging in my war file and without. With same
result(exception) in both cases.
I have tried to isolate the issue in small sample app, but without success.
Unfortunately I can't provide full application for reproduction.
Could you give some hints, how can I help yo
Hello,
I have following exception after version upgrade from 1.5.0 to 1.5.1.
Just replacing all jars in lib folder with jars from version 1.5.0 solves the
problem. I have tried 1.5.2-SNAPSHOT and got the same exception.
The class "org.apache.commons.logging.impl.Log4JLogger" contained in
common
55 matches
Mail list logo
