Hello,
sorry for this slipping through the cracks. I think nobody had an immediate answer because
this is one of the features that would be *very* nice to have yet carries along a serious
risk (because it affects one of the most core parts of RHQ) and has actually not been
asked for in the community (until now ;) ). We just thought it'd be great for some
more restricted network topologies but because we saw no demand we basically didn't
want to break what's been working for us for quite some time.
That said, if you want to start working on it, you can easily do that in your own forked
repository and we will try to help you as much as we can on the "rhq" IRC
channel on freenode and/or on this list. Unfortunately we're not on github yet
(there's a plan for it and we want to move as soon as time allows) so
merging/reviewing changes will be a bit more cumbersome, but that's nothing that
can't be solved (for example I could mirror our codebase in my own github account
which you could fork, or we could be a bit hardcore and do code reviews through email and
git-request-pull or git-format-patch ;) ). Just bear in mind that we need to be quite
strict about backwards compatibility so your changes should not touch any of our public
facing APIs (which really they should not, I think) for them to be accepted upstream, if
you so wished.
Also take a look at
https://docs.jboss.org/author/display/RHQ/Contributions. You'd
need to sign a CLA to get your changes accepted but that's nothing unusual.
As for the code you should probably start looking at - it all boils down to the fact that
we have infrastructure in place that can create transparent proxies to allow calling
methods on a remote object (including reading/writing streams). This facility is then used
throughout the codebase to communicate between agent and server. Note though that the code
assumes the communication is bidirectional so you'd have to work around that fact
somehow.
The org.rhq.enterprise.communications.command.client.ClientRemotePojoFactory in the
$RHQ_CHECKOUT/modules/enterprise/comm module is the thing that creates the proxies and the
ClientCommandSender is the thing that then facilitates the communication itself. We also
use the ClientCommandSender directly to add more fun so your best bet would be to try and
keep the APIs of at least these two classes so that other code doesn't have to be
drastically changed.
Note also that I am no expert in this lowest level of our codebase so the above might be
completely wrong ;)
Looking forward to talking to you!
Lukas
----- Original Message -----
From: "Van Dillon" <vandillon(a)gmail.com>
To: rhq-devel(a)lists.fedorahosted.org
Sent: Monday, August 5, 2013 2:44:19 PM
Subject: Agent / Server Communications Options
Hi everyone,
At the end of last month I posted a question to this list. Perhaps
the post
was missed because I didn't receive an answer. If, on the other hand, I am
posting to the wrong list, please accept my apologies and I will post the
question on the rhq-users list instead.
Here is the body of the post:
>>
I'm new to RHQ and am interested in using it in several different ways. Some
of the ways I want to use it require the agent to be on platforms that do
not have a public IP address. I read the Design Documentation wiki entries:
"Design-Agent-to-Server Unidirectional Communications" and
"Design-Agent-Server Communications 3", both of
which indicate that you guys have put some serious thought into adding this
ability to RHQ.
Is this feature being added to the roadmap anytime soon? If not, is
there a
way to hook our own handlers into the agent and server communications
layers?
<<
I'm interested in getting involved in the development of this
feature if it's
still being considered.
Thanks,
Van Dillon
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel