The workaround for wsdl2java did not work for me, the output as Element
remains the same.
I will definitely check out the 2.2 code, but won't be able to do so until
tomorrow.
Meanwhile, I could not get my initialization right. Within "
MyCapability.java" I added the following code
to initialize the "_MyMetric" Property which is of type "Element":
QName QnMetric = new QName("http://ws.apache.org/muse/test/wsrf",
"MyMetric", "tns");
Element metric = XmlUtils.createElement(QnMetric);
metric.setTextContent("100");
_MyMetric = metric;
The server log shows that the resource is initialized and the code above
executed, but I still get a NullPointerException
afterwards. If I specify an intial value in the RMD file, the resource
starts up allright and the Metric Metadata is generated.
Can you give me an example of how to initialize such an "Element"-type
property correctly, or point me to corresponding documentation?
Another thing that just came to my mind: When is the "LastUpdated" attribute
updated? I mean, since the Metric is read-only for any clients, it has to be
somehow updated on the server side. But seeing the code generated for that
property, how does Muse determine that there has been an update on that
value?
Thanks a lot for your patience with my endless questioning!
Christoph
On 2/27/07, Daniel Jemiolo <[EMAIL PROTECTED]> wrote:
of course, what was I thinking - you do also need the actual Metric types
in the RMD document as well. luckily you've figured that out. I will be
sure to add that to the docs I'm creating (JIRA issue MUSE-201).
andrew may correct me, but I don't believe wsdl2java will handle an XSD
extension without giving you an Element, which is not really what you
want. you want the integer, and the attributes to be ignored (for the Java
method signature). muse's WSDM implementation will handle adding the
metric attributes before the values are put on the wire.
the following workaround may work for the moment:
<xsd:element name="MyMetric">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="MyValue" type="xsd:integer"/>
<xsd:attributeGroup ref="muws2:MetricAttributes"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
this isn't pretty, but may allow wsdl2java to generate code without
tripping up on the attribute group.
for a better fix, though, please open up a JIRA item to ask for better
recognition of WSDM Metrics in wsdl2java, so that your original XSD will
work. please reference your sample in the report.
thanks!
Dan
P.S. I added a Metrics-specific client to the Muse 2.2 code two days ago -
if you pick up the nightly build, you can find it as
org.apache.muse.ws.dm.muws.remote.MetricsClient.
"Christoph Bernhard Schwarz" <[EMAIL PROTECTED] > wrote on
02/27/2007 12:52:17 PM:
> I added ".xsd" to the namespace prefix so now Muse recognizes that the
> property is a metric. (I say it's recognized, because Muse complains, if
I
> do not add all the metadata required for a metric.)
>
> But I still need some help: I now also updated the wsdl file to add the
> AttributeGroup "muws2:MetricAttributes" to my metric like this:
>
> <xsd:element name="MyMetric">
> <xsd:complexType>
> <xsd:simpleContent>
> <xsd:extension base="xsd:integer">
> <xsd:attributeGroup
ref="muws2:MetricAttributes"
> />
> </xsd:extension>
> </xsd:simpleContent>
> </xsd:complexType>
> </xsd:element>
>
> This causes wsdl2java to generate my metric not as integer value, but as
> Element. As I understand, this now needs to be initialized somehow. Can
you
> please give me an example of how to do this? I'm constantly running into
> NullPointerException at
>
org.apache.muse.ws.resource.properties.impl.SimpleResourcePropertyCollection
.
> getResourceProperty(
> SimpleResourcePropertyCollection.java:612)
> after the Resource has been initialized.
>
> On 2/26/07, Daniel Jemiolo <[EMAIL PROTECTED]> wrote:
> >
> > sorry, I think I made the mistake in my sample RMD XML:
> >
> > the namespace for prefix muws2 should be
> > " http://docs.oasis-open.org/wsdm/muws2-2.xsd" - notice the ".xsd"
added to
> >
> > the end. if you modify the <muws2:Capability/> element by updating the
> > namespace, it should work - if not, send any trace/error info from
> > muse.log or your server log to the list and I will try to reproduce.
> >
> > for the prefix issue, see the following in our troubleshooting
section:
> >
> >
> > http://ws.apache.org/muse/docs/2.1.0/manual/troubleshooting/default-
> namespaces-xerces.html
> >
> >
> > Dan
> >
> >
> > "Christoph Bernhard Schwarz" <[EMAIL PROTECTED]> wrote on
> > 02/26/2007 07:42:25 AM:
> >
> > > Hi!
> > >
> > > Thank you for the extensive answer. Unfortunately, my problem still
> > remains:
> > > I used the wsdl from the 'wsrf' as a starting point, and added one
> > property
> > > named 'MyMetric'. I also added the 'CurrentTime' property defined as
> > required
> > > by MUWS2 (Adding this property has the wsdl2java tool automatically
> > generating
> > > the Metrics-Capability entry in muse.xml). In the .rmd-File I marked
> > that
> > > property as Metric, as you described, but with no effect.
> > > I'm currently using the 2.1.0 binary distribution. The files I
modified
> > are
> > > attached to this mail.
> > >
> > > One other thing that I don't quite understand is, that when I want
to
> > access a
> > > resource property by using
> >
> > > proxy.getResourceProperty(new QName("MyProperty"));
> > >
> > > I get a PropertyNotInSchema - Error. And when I add the namespace
URI
> >
> > > proxy.getResourceProperty(new
> > QName("http://ws.apache.org/muse/test/wsrf ",
> > > "MyProperty"));
> > >
> > > there is a SAXParseException thrown on the server side
> > > [Fatal Error] :13:72: Element or attribute do not match QName
> > production:
> > > QName::=(NCName':')?NCName.
> > > ...
> > >
> > > So I went ahead and also added the prefix part:
> >
> > > proxy.getResourceProperty (new
> > QName(" http://ws.apache.org/muse/test/wsrf",
> > > "MyMetric", "myns"));
> > >
> > > Now that went OK. It even doesn't matter what I set as prefix. But
I
> > guess
> > > that operation should also be successful without specifying any
prefix,
> > > because I saw that normally Muse generates a prefix for all the
> > namespaces
> > > (something like pfx0).
> > >
> > > Christoph
> >
> > > On 2/25/07, Daniel Jemiolo < [EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > The WSDM Configuration capability does not define any additional
> > metadata
> > > that could be associated with properties or operation - right now
it's
> > > really just for semantics (so a client can see that your interface
makes
> >
> > > the resource configurable by a remote client).
> > >
> > > The WSDM Metrics capability allows you to add metric metadata to
> > existing
> > > resource properties. There is some info on the Metrics capability
here:
> > >
> > >
> > >
> >
http://ws.apache.org/muse/docs/2.1.0/manual/capabilities/wsdm-metrics.html
> >
> > >
> > > To clarify the instructions on this page, you can add Metrics
support to
> > > your resource type using Muse is:
> > >
> > > 1. Add the Metrics capability to your <resource-type/> in muse.xml :
> > >
> > > <capability>
> > >
> > >
> >
<capability-uri>http://docs.oasis-open.org/wsdm/muws/capabilities/Metrics
> > > </capability-uri>
> > >
> > >
> > <java-capability-class>org.apache.muse.ws.dm.muws.impl.SimpleMetrics
> > </java-
> > > capability-class>
> > > </capability>
> > >
> > > 2. Make sure you have an RMD (metadata) document for your resource
> > > properties. You can see an example of RMD usage in the 'wsrf' sample
> > > project.
> > >
> > > 3. The <wsrmd:Property/> elements for the properties that you
consider
> > to
> > > be metrics needs the following element underneath it:
> > >
> > > <muws2:Capability
> > > xmlns:muws2="http://docs.oasis-open.org/wsdm/muws2-2">
> > http://docs.oasis-open .
> > > org/wsdm/muws/capabilities/Metrics<muws2:Capability>
> > >
> > >
> > > This will tell Muse that the Metrics capability is associated with
the
> > > property. The Metrics capability will create and maintain all of the
> > > metadata for the property (when you update the property, it will set
the
> > > value of "LastUpdated", etc.).
> > >
> > > 4. Use the getResourceProperty() method on your generated client to
get
> > > the property values in XML form. You can then extract the Metrics
> > > attributes from them like so:
> > >
> > >
> > > Element[] properties = client.getResourceProperty(new
> > > QName("MyPropertyName"));
> > >
> > > for (int n = 0; n < properties.length; ++n)
> > > {
> > > String updateTime =
properties[n].getAttribute("LastUpdated");
> > > System.out.println("Last updated on: " + updateTime);
> > > }
> > >
> > >
> > > Admittedly, Muse could have a more convenient way of getting the
> > > properties and the metric metadata at the same time (in this system,
you
> >
> > > can't use getPropertyAsObject() to get the property values as POJOs
-
> > you
> > > have to get them as XML first). I will create JIRA item for this.
> > >
> > > I will also add the above info to the Metrics capability
documentation.
> > >
> > > Dan
> > >
> > >
> > > "Christoph Bernhard Schwarz" < [EMAIL PROTECTED]> wrote
on
> > > 02/25/2007 07:11:40 AM:
> > >
> > > > hi!
> > > >
> > > > as far as i understood the standard, metrics and configurations
are
> > > > specialized resource properties. how do i specify a resource
property
> > to
> > > be
> > > > a metric or configuration in the wsdl file that is used for code
> > > generation?
> > > > and how do i access the meta-information that is attached to a
metric
> > > (e.g.
> > > > lastupdated) from the client side proxy?
> > > >
> > > > any help appreciated,
> > > > christoph
> > >
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > > [attachment "WsResource.wsdl" deleted by Daniel Jemiolo/Durham/IBM]
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]