RE
experts and all developers extraordinaire,
YIPPEEE…
Now a question: does this mean we do not need ANY meetings whatsoever later
today in regards to the i8 build?
Can
we assume that Shivvy will have a clean / final / complete i8 build first thing
Monday AM Indian time (which is Sunday night)?
Thanks,
Jimmy Mohsin
Cell +1-609-635-1703
From: cosmos-dev-bounces@xxxxxxxxxxx
[mailto:cosmos-dev-bounces@xxxxxxxxxxx] On Behalf Of Hawkins, Joel
Sent: Friday, January 18, 2008 12:36 PM
To: Hubert H Leung
Cc: Muldoon, William H; Todd, John A; Devine, John T; Stratton, Paul;
cosmos-dev@xxxxxxxxxxx
Subject: [cosmos-dev] RE: Build issue
Works for me. Once again, nice work everybody. I’ll keep an
eye out for the next build.
-----Original Message-----
From: Hubert H Leung [mailto:hkyleung@xxxxxxxxxx]
Sent: Friday, January 18, 2008 12:33 PM
To: Hawkins, Joel
Cc: cosmos-dev@xxxxxxxxxxx; Devine, John T; Todd, John A; Stratton,
Paul; Mark D Weitzel; Muldoon, William H
Subject: RE: Build issue
Hi Joel,
We don't need
to call. I will update the manifest files, and start a build. I
know there is code checked in for the UI as well. Let's all check the
next build.
Thanks,
_________________________
Hubert Leung
IBM Toronto Lab
hkyleung@xxxxxxxxxx
905-413-3382
"Hawkins,
Joel" <Joel.Hawkins@xxxxxxxxxxxxx>
01/18/2008
12:30 PM
|
To
|
"Todd,
John A" <John.Todd@xxxxxx>, "Muldoon, William H"
<William.Muldoon@xxxxxx>, Hubert H Leung/Toronto/IBM@IBMCA,
<cosmos-dev@xxxxxxxxxxx>
|
cc
|
"Devine,
John T" <John.Devine@xxxxxx>, "Stratton, Paul"
<Paul.Stratton@xxxxxx>, "Mark D Weitzel"
<weitzelm@xxxxxxxxxx>
|
Subject
|
RE:
Build issue
|
|
And
I would publicly like to give 99% of that to Hubert!
Are we doing the 12:30 call-in, or can we declare victory by email?
Cheers,
Joel
-----Original
Message-----
From: Todd, John A [mailto:John.Todd@xxxxxx]
Sent: Friday, January 18, 2008 12:25 PM
To: Muldoon, William H; Hawkins, Joel; Hubert H Leung
Cc: Devine, John T; Stratton, Paul; Mark D Weitzel
Subject: RE: Build issue
Hooray!
I have just independently verified the solution.
That works for me too.
I would like to publicly thank Hubert and Joel for their effort
here.
- John
From: Muldoon, William H
Sent: Friday, January 18, 2008 12:23 PM
To: Hawkins, Joel; Hubert H Leung
Cc: Devine, John T; Todd, John A; Stratton, Paul; Mark D Weitzel
Subject: RE: Build issue
I think it means we need to buy Hubert lunch!
Also, I’ve checked in changes for the CMDBf query problem. So
let the build begin…
From: Hawkins, Joel
[mailto:Joel.Hawkins@xxxxxxxxxxxxx]
Sent: Friday, January 18, 2008 12:18 PM
To: Hubert H Leung
Cc: Devine, John T; Todd, John A; Stratton, Paul; Mark D Weitzel; Muldoon,
William H
Subject: RE: Build issue
Yeah!!! Does this mean I can go get lunch?
-----Original
Message-----
From: Hubert H Leung [mailto:hkyleung@xxxxxxxxxx]
Sent: Friday, January 18, 2008 12:16 PM
To: Hawkins, Joel
Cc: Devine, John T; Todd, John A; Stratton, Paul; Mark D Weitzel; Muldoon,
William H
Subject: RE: Build issue
I think I got it...
In the manifest file of
org.eclipse.cosmos.dc.logging.datamgr.common and org.eclipse.cosmos.dc.stat.datamgr.common
we need to add org.apache.xerces to the require-Bundle section. I also
added org.w3c.dom to the
import-package section.
Now I got the EPR bounded message!
_________________________
Hubert Leung
IBM Toronto Lab
hkyleung@xxxxxxxxxx
905-413-3382
"Hawkins,
Joel" <Joel.Hawkins@xxxxxxxxxxxxx>
01/18/2008
11:32 AM
|
To
|
Hubert
H Leung/Toronto/IBM@IBMCA
|
cc
|
"Devine,
John T" <John.Devine@xxxxxx>, "Todd, John A"
<John.Todd@xxxxxx>, "Stratton, Paul" <Paul.Stratton@xxxxxx>,
"Mark D Weitzel" <weitzelm@xxxxxxxxxx>, "Muldoon,
William H" <William.Muldoon@xxxxxx>
|
Subject
|
RE:
Build issue
|
|
OMG – reminds me of whack-a-QName from the old days…
Shall we still call in, or wait a bit for Hubert to try some
classpath tricks?
-----Original
Message-----
From: Hubert H Leung [mailto:hkyleung@xxxxxxxxxx]
Sent: Friday, January 18, 2008 11:31 AM
To: Hubert H Leung
Cc: Hawkins, Joel; Devine, John T; Todd, John A; Stratton, Paul; Mark D
Weitzel; Muldoon, William H
Subject: RE: Build issue
Hi John and Joel,
I managed to get an interesting stacktrace:
Nested Exception:
java.lang.NoClassDefFoundError: org.w3c.dom.Element
at java.lang.Class.getDeclaredMethodsImpl(Native Method)
at java.lang.Class.getDeclaredMethods(Class.java:612)
at
java.lang.Class.getInterfaceMethodCountImpl(Class.java:861)
at java.lang.Class.getInterfaceMethodsImpl(Class.java:876)
at
java.lang.Class.getMethods(Class.java:821)
at
org.eclipse.cosmos.dc.mgmt.common.util.ManagedProxyInvocationHandler.getAnnotation(ManagedProxyInvocationHandler.java:404)
at
org.eclipse.cosmos.dc.mgmt.common.util.ManagedProxyInvocationHandler.processAnnotations(ManagedProxyInvocationHandler.java:365)
at
org.eclipse.cosmos.dc.mgmt.common.util.ManagedProxyInvocationHandler.<init>(ManagedProxyInvocationHandler.java:456)
at org.eclipse.cosmos.dc.mgmt.common.util.ManagementProxyFactory.getManagedProxy(ManagementProxyFactory.java:124)
at
org.eclipse.cosmos.dc.mgmt.osgi.ContributionManagerImpl.manage(ContributionManagerImpl.java:65)
at
org.eclipse.cosmos.dc.dataManager.impl.AbstractDataManagerActivator.serviceChanged(AbstractDataManagerActivator.java:98)
at
org.eclipse.cosmos.dc.dataManager.impl.AbstractDataManagerActivator.start(AbstractDataManagerActivator.java:73)
My current theory of the problem is that if a class has the class Element in a
method signature, the class reflection fails to find the Element class.
It may be a classloader problem.
I will now work on tweaking the manifest file settings...
Give me a shot if you know how to fix it!
_________________________
Hubert Leung
IBM Toronto Lab
hkyleung@xxxxxxxxxx
905-413-3382
Hubert
H Leung/Toronto/IBM
01/18/2008
10:17 AM
|
To
|
"Hawkins,
Joel" <Joel.Hawkins@xxxxxxxxxxxxx>
|
cc
|
"Devine,
John T" <John.Devine@xxxxxx>, "Todd, John A"
<John.Todd@xxxxxx>, "Stratton, Paul" <Paul.Stratton@xxxxxx>,
"Mark D Weitzel" <weitzelm@xxxxxxxxxx>, "Muldoon,
William H" <William.Muldoon@xxxxxx>
|
Subject
|
RE:
Build issueLink
|
|
I confirmed John's finding that the program stops at
Method
methods[] = resourceClass.getMethods();
where resourceClass is the LoggingDataManager's class object.
I added the following two lines at AbstractDataManagerActivator, right before
we call contribution manager. The program stops at this getMethods() call
as well.
Method[] methods = dataMgrImpl.getClass().getMethods();
System.out.println("number of methods: " + methods.length);
manager.manage(dataMgrImpl);
So there is something strange about this class, but I have no clue what that
is.
_________________________
Hubert Leung
IBM Toronto Lab
hkyleung@xxxxxxxxxx
905-413-3382
"Hawkins,
Joel" <Joel.Hawkins@xxxxxxxxxxxxx>
01/17/2008
04:57 PM
|
To
|
Hubert
H Leung/Toronto/IBM@IBMCA
|
cc
|
"Devine,
John T" <John.Devine@xxxxxx>, "Todd, John A"
<John.Todd@xxxxxx>, "Stratton, Paul"
<Paul.Stratton@xxxxxx>, "Mark D Weitzel" <weitzelm@xxxxxxxxxx>,
"Muldoon, William H" <William.Muldoon@xxxxxx>
|
Subject
|
RE:
Build issue
|
|
OK. I’m running the same thing Hubert’s got, so I should be able to
duplicate this. I’ll work on it tonght.
-----Original
Message-----
From: Hubert H Leung [mailto:hkyleung@xxxxxxxxxx]
Sent: Thursday, January 17, 2008 4:41 PM
To: Hawkins, Joel
Cc: Devine, John T; Todd, John A; Stratton, Paul; Mark D Weitzel; Muldoon,
William H
Subject: RE: Build issue
I have this:
java version "1.5.0_11"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode)
and this:
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20070201
(SR4))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32
j9vmwi3223-2007020
1 (JIT enabled)
J9VM - 20070131_11312_lHdSMR
JIT - 20070109_1805ifx1_r8
GC - 200701_09)
JCL - 20070131
_________________________
Hubert Leung
IBM Toronto Lab
hkyleung@xxxxxxxxxx
905-413-3382
"Hawkins,
Joel" <Joel.Hawkins@xxxxxxxxxxxxx>
01/17/2008
04:34 PM
|
To
|
"Todd,
John A" <John.Todd@xxxxxx>, Hubert H Leung/Toronto/IBM@IBMCA
|
cc
|
"Devine,
John T" <John.Devine@xxxxxx>, "Stratton, Paul"
<Paul.Stratton@xxxxxx>, "Mark D Weitzel"
<weitzelm@xxxxxxxxxx>, "Muldoon, William H"
<William.Muldoon@xxxxxx>
|
Subject
|
RE:
Build issue
|
|
And what JRE is everyone using? I’m using Sun’s VM (1.5.11).
-----Original
Message-----
From: Todd, John A [mailto:John.Todd@xxxxxx]
Sent: Thursday, January 17, 2008 4:26 PM
To: Hawkins, Joel; Hubert H Leung
Cc: Devine, John T; Stratton, Paul; Mark D Weitzel; Muldoon, William H
Subject: RE: Build issue
I was in the middle of sending you email saying that,
Just add the appropriate dm jars to the config.ini (and you might
have to add org.w3c.dom, depending on your JRE)
And it should reproduce for you....in theory.
- John
From: Hawkins, Joel
[mailto:Joel.Hawkins@xxxxxxxxxxxxx]
Sent: Thursday, January 17, 2008 4:24 PM
To: Todd, John A; Hubert H Leung
Cc: Devine, John T; Stratton, Paul; Mark D Weitzel; Muldoon, William H
Subject: RE: Build issue
But if I download the demo and follow the install steps, I should
be able to reproduce this without any problems, right?
-----Original
Message-----
From: Todd, John A [mailto:John.Todd@xxxxxx]
Sent: Thursday, January 17, 2008 4:22 PM
To: Hubert H Leung; Hawkins, Joel
Cc: Devine, John T; Stratton, Paul; Mark D Weitzel; Muldoon, William H
Subject: RE: Build issue
We’ve been poking around using system.out.printlns and minor
changes in ManagedProxyInvocationHandler, but still have no definitive clues.
- John
From: Hubert H Leung
[mailto:hkyleung@xxxxxxxxxx]
Sent: Thursday, January 17, 2008 4:15 PM
To: Hawkins, Joel
Cc: Devine, John T; Todd, John A; Stratton, Paul; Mark D Weitzel; Muldoon,
William H
Subject: RE: Build issue
When it works, I see an output at the console like:
Jan 17, 2008 1:58:09 PM org.apache.muse.core.routing.SimpleResourceRouter
initia
lize
INFO: [ID = 'RouterIsInitialized'] The resource router has been initialized.
serviceChanged in AbstractDataManager
Jan 17, 2008 1:58:09 PM org.apache.muse.core.SimpleResource initialize
INFO: [ID = 'ResourceInitialized'] The resource at '/datamanager.DataManagerImpl
' has been initialized.
Bound<wsa:EndpointReference
xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:Address>http://9.26.188.72:8081/cosmos/services/datamanager.DataManager
Impl</wsa:Address>
<wsa:ReferenceParameters>
<muse-wsa:ResourceId
xmlns:muse-wsa="http://ws.apache.org/muse/addressin
g">dmtest</muse-wsa:ResourceId>
</wsa:ReferenceParameters>
</wsa:EndpointReference>
Note the EPR printed. There should be one EPR for each MDR or data
manager in the container. When I run the build, I only see two EPRs,
printed. The EPRs two new data managers are not bound.
I don't see any stacktrace.
_________________________
Hubert Leung
IBM Toronto Lab
hkyleung@xxxxxxxxxx
905-413-3382
"Hawkins,
Joel" <Joel.Hawkins@xxxxxxxxxxxxx>
01/17/2008
03:14 PM
|
To
|
"Todd,
John A" <John.Todd@xxxxxx>, Hubert H Leung/Toronto/IBM@IBMCA,
"Muldoon, William H" <William.Muldoon@xxxxxx>
|
cc
|
"Devine,
John T" <John.Devine@xxxxxx>, "Stratton, Paul"
<Paul.Stratton@xxxxxx>, "Mark D Weitzel"
<weitzelm@xxxxxxxxxx>
|
Subject
|
RE:
Build issue
|
|
Can you elaborate on ‘doesn’t work’?
-----Original
Message-----
From: Todd, John A [mailto:John.Todd@xxxxxx]
Sent: Thursday, January 17, 2008 2:04 PM
To: Hubert H Leung; Muldoon, William H
Cc: Hawkins, Joel; Devine, John T; Stratton, Paul; Mark D Weitzel
Subject: RE: Build issue
Some kind of silent dependency on org.w3c.dom something?
I agree it is very weird because as you mentioned the other MDRs
which work have this.
- John
From: Hubert H Leung
[mailto:hkyleung@xxxxxxxxxx]
Sent: Thursday, January 17, 2008 1:49 PM
To: Muldoon, William H
Cc: Hawkins, Joel; Devine, John T; Todd, John A; Stratton, Paul; Mark D
Weitzel
Subject: RE: Build issue
Hi all,
Here is an update of my findings. I can't pinpoint the location yet, but
I found that a change in the managed operation method signature can make a
difference.
I created a test program with a very simple data manager. See attached
file. The capability interface "ITest" has only one method. The EPR of
the data manager is bound if the capability has the following operation:
@ManagedOperation
public String
test(String x) throws
CosmosException;
However, if I change the return type to Element, then it doesn't work.
@ManagedOperation
public Element
test(String x) throws
CosmosException;
It's strange because there the IQuery interface has a capability that returns
Element, and MDRs work.
You can play around with my test case. Unzip datamanager.zip it to the
DataManagers/plugins directory. And update the config.ini to append the
following string to the first line:
plugins/datamanager_1.0.0@start, plugins/datamanager.common_1.0.0@start
Source code of the 2 modules are in the code.zip. You can import them to
your workspace:
_________________________
Hubert Leung
IBM Toronto Lab
hkyleung@xxxxxxxxxx
905-413-3382
"Muldoon,
William H" <William.Muldoon@xxxxxx>
01/17/2008
11:01 AM
|
To
|
"Hawkins,
Joel" <Joel.Hawkins@xxxxxxxxxxxxx>, Hubert H
Leung/Toronto/IBM@IBMCA
|
cc
|
"Devine,
John T" <John.Devine@xxxxxx>, "Todd, John A"
<John.Todd@xxxxxx>, "Stratton, Paul"
<Paul.Stratton@xxxxxx>
|
Subject
|
RE:
Build issue
|
|
Hi Joel
To summarize the problem: we have 4 data managers, 2
are mdrs (Example & SML) and 2 are data managers (CBE & Stat). All of
them work within osgi. But outside of osgi, only the 2 mdrs work. JT traced the
failure of the 2 data managers outside osgi to the resourceClass.getMethods()
line in ManagedProxyInvocationHandler.java (using tedious println statements).
There was no actual failure exception thrown; instead the println after the
getMethods was never reached. So it appeared that getMethods() hung the thread.
Since this hang occurred while processing the annotations, we thought you could
help identify the cause and provide a resolution.
Hope this helps.
Regards
Bill
From:
Hawkins, Joel [mailto:Joel.Hawkins@xxxxxxxxxxxxx]
Sent: Thursday, January 17, 2008 10:59 AM
To: Hubert H Leung
Cc: Devine, John T; Todd, John A; Stratton, Paul; Muldoon, William H
Subject: RE: Build issue
OK. I’m off to meetings. I’ll try and get to this over lunch.
Cheers
-----Original Message-----
From: Hubert H Leung [mailto:hkyleung@xxxxxxxxxx]
Sent: Thursday, January 17, 2008 10:56 AM
To: Hawkins, Joel
Cc: Devine, John T; Todd, John A; Stratton, Paul; Muldoon, William H
Subject: RE: Build issue
Hi Joel,
We are using org.eclipse.equinox.ds taken from orbit. I don't know who
implemented it.
You can download the build from here:
http://www.eclipse.org/cosmos/downloads/
The last two developement builds should be good. I am running with
COSMOS-1.0.0-200801142344.
_________________________
Hubert Leung
IBM Toronto Lab
hkyleung@xxxxxxxxxx
905-413-3382
"Hawkins,
Joel" <Joel.Hawkins@xxxxxxxxxxxxx>
01/17/2008
10:44 AM
|
To
|
Hubert
H Leung/Toronto/IBM@IBMCA, "Todd, John A"
<John.Todd@xxxxxx>
|
cc
|
"Devine,
John T" <John.Devine@xxxxxx>, "Stratton, Paul"
<Paul.Stratton@xxxxxx>, "Muldoon, William H"
<William.Muldoon@xxxxxx>
|
Subject
|
RE:
Build issue
|
|
Hubert,
From what I understood (wrongly – it appears), you were
getting the stack trace during registration whenever you ran. It wasn’t
clear to me that this only occurs running outside of OSGi. When I ran, I got a
different exception, which I attributed to some sort of race condition. When I
flipped the implementation over to use declarative services on both ends,
everything registered fine.
Looking at your code, I agree that it should work – I’m
wondering if it’s a problem with the equinox declarative services
implementation, where the service registration event is going out before the
service is actually initialized. In the binding code, I use the activate call
to initialize muse, and I’m wondering if DS is sending the registration
event prior to the activate returning.
IIRC, ProSyst had donated a production-strength implementation of
DS to equinox – is that the one we’re running with?
Can you point me to your current build?
Thanks,
Joel
-----Original
Message-----
From: Hubert H Leung [mailto:hkyleung@xxxxxxxxxx]
Sent: Thursday, January 17, 2008 10:25 AM
To: Todd, John A
Cc: Hawkins, Joel; Devine, John T; Stratton, Paul; Muldoon, William H
Subject: RE: Build issue
Joel, can you briefly summary your findings on what caused the problem?
The proposed change is pretty big. It changes the programming model and
affects existing data managers.
The reason why I didn't use declarative service is because I didn't want every
developer who need to create a data manager or MDR to create a component XML,
and let the framework handle the osgi service related details. I will
look for a simpler solution.
_________________________
Hubert Leung
IBM Toronto Lab
hkyleung@xxxxxxxxxx
905-413-3382
"Todd,
John A" <John.Todd@xxxxxx>
01/17/2008
09:59 AM
|
To
|
"Hawkins,
Joel" <Joel.Hawkins@xxxxxxxxxxxxx>, Hubert H
Leung/Toronto/IBM@IBMCA
|
cc
|
"Devine,
John T" <John.Devine@xxxxxx>, "Muldoon, William H"
<William.Muldoon@xxxxxx>, "Stratton, Paul"
<Paul.Stratton@xxxxxx>
|
Subject
|
RE:
Build issue
|
|
I had a look at the patch, though some of it is greek to me.
The problem is that its not as easy as applying the patch to workspace and
trying it out, because my workspace already works just fine,
Its what the build generates that is a pickle, so there is some environmental
factor involved.
- John
From:
Hawkins, Joel [mailto:Joel.Hawkins@xxxxxxxxxxxxx]
Sent: Thursday, January 17, 2008 7:43 AM
To: Todd, John A; Hubert H Leung
Cc: Devine, John T; Muldoon, William H; Stratton, Paul
Subject: RE: Build issue
Patch below – it’s a multi-project patch – give it a shot and
let me know what you think. I left the AbstractDataManagerActivator intact
– it’s just not used anymore.
Cheers,
Joel
### Eclipse Workspace Patch 1.0
#P org.eclipse.cosmos.dc.logging.datamgr
Index: build.properties
===================================================================
RCS file:
/cvsroot/technology/org.eclipse.cosmos/data-collection/org.eclipse.cosmos.dc.logging.datamgr/build.properties,v
retrieving revision 1.2
diff -u -r1.2 build.properties
--- build.properties 7 Jan 2008 19:23:21
-0000 1.2
+++ build.properties 17 Jan 2008 12:40:40 -0000
@@ -1,7 +1,6 @@
source.. = src/
output.. = bin/
-bin.includes = META-INF/,\
- .,\
+bin.includes = .,\
bin/,\
logs/,\
src/
Index: src/org/eclipse/cosmos/dc/logging/datamgr/Activator.java
===================================================================
RCS file:
/cvsroot/technology/org.eclipse.cosmos/data-collection/org.eclipse.cosmos.dc.logging.datamgr/src/org/eclipse/cosmos/dc/logging/datamgr/Activator.java,v
retrieving revision 1.1
diff -u -r1.1 Activator.java
--- src/org/eclipse/cosmos/dc/logging/datamgr/Activator.java
19 Dec 2007 21:02:52 -0000 1.1
+++ src/org/eclipse/cosmos/dc/logging/datamgr/Activator.java
17 Jan 2008 12:40:40 -0000
@@ -12,13 +12,19 @@
import org.eclipse.cosmos.dc.dataManager.api.IDataManager;
import org.eclipse.cosmos.dc.dataManager.impl.AbstractDataManagerActivator;
+import org.osgi.framework.BundleActivator;
+import org.osgi.framework.BundleContext;
-public class Activator extends AbstractDataManagerActivator {
+public class Activator implements BundleActivator /*
AbstractDataManagerActivator */ {
- @Override
- protected IDataManager
getDataManagerInstance() {
- return
new LoggingDataManager();
+ public void start(BundleContext arg0)
throws Exception {
+
// TODO Auto-generated method stub
+
}
+ public void stop(BundleContext arg0) throws
Exception {
+
// TODO Auto-generated method stub
+
+ }
-}
+}
\ No newline at end of file
Index: META-INF/MANIFEST.MF
===================================================================
RCS file:
/cvsroot/technology/org.eclipse.cosmos/data-collection/org.eclipse.cosmos.dc.logging.datamgr/META-INF/MANIFEST.MF,v
retrieving revision 1.2
diff -u -r1.2 MANIFEST.MF
--- META-INF/MANIFEST.MF 15 Jan 2008 20:16:21 -0000
1.2
+++ META-INF/MANIFEST.MF 17 Jan 2008 12:40:40 -0000
@@ -5,8 +5,12 @@
Bundle-Version: 1.0.0
Bundle-Activator: org.eclipse.cosmos.dc.logging.datamgr.Activator
Bundle-Vendor: Eclipse.org
-Import-Package: org.osgi.framework;version="1.3.0"
+Import-Package: org.osgi.framework;version="1.3.0",
+ org.osgi.service.component;version="1.0.0"
Require-Bundle: org.eclipse.cosmos.dc.dataManager,
org.apache.muse.complete,
org.eclipse.cosmos.dc.logging.datamgr.common,
org.eclipse.cosmos.common
+Service-Component: META-INF/DataManager.xml
+Bundle-ClassPath: .
+
Index: src/org/eclipse/cosmos/dc/logging/datamgr/LoggingComponent.java
===================================================================
RCS file: src/org/eclipse/cosmos/dc/logging/datamgr/LoggingComponent.java
diff -N src/org/eclipse/cosmos/dc/logging/datamgr/LoggingComponent.java
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ src/org/eclipse/cosmos/dc/logging/datamgr/LoggingComponent.java
1 Jan 1970 00:00:00 -0000
@@ -0,0 +1,14 @@
+package org.eclipse.cosmos.dc.logging.datamgr;
+
+import org.eclipse.cosmos.dc.dataManager.api.IDataManager;
+import
org.eclipse.cosmos.dc.dataManager.impl.AbstractDataManagerComponentFactory;
+import org.osgi.service.component.ComponentContext;
+
+public class LoggingComponent extends AbstractDataManagerComponentFactory {
+
+ @Override
+ protected IDataManager
getDataManagerInstance() {
+
return new LoggingDataManager();
+ }
+
+}
Index: META-INF/DataManager.xml
===================================================================
RCS file: META-INF/DataManager.xml
diff -N META-INF/DataManager.xml
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ META-INF/DataManager.xml 1 Jan
1970 00:00:00 -0000
@@ -0,0 +1,7 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+
+<component name="DataManager" immediate="true" >
+ <implementation
class="org.eclipse.cosmos.dc.logging.datamgr.LoggingComponent" />
+ <reference name="WSDM"
interface="org.eclipse.cosmos.dc.mgmt.binding.Binding"
cardinality="1..1" policy="static" />
+ <reference
name="ContributionManager"
interface="org.eclipse.cosmos.dc.mgmt.common.ContributionManager"
cardinality="1..1" policy="static" />
+</component>
#P org.eclipse.cosmos.dc.dataManager
Index:
src/org/eclipse/cosmos/dc/dataManager/impl/AbstractDataManagerActivator.java
===================================================================
RCS file: /cvsroot/technology/org.eclipse.cosmos/data-collection/org.eclipse.cosmos.dc.dataManager/src/org/eclipse/cosmos/dc/dataManager/impl/AbstractDataManagerActivator.java,v
retrieving revision 1.5
diff -u -r1.5 AbstractDataManagerActivator.java
--- src/org/eclipse/cosmos/dc/dataManager/impl/AbstractDataManagerActivator.java
15 Jan 2008 20:26:46 -0000
1.5
+++
src/org/eclipse/cosmos/dc/dataManager/impl/AbstractDataManagerActivator.java
17 Jan 2008 12:40:42 -0000
@@ -87,6 +87,10 @@
case ServiceEvent.REGISTERED:
ServiceReference ref =
context.getServiceReference("org.eclipse.cosmos.dc.mgmt.common.ContributionManager");
if (ref != null) {
+
try {
+
Thread.currentThread().sleep(5000);
+
} catch (InterruptedException e1) {
+
}
ContributionManager manager =
(ContributionManager)context.getService(ref);
manager.manage(dataMgrImpl);
Index: src/org/eclipse/cosmos/dc/dataManager/impl/AbstractDataManagerComponentFactory.java
===================================================================
RCS file:
src/org/eclipse/cosmos/dc/dataManager/impl/AbstractDataManagerComponentFactory.java
diff -N src/org/eclipse/cosmos/dc/dataManager/impl/AbstractDataManagerComponentFactory.java
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++
src/org/eclipse/cosmos/dc/dataManager/impl/AbstractDataManagerComponentFactory.java
1 Jan 1970 00:00:00 -0000
@@ -0,0 +1,88 @@
+/*******************************************************************************
+ * Copyright (c) 2007, 2008 IBM Corporation
+ * All rights reserved. This program and the accompanying materials
+ * are made available under the terms of the Eclipse Public License v1.0
+ * which accompanies this distribution, and is available at
+ * http://www.eclipse.org/legal/epl-v10.html
+ *
+ * Contributors:
+ * IBM Corporation - initial API and implementation
+ *******************************************************************************/
+package org.eclipse.cosmos.dc.dataManager.impl;
+
+import java.io.File;
+import java.net.URL;
+import java.util.Properties;
+
+import org.apache.muse.util.xml.XmlUtils;
+import org.apache.muse.ws.addressing.EndpointReference;
+import org.eclipse.cosmos.dc.dataManager.api.IDataManager;
+import org.eclipse.cosmos.dc.mgmt.common.ContributionManager;
+import org.osgi.framework.BundleActivator;
+import org.osgi.framework.BundleContext;
+import org.osgi.framework.ServiceEvent;
+import org.osgi.framework.ServiceListener;
+import org.osgi.framework.ServiceReference;
+import org.osgi.service.component.ComponentContext;
+import org.w3c.dom.Document;
+import org.w3c.dom.Element;
+
+
+/**
+ *
+ * This is the super class of the activator of all bundles that contains the
data manager implementation.
+ *
+ */
+public abstract class AbstractDataManagerComponentFactory {
+
+ protected BundleContext context;
+ private IDataManager dataMgrImpl;
+
+ /*
+ * (non-Javadoc)
+ * @see
org.osgi.framework.BundleActivator#start(org.osgi.framework.BundleContext)
+ */
+ public void activate(ComponentContext
context) throws Exception {
+
+
dataMgrImpl = getDataManagerInstance();
+
+
URL resource =
context.getBundleContext().getBundle().getResource("/META-INF/config.properties");
+
Properties dmConfig = new Properties();
+
dmConfig.load(resource.openStream());
+
dataMgrImpl.setConfigProperties(dmConfig);
+
+ String
domainEprFile = (String)
dmConfig.get(IDataManager.CONFIG_MGMT_DOMAIN_EPR_FILE);
+ if (domainEprFile == null) {
+ // TODO: Log entry
+ System.out.println("Warning: Data
manager registration cannot be completed because EPR of management domain is
not set.");
+ } else {
+
URL domainEprURL =
context.getBundleContext().getBundle().getResource(domainEprFile);
+
Document domainEprDoc =
XmlUtils.createDocument(domainEprURL.openStream());
+
Element eprElement =
domainEprDoc.getDocumentElement();
+
EndpointReference domainEpr = new
EndpointReference(eprElement);
+
dataMgrImpl.setManagementDomainEPR(domainEpr);
+ }
+
+
this.context = context.getBundleContext();
+
+
ContributionManager manager =
(ContributionManager)context.locateService("ContributionManager");
+
manager.manage(dataMgrImpl);
+
+
try {
+
// Try to register data manager with
broker at start up
+
// Log error if unsuccessful.
+
dataMgrImpl.register();
+ }
catch (Exception e) {
+
// TODO: log
+
System.out.println("Tried to
register data manager with broker at startup, but registration failed.");
+ }
+ }
+
+ /**
+ * A factory method for returning an
instance of the data manager implementation.
+ * This instance object should be annotated
as a ManagedResource.
+ * @return
+ */
+ protected abstract IDataManager
getDataManagerInstance();
+
+}
#P org.eclipse.cosmos.dc.stat.datamgr
Index: build.properties
===================================================================
RCS file:
/cvsroot/technology/org.eclipse.cosmos/data-collection/org.eclipse.cosmos.dc.stat.datamgr/build.properties,v
retrieving revision 1.1
diff -u -r1.1 build.properties
--- build.properties 10 Jan 2008 19:07:06
-0000 1.1
+++ build.properties 17 Jan 2008 12:40:43 -0000
@@ -1,4 +1,5 @@
source.. = src/
output.. = bin/
-bin.includes = META-INF/,\
- .
+bin.includes = .,\
+ META-INF/,\
+ bin/
Index: src/org/eclipse/cosmos/dc/stat/datamgr/Activator.java
===================================================================
RCS file:
/cvsroot/technology/org.eclipse.cosmos/data-collection/org.eclipse.cosmos.dc.stat.datamgr/src/org/eclipse/cosmos/dc/stat/datamgr/Activator.java,v
retrieving revision 1.1
diff -u -r1.1 Activator.java
--- src/org/eclipse/cosmos/dc/stat/datamgr/Activator.java 10 Jan 2008
19:07:04 -0000 1.1
+++ src/org/eclipse/cosmos/dc/stat/datamgr/Activator.java
17 Jan 2008 12:40:43 -0000
@@ -12,12 +12,19 @@
import org.eclipse.cosmos.dc.dataManager.api.IDataManager;
import org.eclipse.cosmos.dc.dataManager.impl.AbstractDataManagerActivator;
+import org.osgi.framework.BundleActivator;
+import org.osgi.framework.BundleContext;
-public class Activator extends AbstractDataManagerActivator {
+public class Activator implements BundleActivator /*
AbstractDataManagerActivator */ {
- @Override
- protected IDataManager
getDataManagerInstance() {
-
return new StatisticalDataManager();
+ public void start(BundleContext arg0)
throws Exception {
+
// TODO Auto-generated method stub
+
System.out.println("OK");
+ }
+
+ public void stop(BundleContext arg0) throws
Exception {
+
// TODO Auto-generated method stub
+
}
Index: META-INF/MANIFEST.MF
===================================================================
RCS file:
/cvsroot/technology/org.eclipse.cosmos/data-collection/org.eclipse.cosmos.dc.stat.datamgr/META-INF/MANIFEST.MF,v
retrieving revision 1.3
diff -u -r1.3 MANIFEST.MF
--- META-INF/MANIFEST.MF 15 Jan 2008 20:19:08 -0000
1.3
+++ META-INF/MANIFEST.MF 17 Jan 2008 12:40:43 -0000
@@ -5,9 +5,13 @@
Bundle-Version: 1.0.0
Bundle-Activator: org.eclipse.cosmos.dc.stat.datamgr.Activator
Bundle-Vendor: Eclipse.org
-Import-Package: org.osgi.framework;version="1.3.0"
+Import-Package: org.osgi.framework;version="1.3.0",
+ org.osgi.service.component;version="1.0.0"
Require-Bundle: org.eclipse.cosmos.dc.dataManager,
org.apache.muse.complete,
org.eclipse.cosmos.common,
org.eclipse.cosmos.dc.stat.datamgr.common,
org.apache.derby
+Bundle-ClassPath: .
+Service-Component: META-INF/StatDataManager.xml
+Bundle-RequiredExecutionEnvironment: J2SE-1.5
Index: META-INF/StatDataManager.xml
===================================================================
RCS file: META-INF/StatDataManager.xml
diff -N META-INF/StatDataManager.xml
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ META-INF/StatDataManager.xml 1 Jan 1970 00:00:00 -0000
@@ -0,0 +1,7 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+
+<component name="org.eclipse.cosmos.dc.stat.datamgr.StatComponent"
immediate="true" >
+ <implementation
class="org.eclipse.cosmos.dc.stat.datamgr.StatComponent" />
+ <reference name="WSDM"
interface="org.eclipse.cosmos.dc.mgmt.binding.Binding"
cardinality="1..1" policy="static" />
+ <reference
name="ContributionManager"
interface="org.eclipse.cosmos.dc.mgmt.common.ContributionManager"
cardinality="1..1" policy="static" />
+</component>
Index: src/org/eclipse/cosmos/dc/stat/datamgr/StatComponent.java
===================================================================
RCS file: src/org/eclipse/cosmos/dc/stat/datamgr/StatComponent.java
diff -N src/org/eclipse/cosmos/dc/stat/datamgr/StatComponent.java
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ src/org/eclipse/cosmos/dc/stat/datamgr/StatComponent.java 1 Jan 1970
00:00:00 -0000
@@ -0,0 +1,15 @@
+package org.eclipse.cosmos.dc.stat.datamgr;
+
+import org.eclipse.cosmos.dc.dataManager.api.IDataManager;
+import org.eclipse.cosmos.dc.dataManager.impl.AbstractDataManagerComponentFactory;
+import org.osgi.service.component.ComponentContext;
+
+public class StatComponent extends AbstractDataManagerComponentFactory {
+
+
+ @Override
+ protected IDataManager getDataManagerInstance(){
+
return new StatisticalDataManager();
+ }
+
+}
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose it
to anyone else. If you received it in error please notify us immediately and
then destroy it.
From:
Todd, John A [mailto:John.Todd@xxxxxx]
Sent: Wednesday, January 16, 2008 4:50 PM
To: Hubert H Leung; Hawkins, Joel
Cc: Devine, John T; Muldoon, William H; Stratton, Paul
Subject: Build issue
We tracked why the CBE and Statistical datamanagers don’t get registered
to some kind of annotation issue.
Where it gets stuck is in ManagedProxyInvocationHandler.processAnnotations()
trying to get the methods of the datamanager class
Method methods[] = resourceClass.getMethods();
It does not return from this call
Here’s how it got there.
org.eclipse.cosmos.dc.mgmt.common.util.ManagedProxyInvocationHandler.processAnnotations(ManagedProxyInvocationHandler.java:347)
at
org.eclipse.cosmos.dc.mgmt.common.util.ManagedProxyInvocationHandler.<init>(ManagedProxyInvocationHandler.java:443)
at org.eclipse.cosmos.dc.mgmt.common.util.ManagementProxyFactory.getManagedProxy(ManagementProxyFactory.java:125)
at
org.eclipse.cosmos.dc.mgmt.osgi.ContributionManagerImpl.manage(ContributionManagerImpl.java:65)
at
org.eclipse.cosmos.dc.dataManager.impl.AbstractDataManagerActivator.serviceChanged(AbstractDataManagerActivator.java:111)
at
org.eclipse.osgi.framework.internal.core.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:94)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:1224)
at
org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:195)
at
org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:141)
at org.eclipse.osgi.framework.internal.core.Framework.publishServiceEventPrivileged(Framework.java:1603)
at
org.eclipse.osgi.framework.internal.core.Framework.publishServiceEvent(Framework.java:1578)
at
org.eclipse.osgi.framework.internal.core.ServiceRegistrationImpl.<init>(ServiceRegistrationImpl.java:103)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.createServiceRegistration(BundleContextImpl.java:657)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:609)
at org.eclipse.equinox.ds.instance.RegisterComponentService.registerService(RegisterComponentService.java:102)
at
org.eclipse.equinox.ds.instance.InstanceProcess.registerComponentConfigurations(InstanceProcess.java:153)
at org.eclipse.equinox.ds.resolver.Resolver.dispatchWork(Resolver.java:701)
at
org.eclipse.equinox.ds.workqueue.WorkQueue$Queued.dispatch(WorkQueue.java:57)
at org.eclipse.equinox.ds.workqueue.WorkQueue.run(WorkQueue.java:108)
I tried to figure out what’s different about these datamanagers from the
ones that get registered but did not turn up any substantive leads.
I have no idea why it can’t get the methods of the class, or why it does
not return (instead of throwing an exception)
We noticed that if we call getDeclaredMethods() instead, it comes back but then
hangs on a getAnnotation() call on the first one it finds.
I need help figuring this out.
- John