Ok. Good with me. Will make the change. If this is the new standard, think
will be several other modules that will need to make the change (jmx, jms,
etc.).
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3854654#3854654
Reply to the post :
http://www.jbos
Why is module/tests/src instead of module/src/test? Thought most people have
module/src/test and module/src/main.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3854646#3854646
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=r
Yes. This is great by me. Will add the functional-tests target to the remoting
build.xml next week, so can try it out.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3854137#3854137
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&
Think is refering to org.jboss.remoting.AbstractInvoker. Will fix. Thanks.
-Tom
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3851842#3851842
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3851842
--
Use org.jboss.mx.server.MBeanServerImpl.getClassLoaderRepository() to get the
org.jboss.mx.loading.UnifiedLoaderRepositoryMBean. From there can call:
public Translator getTranslator();
public void setTranslator(Translator t);
View the original post :
http://www.jboss.org/index.html?module=bb&o
BTW, if writing something you think would be useful for others, should consider
contributing it. :)
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3851368#3851368
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3851368
Think you are looking for byte code transformation api, right? This can only be done
programatically, and not by configuration.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3851228#3851228
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=po
If just worried about client and server being interoperable between 3.2 versions, this
should work. However, is possible that API of client proxy, interceptors which are
used (i.e. transaction, security, etc.) or even invocation context may have changed
between versions. If methods were remove
Assume your question is related to EJB invocations? If so, when an EJB is deployed,
the client proxy and interceptors are serialized and bound within JNDI. So when the
client does the JNDI look up for the EJB, will pull the serializaed version the server
bound. To deserialize within the clien
As part of the unified invoker refactor, am working on moving the marshalling of the
transaction out of the invoker itself and into a marshaller. I see that in the case
of a ClientUserTransaction, it actually sets itself as the
TransactionPropagationContextFactory on the JRMPInvokerProxy when i
Think we are looking at it a little differently, but see now where you are coming
from. You are just wanting to have the marshaller be responsible at a high level to
ensure all the items within the payload can be marshalled correctly, Transaction for
example. I was looking at it from a little
My bad. When I said that I agree, meant with
public void write(Object dataObject, OutputStream output);
So meant ok with OutputStream, but not ObjectOutput (sorry, will teach me not to post
so late at night :)
I don't want ObjectOutput passed to Marshaller because I don't want it to ever c
Ok. I agree with:
public void write(Object dataObject, ObjectOutput output) throws IOException;
Eventhough I would rather use an interface instead of an abstract class, would still
be able to over write all the methods of ObjectOutput for a custom implementation.
Am not sure what you mean by
In the remoting refactor, will be introducing a Marshaller interface. Would like the
main method of this interface to have the following signature:
public void write(Object dataObject, DataOutput output) throws IOException
so that the marshaller will marshal the dataObject to the DataOutput. W
Is the callbackobject class (x.y.sample) within the server deoployment file? The
server is giving the error because it can not load this class. Although you are
implementing the interface from the server, the server still has to load the actual
implementation class when it gets server side.
Put your client class in the same deployment (am guessing ejb jar) file as your
session bean..
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3844872#3844872
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3844872
-
Sure. Will have to make sure that you don't have port conflicts such as JNDI (see
jboss-service.xml) and web server (see service.xml in tomcat sar).
Easiest thing to do is take server/default directory (or all, depending on what
services you are using) and make a copy of it using a new name (i.
You are using the JSR 160 APIs, which we don't yet support.
Can find an example of how to do the same thing in PingPongTest (will have to get the
source). Is in
jmx-remoting\src\test\jboss\test\mx\remoting\pingpong\PingPongTest.java.
In this example, it explicitly sets the handler. Can go t
Can find documentation on remoting at
http://www.jboss.org/developers/projects/jboss/remoting.
Can you provide a little sample code or give more detailed on how you are exposing
your mbean remotely? There are several ways to do this, so would help in know
approach you are using.
-Tom
View
In the current code base (may have changed between DR4 and now, but don't think so),
the package is org.jboss.aspects.remoting. Therefore the fully qualified class name
should be:
org.jboss.aspects.remoting.AOPRemotingInvocationHandler
Can be found in the jboss-sapects.jar in the server/defaul
There currently is not support for the JSR160 specification. There is, however,
support for remote JMX, but is not compliant with JSR 160. What tests are you running?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3844047#3844047
Reply to the post :
http://
Also need ability to separate the payloads as is done the the current invoker so can
include things such as security credentials to server side to check security before
allowing dynamic classloading (which would have to be done before deserializing the
target payload).
View the original post :
Wanted to get feedback on how people would like to see a JNDI viewer work for the web
console.
My thinking is there are two basic ways of doing it. One is to populate a html view
of the tree on the right frame using javascript to make the tree
collapsable/expandable. This would be a static
When put in entries for domain, can only send from or to that domain. So, for
example, put in e2.net as domain. Can send from e2.net and receive the e-mail. Can
sent to e2.net, but instead of getting to e2.net, shows up in my inbox. If try to
sent from domain not listed within domain element
In the wiki you list how to set up domains (which are the only domains that the server
will deliver mail to). How to you remove this restriction so that will deliver to all
domains? Just have a blank domain element?
Thanks.
-Tom
View the original post :
http://www.jboss.org/index.html?modul
I personally can't stand Maven (still have the scars from previous attempts in using
it). However, I think Scott has the right idea. If someone really wants to use it
and can put together a maven build that works, it would be worth reviewing what they
have.
http://www.jboss.org/index.html?m
It is possible to do this if just want to wrap the exception in something else and
re-throw it. Is this all you are trying to do?
If you want to re-try, you can do that as well by calling getNext().invoke(mi) again,
but should not expect any differnt results.
View the original post :
http:/
Not positive, but looks like you must be adding yourself as a notification listener
directly to the detector and handling the notification for a new detection? This was
not the original intent of the notifications from the detector (really just added for
the DetectorUtil class), but should work
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3820754#3820754
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3820754
Sure. Really trying to understand how the client side part of the interceptor stack
will be maintaine
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3820686#3820686
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3820686
So what would happen in the case of async invocations? Does the whole state contained
in the invocati
30 matches
Mail list logo
