I'm not really familiar with NetBeans.
Are you using the GWT Development Mode for testing?
On 2010-01-18, at 1:53 PM, Kevin Jordan wrote:
Yeah, that's the only stuff that comes out during the compile
phase. Not
sure if I have something misconfigured in my logging, but that's the only
places that print out.
-----Original Message-----
From: Mike Brock [mailto:cbrock@redhat.com]
Sent: Monday, January 18, 2010 10:45 AM
To: Kevin Jordan
Cc: 'Thomas SEGISMONT'; errai-users(a)lists.jboss.org
Subject: Re: [errai-users] Trouble sending messages
This is for the compile-phase stuff. If you're running in hosted mode, you
need to look in the GWT Development Mode logger.
On 2010-01-18, at 11:43 AM, Kevin Jordan wrote:
> Is there any logging I have to set up for a particular class or
> package or any configuration I have to do for that? Normally, even
> when it works, the only output I see from Errai while compiling is:
> 0 [main] INFO Configuration - configuration scan targets
> 0 [main] INFO Configuration - ->
>
C:\Users\kjordan\Documents\NetBeansProjects\Desktop\lib\errai-persistence-1.
> 0-SNAPSHOT.jar
> 0 [main] INFO Configuration - ->
> C:\Users\kjordan\Documents\NetBeansProjects\Desktop\src\java
> 0 [main] INFO Configuration - ->
> C:\Users\kjordan\Documents\NetBeansProjects\Desktop\build\web\WEB-INF\
> classe
> s
> 63 [main] INFO Configuration - caching context
> 'C:\Users\kjordan\Documents\NetBeansProjects\Desktop\lib\errai-persist
> ence-1
> .0-SNAPSHOT.jar:*'
> 188 [main] INFO Configuration - caching context
> 'C:\Users\kjordan\Documents\NetBeansProjects\Desktop\build\web\WEB-INF
> \class
> es'
>
> And I'm not even really using persistence (i.e. it's not inherited in
> my .gwt.xml, but somehow it's getting run anyways either via ErraiBus
> or ErraiCommons).
> -----Original Message-----
> From: Mike Brock [mailto:cbrock@redhat.com]
> Sent: Monday, January 18, 2010 10:39 AM
> To: Kevin Jordan
> Cc: 'Thomas SEGISMONT'; errai-users(a)lists.jboss.org
> Subject: Re: [errai-users] Trouble sending messages
>
> This is an interesting theory. You should be able to determine
> whether the stub is generated or not since at compile-time the Errai
> generators show log output for each stub.
>
> You should see a log output that says: "Generated
> marshaller/demarshaller
> for: <classname>" for each entity you've annotated.
>
> On 2010-01-18, at 11:32 AM, Kevin Jordan wrote:
>
>> Not sure what you mean by that, but I'm using Netbeans and my domain
>> POJOs
> are in a separate project which gets included by my web project. The
> projects compile file and I've used my domain POJOs via SOAFace's
> UniversalClient and regular GWT-RPC before without issues. And they
> get put across the wire with Errai, it's just when the class is in a
> separate project that there seems to be a problem and my callback
> isn't called. So I'm wondering if it's an issue with the stub getting
generated or something.
>
>>
>> -----Original Message-----
>> From: Thomas SEGISMONT [mailto:tsegismont@gmail.com]
>> Sent: Monday, January 18, 2010 10:12 AM
>> To: Kevin Jordan
>> Cc: Mike Brock; errai-users(a)lists.jboss.org
>> Subject: Re: [errai-users] Trouble sending messages
>>
>> Have you tried to include your project/jar source code in your launch
> configuration ?
>>
>> It sounds more like a GWT configuration problem than an Errai one.
>>
>> If you're using Maven to build your project, you can read this :
>>
http://mojo.codehaus.org/gwt-maven-plugin/user-guide/multiproject.htm
>> l
>>
>> Thomas
>>
>> On Mon, 18 Jan 2010 09:50:40 -0600, "Kevin Jordan"
>> <kevin.jordan(a)xteconline.com> wrote:
>>> I think I've found out one problem. Somehow Errai has trouble if
>>> your
>> POJO
>>> is in an external jar, or in my case another Netbeans project. GWT
>>> will compile my project just fine, but it at least seems to be that
>>> once I go
>> to
>>> another project/jar for my POJO it fails to get to my callback and
>>> does
>> the
>>> behavior I've previously described.
>>>
>>>
>>>
>>> From: Mike Brock [mailto:cbrock@redhat.com]
>>> Sent: Friday, January 15, 2010 4:20 PM
>>> To: Kevin Jordan
>>> Cc: errai-users(a)lists.jboss.org
>>> Subject: Re: [errai-users] Trouble sending messages
>>>
>>>
>>>
>>> Yes, that will work, of course.
>>>
>>>
>>>
>>> On 2010-01-15, at 4:59 PM, Kevin Jordan wrote:
>>>
>>>
>>>
>>>
>>>
>>> I haven't yet. But I'll try it and let you know if it works.
>>>
>>>
>>>
>>> So the default constructor provided by the JVM if you don't specify
>>> one won't work?
>>>
>>>
>>>
>>> From: Mike Brock [mailto:cbrock@redhat.com]
>>> Sent: Friday, January 15, 2010 3:55 PM
>>> To: Kevin Jordan
>>> Cc: errai-users(a)lists.jboss.org
>>> Subject: Re: [errai-users] Trouble sending messages
>>>
>>>
>>>
>>> Have you updated to trunk -- I think that will fix the
>>> InstantiationException? Any serializable class *must* have a
>>> default constructor.
>>>
>>>
>>>
>>> On 2010-01-15, at 4:48 PM, Kevin Jordan wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>> Well, I think I've figured it out on my callback problems. I went
>>> back
>> to
>>> just passing a string back and forth and that worked. I then made a
>>> simpler POJO to pass back and forth with just implementing
>>> Serializable which didn't work (no callback call). I then added the
>>> annotation that I just saw in the docs and that didn't work (no
>>> callback call). I then removed
>> Serializable
>>> and the callback gets called, but it gets an error when it tries to
>>> get
>> the
>>> POJO out of the message.
>>>
>>>
>>>
>>> Is there anything extra I need to do for POJOs?
>>>
>>>
>>>
>>> From: errai-users-bounces(a)lists.jboss.org
>>> [mailto:errai-users-bounces@lists.jboss.org] On Behalf Of Kevin
>>> Jordan
>>> Sent: Thursday, January 14, 2010 4:21 PM
>>> To: 'Mike Brock'
>>> Cc: errai-users(a)lists.jboss.org
>>> Subject: Re: [errai-users] Trouble sending messages
>>>
>>>
>>>
>>> Whenever I do that, I seem to get:
>>>
>>> java.lang.InstantiationException:
>>> org.jboss.errai.bus.server.servlet.DefaultBlockingServlet
>>>
>>> at java.lang.Class.newInstance0(Class.java:340)
>>>
>>> at java.lang.Class.newInstance(Class.java:308)
>>>
>>> at
>>> org.apache.catalina.core.StandardWrapper.loadServlet(Unknown
>>> Source)
>>>
>>> at org.apache.catalina.core.StandardWrapper.load(Unknown
>>> Source)
>>>
>>> at
>>> org.apache.catalina.core.StandardContext.loadOnStartup(Unknown
>>> Source)
>>>
>>> at org.apache.catalina.core.StandardContext.start(Unknown
>>> Source)
>>>
>>> at
>> org.apache.catalina.core.ContainerBase.addChildInternal(Unknown
>>> Source)
>>>
>>> at org.apache.catalina.core.ContainerBase.addChild(Unknown
>> Source)
>>>
>>> at org.apache.catalina.core.StandardHost.addChild(Unknown
>>> Source)
>>>
>>> at
>> org.apache.catalina.startup.HostConfig.deployDescriptor(Unknown
>>> Source)
>>>
>>> at
>> org.apache.catalina.startup.HostConfig.deployDescriptors(Unknown
>>> Source)
>>>
>>> at org.apache.catalina.startup.HostConfig.deployApps(Unknown
>>> Source)
>>>
>>> at org.apache.catalina.startup.HostConfig.check(Unknown
>>> Source)
>>>
>>> at
>>> org.apache.catalina.startup.HostConfig.lifecycleEvent(Unknown
>>> Source)
>>>
>>> at
>>> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Unknown
>>> Source)
>>>
>>> at
>> org.apache.catalina.core.ContainerBase.backgroundProcess(Unknown
>>> Source)
>>>
>>> at
>>>
>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.p
>> r
>> ocessC
>>> hildren(Unknown Source)
>>>
>>> at
>>>
>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.p
>> r
>> ocessC
>>> hildren(Unknown Source)
>>>
>>> at
>>>
>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.r
>> u
>> n(Unkn
>>> own Source)
>>>
>>> at java.lang.Thread.run(Thread.java:619)
>>>
>>>
>>>
>>> Even in a new project I've created to see if anything is interfering
>>> with Errai somehow. Trying TomcatCometServlet or ErraiAutoServlet
>>> also yields the same results as before in both cases. Using the
>>> listener/Guice
>> filter
>>> works. I've also gotten it so a callback works in my new minimal
>> project.
>>> So now I'm wondering if something else is interfering with it. I've
>>> got Spring Security protecting pretty much everything, although I
>>> think I've tried taking that out before and had the same effect.
>>> I've also got GXT
>>> (
http://www.extjs.com/products/gxt/) in there. Along with Mule and
>>> SOAFaces, although SOAFaces can probably go away since I'll be
>>> communicating to Mule via Errai when that works so I can have better
>>> asynchronous communication and also push communication. I suppose
>>> what I'll try first is ripping out GXT since that's probably the
>>> most likely culprit in my mind.
>>>
>>>
>>>
>>> From: Mike Brock [mailto:cbrock@redhat.com]
>>> Sent: Thursday, January 14, 2010 12:12 PM
>>> To: Kevin Jordan
>>> Cc: errai-users(a)lists.jboss.org
>>> Subject: Re: [errai-users] Trouble sending messages
>>>
>>>
>>>
>>> We will actually be removing the Guice filter as it's created
>>> problems
>> for
>>> deploying on some appservers. We're falling back on directly declaring
>>> the
>>> servlet. So you might want to switch to directly declaring the
>>> DefaultBlockingServlet like so:
>>>
>>>
>>>
>>> <servlet>
>>>
>>> <servlet-name>ErraiServlet</servlet-name>
>>>
>>>
>>>
>> <servlet-class>org.jboss.errai.bus.server.servlet.DefaultBlockingServ
>> l
>> et</se
>>> rvlet-class>
>>>
>>> <load-on-startup>1</load-on-startup>
>>>
>>> </servlet>
>>>
>>>
>>>
>>> <servlet-mapping>
>>>
>>> <servlet-name>ErraiServlet</servlet-name>
>>>
>>> <url-pattern>*.erraiBus</url-pattern>
>>>
>>> </servlet-mapping>
>>>
>>>
>>>
>>> .
>>>
>>>
>>>
>>> On 2010-01-14, at 12:45 PM, Kevin Jordan wrote:
>>>
>>>
>>>
>>> Yes. It's still working the way it was before where I have to
>>> submit
>> more
>>> than once and the response comes back on the POST but the callback
>> doesn't
>>> get called.
>>>
>>>
>>>
>>> From: Mike Brock [mailto:cbrock@redhat.com]
>>> Sent: Thursday, January 14, 2010 11:44 AM
>>> To: Kevin Jordan
>>> Cc: errai-users(a)lists.jboss.org
>>> Subject: Re: [errai-users] Trouble sending messages
>>>
>>>
>>>
>>> Are you still losing messages?
>>>
>>>
>>>
>>> On 2010-01-14, at 12:31 PM, Kevin Jordan wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Switching it back to the listener config seems to make it work again
>>> through the DefaultBlockingServlet.
>>>
>>>
>>>
>>> From: Kevin Jordan [mailto:kevin.jordan@xteconline.com]
>>> Sent: Thursday, January 14, 2010 11:22 AM
>>> To: 'Mike Brock'
>>> Cc: 'errai-users(a)lists.jboss.org'
>>> Subject: RE: [errai-users] Trouble sending messages
>>>
>>>
>>>
>>> Yeah, I'm using the NIO connector. And actually if I configure the
>>> TomcatCometServlet manually I get the same error again. I know that
>>> used to happen when I was accessing it through my AJP connected
>>> Apache instance, but now I'm accessing it directly through port 8443
>>> on Tomcat.
>>>
>>>
>>>
>>> From: Mike Brock [mailto:cbrock@redhat.com]
>>> Sent: Thursday, January 14, 2010 10:55 AM
>>> To: Kevin Jordan
>>> Cc: errai-users(a)lists.jboss.org
>>> Subject: Re: [errai-users] Trouble sending messages
>>>
>>>
>>>
>>> Are you using the NIO connector in Tomcat? Errai by default will
>>> try to use Tomcat's AIO system, which requires that the NIO or APR
>>> connecter be
>> used.
>>>
>>>
>>>
>>> On 2010-01-14, at 11:47 AM, Kevin Jordan wrote:
>>>
>>>
>>>
>>> I tried the AutoServlet and it seems to pick the TomcatCometServlet
>>> which makes it spin over and over on this message every time it
>>> tries to access
>>> it:
>>>
>>>
>> *********************************************************************
>> *
>> ******
>>> *********************
>>>
>>> ** PROBLEM!
>>>
>>> ** It appears something has been incorrectly configured. In order to
>>> use ErraiBus
>>>
>>> ** on Tomcat, you must ensure that you are using the NIO or APR
>> connector.
>>> Also
>>>
>>> ** make sure that you have added these lines to your WEB-INF/web.xml
>> file:
>>>
>>> ** ---
>>>
>>> ** <servlet>
>>>
>>> ** <servlet-name>TomcatErraiServlet</servlet-name>
>>>
>>> **
>>>
>> <servlet-class>org.jboss.errai.bus.server.servlet.TomcatCometServlet<
>> /
>> servle
>>> t-class>
>>>
>>> ** <load-on-startup>1</load-on-startup>
>>>
>>> ** </servlet>
>>>
>>> **
>>>
>>> ** <servlet-mapping>
>>>
>>> ** <servlet-name>TomcatErraiServlet</servlet-name>
>>>
>>> ** <url-pattern>*.erraiBus</url-pattern>
>>>
>>> ** </servlet-mapping>
>>>
>>> ** ---
>>>
>>> ** If you have the following lines in your WEB-INF/web.xml, you must
>>> comment or remove them:
>>>
>>> ** ---
>>>
>>> ** <listener>
>>>
>>> **
>>>
>> <listener-class>org.jboss.errai.bus.server.ErraiServletConfig</listen
>> e
>> r-clas
>>> s>
>>>
>>> ** </listener>
>>>
>>>
>> *********************************************************************
>> *
>> ******
>>> *********************
>>>
>>>
>>>
>>> From: Mike Brock [mailto:cbrock@redhat.com]
>>> Sent: Thursday, January 14, 2010 10:06 AM
>>> To: Kevin Jordan
>>> Cc: errai-users(a)lists.jboss.org
>>> Subject: Re: [errai-users] Trouble sending messages
>>>
>>>
>>>
>>> By the way, if you want, we're on IRC on
irc.freenode.net in channel
>> #errai
>>> -- I'm "cbrock" on there if you want help troubleshooting
directly.
>>>
>>>
>>>
>>> On 2010-01-14, at 9:44 AM, Kevin Jordan wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> It happens in all browsers, Firefox 3.5, Firefox 3.6, Chrome, and IE
>>> on Windows 7. I'm using Tomcat.
>>>
>>>
>>>
>>> I'll try the AutoServlet to see if it makes a difference.
>>>
>>>
>>>
>>> From: Mike Brock [mailto:cbrock@redhat.com]
>>> Sent: Wednesday, January 13, 2010 8:35 PM
>>> To: Kevin Jordan
>>> Cc: errai-users(a)lists.jboss.org
>>> Subject: Re: [errai-users] Trouble sending messages
>>>
>>>
>>>
>>> If you update to the latest version of trunk, simply get rid of the
>>> listener and replace your web.xml config with this:
>>>
>>>
>>>
>>> <servlet>
>>>
>>> <servlet-name>ErraiAutoServlet</servlet-name>
>>>
>>>
>>>
>> <servlet-class>org.jboss.errai.bus.server.servlet.ErraiAutoServlet</s
>> e
>> rvlet-
>>> class>
>>>
>>> <load-on-startup>1</load-on-startup>
>>>
>>> </servlet>
>>>
>>>
>>>
>>> <servlet-mapping>
>>>
>>> <servlet-name>ErraiAutoServlet</servlet-name>
>>>
>>> <url-pattern>*.erraiBus</url-pattern>
>>>
>>> </servlet-mapping>
>>>
>>>
>>>
>>> This problem you're having is curious, though. We haven't seen it
>>> in our internal testing. Can you tell me what browser, what
>>> appserver, and what OS you're on?
>>>
>>>
>>>
>>> On 2010-01-13, at 5:08 PM, Kevin Jordan wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> I'm using the following on the client side:
>>>
>>> bus.subscribe("ItemFound", new MessageCallback() {
>>>
>>>
>>>
>>> @Override
>>>
>>> public void callback(Message message) {
>>>
>>> //throw new
>>> UnsupportedOperationException("Not supported yet.");
>>>
>>> MessageBox.alert("Success", "In
>> Callback",
>>> null);
>>>
>>> /*Map<String,Object> parts =
>>> message.getParts();
>>>
>>> Set<String> keys = parts.keySet();
>>>
>>> for (String key : keys) {
>>>
>>> MessageBox.alert("Key",key,null);
>>>
>>> }*/
>>>
>>> //Item item = message.get(Item.class,
>>> "Item");
>>>
>>> //MessageBox.alert("Return",
>>> item.getSerialNumber().toString(), null);
>>>
>>> }
>>>
>>> });
>>>
>>>
>>>
>> MessageBuilder.createMessage().toSubject("Items").signalling().with(M
>> e
>> ssageP
>>> arts.ReplyTo, "ItemFound").with("SerialNumber",
>>> serialInput.getValue().toString()).errorsHandledBy(new
>>> ErrorCallback() {
>>>
>>>
>>>
>>> @Override
>>>
>>> public boolean error(Message message,
>> Throwable
>>> throwable) {
>>>
>>> //throw new
>>> UnsupportedOperationException("Not supported yet.");
>>>
>>> MessageBox.alert("Error",
>>> throwable.getMessage(), null);
>>>
>>> return true;
>>>
>>> }
>>>
>>> }).sendNowWith(bus);
>>>
>>>
>>>
>>> Which sends:
>>>
>>>
{"ToSubject":"Items","ReplyTo":"ItemFound","SerialNumber":"1201489"}
>>>
>>>
>>>
>>> Although I've now noticed that it takes 2 tries to get it to send
>>> that
>> and
>>> a
>>> 3rd one to get the response back for the first one.
>>>
>>>
>>>
>>> Server portion looks like:
>>>
>>> @Service("Items")
>>>
>>> public class Items implements MessageCallback {
>>>
>>> private MessageBus bus;
>>>
>>>
>>>
>>> @Inject
>>>
>>> public Items(MessageBus bus) {
>>>
>>> this.bus = bus;
>>>
>>> System.out.println("Got a bus...");
>>>
>>> }
>>>
>>>
>>>
>>> @Override
>>>
>>> public void callback(Message message) {
>>>
>>> //throw new UnsupportedOperationException("Not supported
>> yet.");
>>>
>>> System.out.println("Incoming message...");
>>>
>>> String serialNum = message.get(String.class,
>>> "SerialNumber");
>>>
>>> System.out.println(serialNum);
>>>
>>> Item item = new Item();
>>>
>>> item.setSerialNumber(Long.parseLong(serialNum));
>>>
>>>
>>>
>> MessageBuilder.createConversation(message).subjectProvided().signalli
>> n
>> g().wi
>>> th("Item", item).errorsHandledBy(new ErrorCallback() {
>>>
>>>
>>>
>>> @Override
>>>
>>> public boolean error(Message message, Throwable
>> throwable)
>>> {
>>>
>>> //throw new UnsupportedOperationException("Not
>>> supported yet.");
>>>
>>> throwable.printStackTrace();
>>>
>>> return true;
>>>
>>> }
>>>
>>> }).sendNowWith(bus);
>>>
>>> }
>>>
>>> }
>>>
>>>
>>>
>>> Response on the second POST is:
>>>
>>>
>>
[{"ItemFound":{"Item":{__EncodedType:'com.xteconline.system.Item',id:
>> n
>> ull,se
>>>
>>
>
rialNumber:1201489,part:null,storageLocation:null,storageUnit:null,customer:
>>>
>> null,oemSerial:null,manufacturer:null,status:null,itemInfos:null},"To
>> S
>> ubject
>>> ":"ItemFound"}}]
>>>
>>>
>>>
>>> All others seem to get:
>>>
>>> [{"HeartBeat":null}]
>>>
>>>
>>>
>>> And on the first time I try to submit, it still seems to be kind of
>> setting
>>> up stuff since it sends:
>>>
>>>
>>
{"CommandType":"RemoteSubscribe","ToSubject":"ServerBus","Subject":"S
>> e
>> rverBu
>>>
>>
>
s","PriorityProcessing":"1"}||{"CommandType":"RemoteSubscribe","ToSubject":"
>>>
>>
ServerBus","Subject":"AuthorizationService","PriorityProcessing":"1"}
>> |
>> |{"Com
>>>
>>
mandType":"RemoteSubscribe","ToSubject":"ServerBus","Subject":"Client
>> N
>> egotia
>>>
>>
tionService","PriorityProcessing":"1"}||{"CommandType":"RemoteSubscri
>> b
>> e","To
>>>
>>
Subject":"ServerBus","Subject":"ServerEchoService","PriorityProcessin
>> g
>> ":"1"}
>>>
>>
||{"CommandType":"RemoteSubscribe","ToSubject":"ServerBus","Subject":"
>> ||Cl
>> ||ient
>>>
>>
Bus"}||{"CommandType":"RemoteSubscribe","ToSubject":"ServerBus","Subj
>> e
>> ct":"C
>>>
>>
>
lientBusErrors"}||{"CommandType":"RemoteSubscribe","ToSubject":"ServerBus","
>>>
>>
Subject":"Items"}||{"CommandType":"RemoteSubscribe","ToSubject":"Serv
>> e
>> rBus",
>>>
>>
"Subject":"ServerBus"}||{"CommandType":"RemoteSubscribe","ToSubject":"
>> Server
>>>
>>
Bus","Subject":"AuthorizationService"}||{"CommandType":"RemoteSubscri
>> b
>> e","To
>>>
>>
>
Subject":"ServerBus","Subject":"ClientNegotiationService"}||{"CommandType":"
>>>
RemoteSubscribe","ToSubject":"ServerBus","Subject":"ServerEchoService"
>>> }
>>>
>>>
>>>
>>> And
>>>
>>>
>>>
>>>
>>
{"CommandType":"RemoteSubscribe","ToSubject":"ServerBus","Subject":"I
>> t
>> emFoun
>>> d","PriorityProcessing":"1"}
>>>
>>>
>>>
>>> But doesn't send my stuff until I submit again.
>>>
>>>
>>>
>>> And about the only other relevant thing I can think of for Errai is
>>> the servlet config:
>>>
>>> <listener>
>>>
>>>
>>>
>> <listener-class>org.jboss.errai.bus.server.ErraiServletConfig</listen
>> e
>> r-clas
>>> s>
>>>
>>> </listener>
>>>
>>>
>>>
>>> Which I believe sets up the DefaultBlockingServlet.
>>>
>>>
>>>
>>> From: Mike Brock [mailto:cbrock@redhat.com]
>>> Sent: Tuesday, January 12, 2010 11:48 AM
>>> To: Kevin Jordan
>>> Cc: errai-users(a)lists.jboss.org
>>> Subject: Re: [errai-users] Trouble sending messages
>>>
>>>
>>>
>>> We have a fairly significant application that makes extensive use
>>> of
>> this
>>> type of paradigm and we haven't ever experienced any dropped messages.
>> Can
>>> you provide me some examples of your code so we can troubleshoot
>>> what's going on?
>>>
>>>
>>>
>>> On 2010-01-12, at 11:38 AM, Kevin Jordan wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> The MessageParts.ReplyTo was what I was missing in there. However,
>>> my callback doesn't seem to be called. I get something back when my
>>> request is POSTed, but it never seems to call my callback. They do
>>> seem to work sometimes though. I had accidentally named my callback
>>> subject and the server subject the same and when I created a message
>>> to that subject,
>> both
>>> the client callback and the server callback were called correctly.
>>>
>>>
>>>
>>> From: Mike Brock [mailto:cbrock@redhat.com]
>>> Sent: Tuesday, January 12, 2010 9:07 AM
>>> To: Kevin Jordan
>>> Cc: errai-users(a)lists.jboss.org
>>> Subject: Re: [errai-users] Trouble sending messages
>>>
>>>
>>>
>>> The sender needs to create a listening service that can be replied to.
>> The
>>> best way to do this is like so:
>>>
>>>
>>>
>>>
>>>
>>> //client-side code
>>>
>>> bus.subscribe("MyResponseSvc",
>>>
>>> new MessageCallback() {
>>>
>>> public void callback(Message msg) {
>>>
>>> ...
>>>
>>> }
>>>
>>> }
>>>
>>> );
>>>
>>>
>>>
>>>
>> MessageBuilder.createMessage().toSubject("ConversationalService").sig
>> n
>> alling
>>> ()
>>>
>>> .with(MessageParts.ReplyTo, "MyResponseSvc")
>>>
>>> .with("SomeMessagePart", "Foo")
>>>
>>> .noErrorHandling()
>>>
>>> .sendNowWith(bus);
>>>
>>>
>>>
>>> ...
>>>
>>> //server-side code
>>>
>>>
>>>
>>> MessageBuilder.createConversation(message)
>>>
>>> .subjectProvided().signalling()
>>>
>>> .with("MyResponseData", "Bar")
>>>
>>> .noErrorHandling()
>>>
>>> .sendNowWith(bus);
>>>
>>>
>>>
>>> ...
>>>
>>>
>>>
>>> Note: we may make this more straight forward in the future, such as
>>> with the RPC API.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 2010-01-11, at 5:14 PM, Kevin Jordan wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> I won't be able to use the Swing monitor on the server I'm deploying
>>> to since it has no interface. However, I did start enabling logging
>>> in various places and it does seem that my services weren't getting
>>> started. I was lacking an ErraiApp.properties which I guess is used
>>> as the root for
>> where
>>> it should start looking for services. After adding that, they
>>> started
>> and
>>> stuff started to go through. Does the client keep a record of
>>> services
>> or
>>> something then? Why wouldn't it try to contact the service and then
>>> fail that it couldn't find it?
>>>
>>>
>>>
>>> Also, looking at the revised Message API, how do you listen for the
>>> reply in a conversation? Do I need to create a separate listener?
>>> Before you
>> could
>>> specify a MessageCallback to get the response in the conversation,
>>> but I can't find anywhere in the call chain to do that and it's not
>>> covered in the SVN book.
>>>
>>>
>>>
>>> From: Mike Brock [mailto:cbrock@redhat.com]
>>> Sent: Monday, January 11, 2010 3:16 PM
>>> To: Kevin Jordan
>>> Cc: errai-users(a)lists.jboss.org
>>> Subject: Re: [errai-users] Trouble sending messages
>>>
>>>
>>>
>>> Kevin,
>>>
>>>
>>>
>>> I'm not sure how you're launching your app, but can you provide this
>>> command line option which will bring up the bus monitor, and at
>>> least tell me if you've probably deployed your services:
>>> -Derrai.bus.showmonitor=true
>>>
>>>
>>>
>>> Also, can you email me the log output from when your startup the
>>> application?
>>>
>>>
>>>
>>> On 2010-01-11, at 3:35 PM, Kevin Jordan wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Changing to a createCall and making a @Endpoint annotated method on
>>> the server seems to make it send something again:
>>>
>>>
>>
{"CommandType":"RemoteSubscribe","ToSubject":"ServerBus","Subject":"I
>> t
>> ems.ge
>>> tItem:RespondTo:1","PriorityProcessing":"1"}
>>>
>>>
>>>
>>> With a response of:
>>>
>>> [{"HeartBeat":null}]
>>>
>>>
>>>
>>> However, I still so nowhere where it passes the parameter I give it
with:
>>>
>>>
MessageBuilder.createCall().call("Items").endpoint("getItem",
>>> serialInput.getValue()).respondTo(Item.class, new
>>> RemoteCallback<Item>()
>> {
>>>
>>>
>>>
>>> @Override
>>>
>>> public void callback(Item response) {
>>>
>>> //throw new
>>> UnsupportedOperationException("Not supported yet.");
>>>
>>>
>>> MessageBox.alert("Return",item.getSerialNumber().toString(),null);
>>>
>>> }
>>>
>>>
>>>
>>> }).noErrorHandling().sendNowWith(bus);
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> From: errai-users-bounces(a)lists.jboss.org
>>> [mailto:errai-users-bounces@lists.jboss.org] On Behalf Of Kevin
>>> Jordan
>>> Sent: Monday, January 11, 2010 1:46 PM
>>> To: 'Mike Brock'
>>> Cc: errai-users(a)lists.jboss.org
>>> Subject: Re: [errai-users] Trouble sending messages
>>>
>>>
>>>
>>> Made the changes specified in the userguide, but now it doesn't send
>>> anything. I'm using the following:
>>>
>>>
>>
MessageBuilder.createMessage().toSubject("Items").signalling().with("
>> S
>> erialN
>>> umber", "Test").noErrorHandling().sendNowWith(bus);
>>>
>>>
>>>
>>> It still seems to be set up just fine since the in.erraiBus servlet
>>> is created and the client long polls it, but the code above doesn't
>>> seem to send anything. I'm using the following way to make it for
>>> the
>>> DefaultBlockingServlet:
>>>
>>> <listener>
>>>
>>>
>>>
>> <listener-class>org.jboss.errai.bus.server.ErraiServletConfig</listen
>> e
>> r-clas
>>> s>
>>>
>>> </listener>
>>>
>>>
>>>
>>> Should I be using that? I figure it shouldn't affect the client any
>> though
>>> unless the servlet is incorrectly set up as a consequence, which it
>> doesn't
>>> seem to be since they communicate just fine for the initial setup.
>>> What should I look at to see why it's not sending?
>>>
>>>
>>>
>>> From: Mike Brock [mailto:cbrock@redhat.com]
>>> Sent: Monday, January 11, 2010 12:43 PM
>>> To: Kevin Jordan
>>> Cc: 'Heiko Braun'; errai-users(a)lists.jboss.org
>>> Subject: Re: [errai-users] Trouble sending messages
>>>
>>>
>>>
>>> You should be aware we have made changes and are retiring the use of
>>> the CommandMessage API. Be sure to read the documentation in the
>>> userguide/src/main/docbook/en/master.xml file. You can use: mvn
>>> jdocbook:generate to create an HTML file from the userguide/ directory.
>>>
>>>
>>>
>>> On 2010-01-11, at 1:09 PM, Kevin Jordan wrote:
>>>
>>>
>>>
>>> From: Mike Brock [mailto:cbrock@redhat.com]
>>> Sent: Friday, January 08, 2010 2:56 PM
>>> To: Kevin Jordan
>>> Cc: errai-users(a)lists.jboss.org
>>> Subject: Re: [errai-users] Trouble sending messages
>>>
>>>
>>>
>>> I will check into this. We're still working on getting the AIO
>>> stuff
>>> sorted>Monday, January 11, 2010 8:59 AM
>>> To: Kevin Jordan
>>> Cc: errai-users(a)lists.jboss.org
>>> Subject: Re: [errai-users] Trouble sending messages
>>>
>>>
>>>
>>>
>>>
>>> Hi Kevin, the compilation problems should be fixed already.
>>>
>>>
>>>
>>>
>>>
>>> On Jan 11, 2010, at 3:36 PM, Kevin Jordan wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Yes, I am using trunk. Is there a more stable branch/version I
>>> should be using? I had updated again hoping it was just something
>>> with the time I checked out and then ran into the problems Heiko
>>> Braun ran into compiling it.
>>>
>>>
>>>
>>> From: Mike Brock [mailto:cbrock@redhat.com]
>>> Sent: Friday, January 08, 2010 8:52 PM
>>> To: Kevin Jordan
>>> Cc: errai-users(a)lists.jboss.org
>>> Subject: Re: [errai-users] Trouble sending messages
>>>
>>>
>>>
>>> What version of ErraiBus are you using? Are you getting it from trunk?
>>>
>>>
>>>
>>> On 2010-01-08, at 5:37 PM, Kevin Jordan wrote:
>>>
>>>
>>>
>>> DefaultBlockingServlet seems to have the same effect.
>>>
>>>
>>>
>>> From: Mike Brock [mailto:cbrock@redhat.com]
>>> Sent: Friday, January 08, 2010 2:56 PM
>>> To: Kevin Jordan
>>> Cc: errai-users(a)lists.jboss.org
>>> Subject: Re: [errai-users] Trouble sending messages
>>>
>>>
>>>
>>> I will check into this. We're still working on getting the AIO
>>> stuff sorted, and I wouldn't consider the Tomcat or JBoss adapters
>>> to be production ready. You're best to use the
>>> DefaultBlockingServlet -- which will provide adequate performance
>>> for development while we get the AIO adapters squared away over the next
few days.
>>>
>>>
>>>
>>> On 2010-01-08, at 2:34 PM, Kevin Jordan wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> I'm having trouble getting a message to go through using ErraiBus.
>>> I'm using this on the client side:
>>>
>>> CommandMessage msg = (CommandMessage)
>>>
CommandMessage.create().toSubject("Items").set("SerialNumber",
>>> serialInput.getValue());
>>>
>>> bus.conversationWith(msg, new MessageCallback() {
>>>
>>>
>>>
>>> @Override
>>>
>>> public void callback(Message message) {
>>>
>>> //throw new
>>> UnsupportedOperationException("Not supported yet.");
>>>
>>> Item item = message.get(Item.class,
>>> "Item");
>>>
>>> MessageBox.alert("Errai",
>>> item.getSerialNumber().toString(), null);
>>>
>>> }
>>>
>>> });
>>>
>>>
>>>
>>> With this on the server side:
>>>
>>> @Service("Items")
>>>
>>> public class Items implements MessageCallback {
>>>
>>> private MessageBus bus;
>>>
>>>
>>>
>>> @Inject
>>>
>>> public Items(MessageBus bus) {
>>>
>>> this.bus = bus;
>>>
>>> System.out.println("Got a bus...");
>>>
>>> }
>>>
>>>
>>>
>>> @Override
>>>
>>> public void callback(Message message) {
>>>
>>> //throw new UnsupportedOperationException("Not supported
>> yet.");
>>>
>>> System.out.println("Incoming message...");
>>>
>>> Long serialNum = message.get(Long.class, "SerialNumber");
>>>
>>> System.out.println(serialNum);
>>>
>>> Item item = new Item();
>>>
>>> item.setSerialNumber(serialNum);
>>>
>>>
>>>
ConversationMessage.create(message).set("Item",item).sendNowWith(bus
>>> )
>>> ;
>>>
>>> }
>>>
>>>
>>>
>>> }
>>>
>>>
>>>
>>> However, all it seems to send is:
>>>
>>>
>>
{"CommandType":"RemoteSubscribe","ToSubject":"ServerBus","Subject":"t
>> e
>> mp:Con
>>> versation:2","PriorityProcessing":"1"}
>>>
>>>
>>>
>>> I don't see where it actually sends my body or the subject that I
>>> fill
>> out
>>> in my message. Nothing also gets to the Service class. Am I doing
>>> something wrong? I have Tomcat running NIO and everything else
>>> seems set up correctly. It will keep a GET connection open and do
>>> the POST of the
>> JSON
>>> above, but nowhere does it seem to send what I want it to. I also
>>> seem
>> to
>>> be getting these occasionally, usually on some of the first requests
>>> to
>>> in.erraiBus:
>>>
>>> java.lang.NullPointerException
>>>
>>> at
>>>
>> org.jboss.errai.bus.server.servlet.TomcatCometServlet.event(TomcatCom
>> e
>> tServl
>>> et.java:105)
>>>
>>> at
>>>
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilterEvent
>> (
>> Unknow
>>> n Source)
>>>
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.doFilterEvent(Unknow
>>> n
>>> Source)
>>>
>>> at org.apache.catalina.core.StandardWrapperValve.event(Unknown
>>> Source)
>>>
>>> at org.apache.catalina.core.StandardContextValve.event(Unknown
>>> Source)
>>>
>>> at org.apache.catalina.core.StandardHostValve.event(Unknown
>> Source)
>>>
>>> at org.apache.catalina.valves.ValveBase.event(Unknown Source)
>>>
>>> at org.apache.catalina.core.StandardEngineValve.event(Unknown
>>> Source)
>>>
>>> at org.apache.catalina.connector.CoyoteAdapter.event(Unknown
>>> Source)
>>>
>>> at org.apache.coyote.http11.Http11NioProcessor.event(Unknown
>>> Source)
>>>
>>> at
>>>
>> org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.ev
>> e
>> nt(Unk
>>> nown Source)
>>>
>>> at
>>> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(Unknown
>> Source)
>>>
>>> at
>>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec
>> u
>> tor.ja
>>> va:886)
>>>
>>> at
>>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
>> java:9
>>> 08)
>>>
>>> at java.lang.Thread.run(Thread.java:619)
>>>
>>>
>>>
>>> Can anyone point me at what I'm missing?
>>>
>>> _______________________________________________
>>> errai-users mailing list
>>> errai-users(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/errai-users
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> errai-users mailing list
>>> errai-users(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/errai-users
>>>
>>>
>>>
>>> _______________________________________________
>>> errai-users mailing list
>>> errai-users(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/errai-users
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> errai-users mailing list
>>> errai-users(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/errai-users
>>
>
>