Thanks a lot Scott for your answer. This is the result:
That looks like an error in the XML parser. You might try changing the
javax.xml.stream.XMLInputFactory property to
com.sun.xml.internal.stream.XMLInputFactoryImpl.
When I add
system-property
Hi there,
Not sure if it helps, but I have an application that exposes a SOAP
interface using CXF 2.1.9 and I just tested it to work under Resin 3.1.5
and it fails under Resin 4.0.7 with a weird error.
It's just a proof-of-concept application that I have, so I can't tell
how well the
Thanks for the Priority = normal :)
-Wesley
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
I still think that 29Mb/66jars is too much when you need only soap.
Axis 2 is also very heavy, axis 1.4 is 2Mb only :) ... bad choice
probably because too old.
Daniel López wrote:
Hi there,
Not sure if it helps, but I have an application that exposes a SOAP
interface using CXF 2.1.9 and
Riccardo Cohen wrote:
I still think that 29Mb/66jars is too much when you need only soap.
Axis 2 is also very heavy, axis 1.4 is 2Mb only :) ... bad choice
probably because too old.
In this case, though, it just looks like we need to find the right
classname for the XMLInputFactory,
Thanks, Scott. You'd think that an explicit command to stop would mean stop,
not stop and restart.
I want to use submit because I'm actually doing this from a menu bar status
item, and would rather avoid creating the file (so inelegant). Is that not
possible? I exec it from the program.
--
Jeff Schnitzer wrote:
I can't seem to get a message driven bean hooked up to a queue up in
Resin 4.0.8. It's been a problem since at least 4.0.6. The problem
is pretty straightforward:
web-app xmlns=http://caucho.com/ns/resin;
xmlns:ee=urn:java:ee
Rick Mann wrote:
Thanks, Scott. You'd think that an explicit command to stop would mean
stop, not stop and restart.
I want to use submit because I'm actually doing this from a menu bar status
item, and would rather avoid creating the file (so inelegant). Is that not
possible? I exec it
On Tue, Jul 20, 2010 at 12:21 PM, Scott Ferguson f...@caucho.com wrote:
Thanks. It's a timing issue in CanDI. The jms:FileQueue was added to a
lazy-init which wasn't being evaluated when the #{delivery} was
processed. The fix will be in the next snapshot.
Cool. If you get to a point where
On Jul 20, 2010, at 12:26:55, Scott Ferguson wrote:
Rick Mann wrote:
Thanks, Scott. You'd think that an explicit command to stop would mean
stop, not stop and restart.
I want to use submit because I'm actually doing this from a menu bar status
item, and would rather avoid creating the
By the way, I was able to work past the lazy-init issue (presumably)
by using this block instead:
cfg:MessageBeanConfig
cfg:classtest.DeliveryListener/cfg:class
cfg:destination#{delivery}/cfg:destination
/cfg:MessageBeanConfig
However, enqueueing a
Jeff Schnitzer wrote:
By the way, I was able to work past the lazy-init issue (presumably)
by using this block instead:
cfg:MessageBeanConfig
cfg:classtest.DeliveryListener/cfg:class
cfg:destination#{delivery}/cfg:destination
/cfg:MessageBeanConfig
Neither ee:Startup/ nor resin:Service/ has any observable effect.
There's definitely some sort of cpu loop; as soon as I enqueue one
entry, one core goes to 99% for the java process. Occasionally the
thread hops between cores.
* It happens with both jms:FileQueue and jms:MemoryQueue.
* There
Jeff Schnitzer wrote:
Neither ee:Startup/ nor resin:Service/ has any observable effect.
There's definitely some sort of cpu loop; as soon as I enqueue one
entry, one core goes to 99% for the java process. Occasionally the
thread hops between cores.
Thanks. The loop is unrelated to EJB or
It works! Just got this working against trunk:
jms:JmsConnectionFactory/
jms:MemoryQueue
ee:Nameddelivery/ee:Named
/jms:MemoryQueue
ejb-message-bean class=test.DeliveryListener
15 matches
Mail list logo
