9:49 a.m.
Jesper Pedersen [http://community.jboss.org/people/jesper.pedersen] created the
discussion
"Re: IronJacamar RHQ plugin development"
To view the discussion, visit: http://community.jboss.org/message/590675#590675
--------------------------------------------------------------
1. For the code structure, we will create 2 sub packages
for implementation of AS7, ironjacamar standalone separately. The most common functions
will be abstracted to the package: *+org.jboss.jca.rhq.core+*,
And the build process will create 2 jars like:
* ironjacamar-rhq-plugin-as7.jar // used in AS 7
* ironjacamar-rhq-plugin-standalone.jar // used in ironjacamar standalone mode
except we can find a way to know which situation the current runtime environment is in.
That is the job of the Discover process - default being a discovery against an in-vm
instance. I'll take a look at this soon.
2. If the *+org.jboss.jca.core.api.management.ManagementRepository+*
can be transferred to RHQ plugin in all situations, we can use it directly without
abstracting our own model for this RHQ plugin. This class is used only for RHQ to discover
JCA resources.
ManagementRepository is the instance that lives in the same VM as the container, and will
delegate all calls in-vm.
So in case of a plugin connecting to a remove instance you'll need a "proxy"
to handle that communication:
In-VM:
------
RHQ Plugin -> Embedded discovery -> ManagementRepository
Remote VM:
----------
RHQ Plugin -> Remote discovery -> Network transport -> RemoteManagementRepository
-> ManagementRepository
Of course we can have a facade for ManagementRepository in the plugin such that
communication can be optimized in the remote scenario, since in some instances a query for
configuration property names will limit network bandwidth.
The ManagementRepository should always delegate calls to dynamic attributes and
operations. In most cases we can handle that by supplying a WeakReference to the actual
object, and just call directly. We just need to expose the information we need in the
right locations - like the .api...Pool class.
However, currently the focus on the purely embedded case - using IronJacamar/Embedded for
testing, and IronJacamar/AS7 for real data.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/590675#590675]
Start a new discussion in IronJacamar Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
9:14 p.m.
Yang Yong [http://community.jboss.org/people/yyang%40redhat.com] created the discussion
"Re: IronJacamar RHQ plugin development"
To view the discussion, visit: http://community.jboss.org/message/590759#590759
--------------------------------------------------------------
Hi Jesper,
Returning ManagementRepository works well in ronJacamar/Embedded environment, but for
IronJacamar/AS7 and IronJacamar/standalone environments, I think it is not suitable to
return ManagementRepository instance, because we have to face many problems. In fact there
are 2 ways to return a ManagementRepository instance, we can analyze these 2 ways.
1) Serailize.
In this situation, we have to make all IronJacamar Management POJO classes
serializable even if the referenced classes, and may cause network bandwidth issue and
dirty local data issue, so this is not a good enough plan.
2) return a (Dynamic) Proxy object
A proxy object will delegate all invocations to remote IronJacamar Management Model
and don't have any local data, the problem is we have to map objects between "AS
Detyped MetaValue object" and "IronJacamar management POJO", but actually
we can resolve Detyped MetaValue and show the value in the console UI directly, this looks
like an extra work.
So, after discuss with lgao, our plan is creating an abstract layer to encapsulate all
common methods,and the separate implementations of AS7/Standalone/embedded to 3
sub-packages , and in the implementation classes of the sub-packages, can implement the
abstract methods(for example methods to get and resolve data) by using the best way in
each enironment separately, for example, use as7 management api in IronJacamar/AS7, use
jmx in IronJacamar/Standalone, and directly call ManagementRepository in
IronJacamar/Embedded for testing. This structure looks simple and clear, and easy to
maintain.
Package sturcture:
...rhq (abstract classes encapsulate all common methods here)
|
- as7 (implementation for as7 here)
|
- standalone (implementation for IronJacamar standalone here)
|
- embedded (implementation for IronJacamar embeddded testing here)
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/590759#590759]
Start a new discussion in IronJacamar Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
9:36 a.m.
Jesper Pedersen [http://community.jboss.org/people/jesper.pedersen] created the
discussion
"Re: IronJacamar RHQ plugin development"
To view the discussion, visit: http://community.jboss.org/message/590966#590966
--------------------------------------------------------------
I think you misunderstood me.
The network transport part is specific to IronJacamar - our own protocol - to retrieve
information or invoke operations. There is no serialization of the ManagementRepository
going on - nor proxy stuff.
The packages you mentions are correct - they contains the functionality needed to discover
the environment, like the embedded container.
F.ex. the "as7" and "standalone" will have a discovery implementation
for accessing remote containers based on the "manual add" functionality (
http://pilhuhn.blogspot.com/search?q=manualadd
http://pilhuhn.blogspot.com/search?q=manualadd).
The focus should be on the core and embedded packages first, as we need that for testing
the plugin, and defining which functionality we need from the IronJacamar container. Once
that is done we will do an as7.InVMDiscovery class for AS 7 specific discovery. After that
an as7.RemoteDiscovery class.
The "standalone" package has the lowest priority as the standalone distribution
doesn't feature a RHQ platform at the moment. It is correct that a bridge between the
plugin and JMX would be the quickest solution.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/590966#590966]
Start a new discussion in IronJacamar Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
5329
days inactive
5330
days old
jboss-dev-forums@lists.jboss.org
2 comments
2 participants
participants (2)
-
Jesper Pedersen -
Yang Yong