Actually it is desirable. You want the client to be async as well (server
async is not mandatory here). If we use daemon threads
Daemon threads is what we do.
Le 17 mai 2014 01:00, "Andy Gumbrecht" a écrit :
> It depends on how you are exiting the client. Make sure you close the
> context proper
You updated your project?
If so it means both apps uses same name
Le 17 mai 2014 01:27, "asotobu" a écrit :
> I have tried today with a simple WAR with HelloWorld servlet and still the
> same problem, I can only deploy one application, when I tried to deploy the
> second one the same exception o
Any idea why it worked before? OS dependent?
Le 17 mai 2014 01:45, "agumbrecht" a écrit :
> Hi jieryn,
>
> This has got me thinking along the lines of using 'lineEndings' in the
> maven-assembly-plugin, which is designed to address exactly this issue.
>
> It means splitting out tar.gz and zip ass
Hi
About mails: asf got a big issues and it is slowly sznding blocked mails
About your issue: ext is just taking properties creating an InitialContext
and looking up the ejb remote name. So localbean is not compatible.
Le 16 mai 2014 23:39, "hwaastad" a écrit :
> Something strange is happening
Hi
Is you have access to server.xml and catalina.properties just doing the
same using other folders works otherwise just do a war overlay of
tomee-webapp
Le 16 mai 2014 21:47, "Alex Wede" a écrit :
> hello guys,
>
> my question is:
> Is it possible to use tomcat like tomee without modifying any
Yep, just wanted to make it less obvious. Internal/custom releases are
not always possible - one sample is open source releases of EE
products. That said it just means we should continue what you started
to do (thank you for that) ie release more often ;)
Romain Manni-Bucau
Twitter: @rmannibucau
Something strange is happening with email to this list...it bounces.
And a reply from Romain never got into the list:
---
Remote bean name, ejb-name no link with java itself if you dont name your
ejb as the implementation
---
Anyway,
I had @Stateless @LocalBean on my bean implementation.
Removi
So you are saying that for a remote asynchronous EJB method call, there are
/two/ additional threads; one on the client to make the remoteCall, and one
on the server to wrap the method invocation. As a result, the problem we are
seeing is that the thread created on the client side has not yet invok
It depends on how you are exiting the client. Make sure you close the
context properly and don't just kill the process, it may not have
completed the call.
http://docs.oracle.com/javase/6/docs/api/javax/naming/InitialContext.html#close()
Can you share some code.
Andy.
On 14/05/2014 23:24, ym
if new no need of version which is good and if not new (fact =
em.find(Fact.class, dto.getId());) you can check it
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-16 1
hello guys,
my question is:
Is it possible to use tomcat like tomee without modifying any files in
the tomcat folder.
(I don't have access to the server)
I am using maven to get my dependencies for the web-app. I thought to
ship the dependencies(OpenEjb and JPA ...) with the war-file . Is my
If not ambiguous delete by default is ok
Le 16 mai 2014 17:04, "Thiago Veronezi" a écrit :
> Hi,
>
> If that's the case, we have a bug. I have this sample application with a
> "deleteUser" method:
>
> https://github.com/tveronezi/faceid/blob/master/src/main/groovy/faceid/rest/Users.groovy
>
> Las
After spending a couple of hours trying to achieve this in 1.6.0, I've
finally found this thread. :(
I look forward to having the stable version 1.6.1.
--
View this message in context:
http://openejb.979440.n4.nabble.com/tomee-jax-rs-and-logback-tp4667241p4669344.html
Sent from the OpenEJB User
The list is still messed up. I'm trying to follow up the emails, but they
are coming out of order.
[]s,
Thiago
On Fri, May 16, 2014 at 10:49 AM, Romain Manni-Bucau
wrote:
> Just checked and was not clear in my previous answer. Client side and
> server side have the same architecture more or le
Hi,
Async calls return back to the caller immediately. If we expect to get a
result back from an async call, we should use Future to hold it.
Maybe you can create something reproducible by cloning the async-method
example with a remote async call.
http://tomee.apache.org/examples-trunk/async-met
Hi Romain,
Well in the else block the DTO and the Entity will both be new so the
version will never be set.
Andy.
Thanks, I am aware of this basic rule but I got confused by reading several
times that if you use DTO remember to care for the version field. However I
guess this means I am supposed
Just checked and was not clear in my previous answer. Client side and
server side have the same architecture more or less. Both have a
thread pool. So bean.asyncCall() will do a
executorService.submit(remoteCall).
What can potentially be considered as a bug is the fact we don't
shutdown this execu
Hi
I don't get the question. Can you detail it please?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-15 11:53 GMT+02:00 James Green :
> It appears that TomEE does a
HI
if asynchronous call is like 'call this ejb -> send call in a thread
pool', if first step is not done and connection cut then it is
aborted.
Sounds normal.
It is async on server not on client.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http:/
Hi,
If that's the case, we have a bug. I have this sample application with a
"deleteUser" method:
https://github.com/tveronezi/faceid/blob/master/src/main/groovy/faceid/rest/Users.groovy
Last time checked, it was working. :) Can you confirm it for us?
[]s,
Thiago.
On Thu, May 15, 2014 at 5:53
@Andy: not the question I think
the point is mainly how do I keep version management when I use DTO in
the front. You must push version until your DTO and handle it
yourself.
That said you can just do the check this way:
if (entity.version != dto.version) throw new ItWillFailException();
instea
Oh... I think I see what you mean now.
You say that the server kills the async thread as soon as the caller thread
ends, right?
Can you create an example for that too?
[]s,
Thiago
On May 16, 2014 9:21 AM, "Thiago Veronezi" wrote:
> Hi,
>
> Async calls return back to the caller immediately. If
Part 3 has been posted:
http://blog.paralleluniverse.co/2014/05/15/modern-java-pt3
and David, after reading your mails I'm about this fired up about TomEE:
http://s27.postimg.org/xcq6wgx8j/Screen_Shot_2014_05_15_at_10_54_51_PM.png
On Wed, May 14, 2014 at 5:19 PM, David Blevins wrote:
> On May 1
There is something related to hashcode behing it so maybe a conflict
without another path.
No more idea while not seeing it from my eyes :(
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/
It appears that TomEE does accept HTTP DELETE operations by default.
Given the project is Tomcat + some components that expressly accept DELETE
(CXF) on resource URIs, should this situation be changed to prevent us
developers having to identify the problem, the research and try the
solutions ourse
25 matches
Mail list logo
