On Mon, Oct 6, 2014 at 6:58 PM, Romain Manni-Bucau
wrote:
> 2014-10-06 18:55 GMT+02:00 John D. Ament :
> > No, not at all.
> >
>
As far as I understand I can access @RequestScoped and @ApplicationScoped
beans when inside an @Asynchronous EJB method call. However only the
@ApplicationScoped bean
Hmm
How did you set the action? well a small sample (a hello world
webservice) showing this difference would be awesome to go ahead
otherwise we'll start to get 20 mails just to understand what we are
speaking about ;)
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.w
Oh I see what you are saying. You mean there may be a configuration to make
is so XCF will be compatible with the existing clients? That would be
wonderful.
The XCF wsdl looks like this
The Metro looks like this
http://server.synchronizer.compass.ciminc.com/SynchronizerService/connectionChe
2014-10-06 18:55 GMT+02:00 John D. Ament :
> No, not at all.
>
> The solution Romain gave you would likely work, but may fail in other
> containers as what's passed around is a proxy, not necessarily the real
> object.
>
well idea was to compute params before being async. If that's a
request scope
No, not at all.
The solution Romain gave you would likely work, but may fail in other
containers as what's passed around is a proxy, not necessarily the real
object.
On Mon, Oct 6, 2014 at 12:51 PM, Lars-Fredrik Smedberg
wrote:
> @John
>
> But isnt @RequestScoped and @ApplicationScoped allowed
@John
But isnt @RequestScoped and @ApplicationScoped allowed scopes when running
in an @Asynchronous EJB method?
On Mon, Oct 6, 2014 at 5:24 PM, John D. Ament
wrote:
> Hi,
>
> I would say no to #2. Thread != RequestScoped. If you want to start a
> request scope with the thread, DeltaSpike h
2014-10-06 18:38 GMT+02:00 benerridge :
> Maybe I need to re state the problem.
>
> We have thousands of clients in the wild that use ws client code generated
> from a Metro created WSDL(glassfish) and when the implementation on the
> server is changed to XCF (TomEE) they will no longer be capable
Maybe I need to re state the problem.
We have thousands of clients in the wild that use ws client code generated
from a Metro created WSDL(glassfish) and when the implementation on the
server is changed to XCF (TomEE) they will no longer be capable of
interacting with the server. That is not accep
if you can list all the issues you have we can maybe help you solving
them if that's a config issue
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-10-06 17:55 GMT+02:00 benerridge :
> It is not just the WSDL. The end
It is not just the WSDL. The end-points are defined differently in the WSDL
so clients generated from the Glassfish WSDL get exceptions when contacting
the web services deployed in TomEE.
Exception: "The given SOAPAction does not match an operation."
We cannot move forward with TomEE until we can
2014-10-06 17:24 GMT+02:00 John D. Ament :
> Hi,
>
> I would say no to #2. Thread != RequestScoped. If you want to start a
> request scope with the thread, DeltaSpike has a CDIControl module that can
> do this for you.
>
> John
>
> On Mon, Oct 6, 2014 at 11:08 AM, Lars-Fredrik Smedberg
> wrote:
Hi,
I would say no to #2. Thread != RequestScoped. If you want to start a
request scope with the thread, DeltaSpike has a CDIControl module that can
do this for you.
John
On Mon, Oct 6, 2014 at 11:08 AM, Lars-Fredrik Smedberg
wrote:
> When executing an EJB @Asynchronous method I know that va
When executing an EJB @Asynchronous method I know that valid CDI scopes are
request and application.
1. Since @ApplicationScoped beans are available I assume that its better to
inject those in the actual code being executed rather than passing them as
arguments to the @Asynchronous method, correct
if tht's only the wsdl you can just add a filter and return the existing one
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-10-06 15:16 GMT+02:00 benerridge :
> Currently the biggest stumbling block is the web servic
Currently the biggest stumbling block is the web services. The WSDL generated
from Glassfish using Metro is not compatible with the WSDL generated from
TomEE for the same webservices (annotated POJO's).
So clients we have out in the field based on the WSDL from Glassfish will no
longer work when
Hi
can you precise what you need from Metro/Glassfish:
- EJB integration
- Pojo integration only
- resource injections
- ...
ATM we don't have a dedicated integration so if you need
EJB/Injections etc it can not be working our of the box. That said
integration shouldn't be that hard since we hav
I would like to move a web application from Glassfish to TomEE. I ran into a
problem because TomEE uses xcf Jax-WS and Glassfish uses Metro
implementation. I have many WS clients that will not be anle to be converted
in the near term. I was wondering if it is possible to use Metro WS in TomEE
inste
OK,
I'll just wait until 1.7.2/4.7.2 snapshot repos is updated and I'll give it
another try.
br hw
--
View this message in context:
http://tomee-openejb.979440.n4.nabble.com/deltaspike-fullstack-example-tp4672086p4672145.html
Sent from the TomEE Users mailing list archive at Nabble.com.
can be an issue with TomEE/OpenEJB (see TOMEE-1381)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-10-05 21:00 GMT+02:00 hwaastad :
> Hi,
> well, thats what I do, but
it should yes
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-10-06 9:13 GMT+02:00 Lars-Fredrik Smedberg :
> @Romain
>
> Thanks is @EJB with CDI-interceptors working
@Romain
Thanks is @EJB with CDI-interceptors working for any App server that is
JEE6 compatible or is it a TomEE feature?
On Mon, Oct 6, 2014 at 9:02 AM, Romain Manni-Bucau
wrote:
> 2014-10-06 8:38 GMT+02:00 Lars-Fredrik Smedberg :
> > @Romain
> >
> > - Do I not need to use @Inject for EJB
2014-10-06 8:38 GMT+02:00 Lars-Fredrik Smedberg :
> @Romain
>
> - Do I not need to use @Inject for EJB if I need to use CDI Interceptors on
> the EJB?
no
> - When I use @Inject where can the EJB I try to inject be packaged? Same
> WAR, EJB-JAR inside same EAR, other WAR in same EAR, other EAR?
>
22 matches
Mail list logo
