You are viewing a plain text version of this content. The canonical link for it is here.
Posted to muse-user@ws.apache.org by "Jared A. Zebedee" <ze...@cs.queensu.ca> on 2007/08/29 20:36:02 UTC
Capability URIs and Resource Property Namespaces
I have built a Manageable Resource which includes custom Capabilities.
It appears that Muse interprets each Resource Property Schema referenced in
the WSDL as a Capability. Each Capability is assigned a URI that matches
the namespace of the corresponding Resource Property Schema.
In the WSDM specification, Capability URIs are not the same as Resource
Property namespaces:
For example, the 'ResourceID' Resource Property is part of the 'Identity'
Capability.
The 'Identity' Capability's URI is:
http://docs.oasis-open.org/wsdm/muws/capabilities/Identity
The 'ResourceID' Property's Namespace is:
http://docs.oasis-open.org/wsdm/muws1-2.xsd
But for each of my custom Capabilities, the Capability URI is the same as
the Namespace URI of all the Properties that are part of the Capability. I
personally like the idea of them being the same, but I'm not sure if this is
allowable by the Standard. Am I doing something wrong, or is this how Muse
is designed to deal with Capabilities?
Jared Zebedee
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
Re: Logging with the muse framework
Posted by Bogdan Solomon <bs...@ncct.uottawa.ca>.
>From looking a bit at the Muse source code, it seems that you would need to
modify the Muse libraries.
In muse-core, under org.apache.muse.core.descriptor.LoggingConfig you would
need to modify newInstance() to add whatever handler you want.
david.brossard wrote:
>
> Hi,
>
> I'd like to customize the way a Muse web service is logging information.
> I found the following so far:
>
> - Muse uses the JDK logging API
> quote (from
> http://ws.apache.org/muse/docs/2.2.0/manual/architecture/deployment-desc
> riptor.html):
> ________________________________
> Logging is done with the JDK logging API. The two elements under
> <logging/> - <log-file/> and <log-level/> - allow you to specify where
> the Muse log file will be written and at what level of detail it should
> record, respectively.
>
> The log file path should be relative to the application's
> working directory; in the case of the J2EE, this is the root of the WAR.
> The sample project will create a log file at
> /WEB-INF/services/muse/log/muse.log. The file will be overwritten each
> time the application is restarted.
> ________________________________
>
>
> - Java Logging can be extended with new handlers
> quote (from
> http://java.sun.com/j2se/1.5.0/docs/guide/logging/overview.html#1.5):
> ________________________________
> J2SE provides the following Handlers:
>
> * StreamHandler: A simple handler for writing formatted records
> to an OutputStream.
> * ConsoleHandler: A simple handler for writing formatted records
> to System.err
> * FileHandler: A handler that writes formatted log records
> either to a single file, or to a set of rotating log files.
> * SocketHandler: A handler that writes formatted log records to
> remote TCP ports.
> * MemoryHandler: A handler that buffers log records in memory.
>
> It is fairly straightforward to develop new Handlers. Developers
> requiring specific functionality can either develop a Handler from
> scratch or subclass one of the provided Handlers.
> ________________________________
>
>
> Obviously one needs to write a configuration file:
> quote(from
> http://java.sun.com/j2se/1.5.0/docs/guide/logging/overview.html#1.8):
> ________________________________
> The logging configuration can be initialized using a logging
> configuration file that will be read at startup. This logging
> configuration file is in standard java.util.Properties format.
> ________________________________
>
> But my understanding is that the muse framework programmatically
> configures the logging framework based on the values read from the
> muse.xml which are a file name and logging level which hints at saying
> there is only one possible logging destination: a file. In that case,
> there is no way one can use a custom handler, is there? Let alone use a
> pre-existing one.
>
> Does anyone have an idea? What would be the behavior if I did put in a
> java logging config file? I suppose that the assumed programatic
> configuration would take precedence on the one from the file effectively
> cancelling out the latter's effect.
>
> Thanks, David.
>
>
> David Brossard
> Security Research Professional
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Capability-URIs-and-Resource-Property-Namespaces-tf4349601.html#a12394933
Sent from the Muse User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
Logging with the muse framework
Posted by da...@bt.com.
Hi,
I'd like to customize the way a Muse web service is logging information.
I found the following so far:
- Muse uses the JDK logging API
quote (from
http://ws.apache.org/muse/docs/2.2.0/manual/architecture/deployment-desc
riptor.html):
________________________________
Logging is done with the JDK logging API. The two elements under
<logging/> - <log-file/> and <log-level/> - allow you to specify where
the Muse log file will be written and at what level of detail it should
record, respectively.
The log file path should be relative to the application's
working directory; in the case of the J2EE, this is the root of the WAR.
The sample project will create a log file at
/WEB-INF/services/muse/log/muse.log. The file will be overwritten each
time the application is restarted.
________________________________
- Java Logging can be extended with new handlers
quote (from
http://java.sun.com/j2se/1.5.0/docs/guide/logging/overview.html#1.5):
________________________________
J2SE provides the following Handlers:
* StreamHandler: A simple handler for writing formatted records
to an OutputStream.
* ConsoleHandler: A simple handler for writing formatted records
to System.err
* FileHandler: A handler that writes formatted log records
either to a single file, or to a set of rotating log files.
* SocketHandler: A handler that writes formatted log records to
remote TCP ports.
* MemoryHandler: A handler that buffers log records in memory.
It is fairly straightforward to develop new Handlers. Developers
requiring specific functionality can either develop a Handler from
scratch or subclass one of the provided Handlers.
________________________________
Obviously one needs to write a configuration file:
quote(from
http://java.sun.com/j2se/1.5.0/docs/guide/logging/overview.html#1.8):
________________________________
The logging configuration can be initialized using a logging
configuration file that will be read at startup. This logging
configuration file is in standard java.util.Properties format.
________________________________
But my understanding is that the muse framework programmatically
configures the logging framework based on the values read from the
muse.xml which are a file name and logging level which hints at saying
there is only one possible logging destination: a file. In that case,
there is no way one can use a custom handler, is there? Let alone use a
pre-existing one.
Does anyone have an idea? What would be the behavior if I did put in a
java logging config file? I suppose that the assumed programatic
configuration would take precedence on the one from the file effectively
cancelling out the latter's effect.
Thanks, David.
David Brossard
Security Research Professional
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
RE: Capability URIs and Resource Property Namespaces
Posted by Daniel Jemiolo <da...@us.ibm.com>.
You'll also need to modify the URI in the WSDL and the generated Java
interface. Just do a search and replace for the URI on the files in the
project.
Dan
"Jared A. Zebedee" <ze...@cs.queensu.ca> wrote on 08/29/2007 03:57:26 PM:
> Dan,
>
> Ah, thank you, I understand.
>
> Is it permissible to modify the Capability URIs in muse.xml after code
> generation? I assume it won't cause any adverse affects?
>
> Thanks
>
> Jared
>
> -----Original Message-----
> From: Daniel Jemiolo [mailto:danjemiolo@us.ibm.com]
> Sent: Wednesday, August 29, 2007 3:07 PM
> To: muse-user@ws.apache.org
> Subject: Re: Capability URIs and Resource Property Namespaces
>
>
> I explained the convention in another reply, but to answer your question
on
> standards-compliance: Muse uses the proper namespace URIs for standard
> properties and the proper capability URIs for standard capabilities; only
> custom capabilities are subject to our convention, because those are the
> ones we need to generate code for.
>
> Dan
>
>
>
> "Jared A. Zebedee" <ze...@cs.queensu.ca> wrote on 08/29/2007 02:36:02
PM:
>
> > I have built a Manageable Resource which includes custom Capabilities.
> >
> > It appears that Muse interprets each Resource Property Schema
referenced
> in
> > the WSDL as a Capability. Each Capability is assigned a URI that
matches
> > the namespace of the corresponding Resource Property Schema.
> >
> > In the WSDM specification, Capability URIs are not the same as Resource
> > Property namespaces:
> >
> > For example, the 'ResourceID' Resource Property is part of the
'Identity'
> > Capability.
> >
> > The 'Identity' Capability's URI is:
> > http://docs.oasis-open.org/wsdm/muws/capabilities/Identity
> >
> > The 'ResourceID' Property's Namespace is:
> > http://docs.oasis-open.org/wsdm/muws1-2.xsd
> >
> > But for each of my custom Capabilities, the Capability URI is the same
as
> > the Namespace URI of all the Properties that are part of the
Capability.
> I
> > personally like the idea of them being the same, but I'm not sure if
this
> is
> > allowable by the Standard. Am I doing something wrong, or is this how
> Muse
> > is designed to deal with Capabilities?
> >
> > Jared Zebedee
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: muse-user-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
RE: Capability URIs and Resource Property Namespaces
Posted by "Jared A. Zebedee" <ze...@cs.queensu.ca>.
Dan,
Ah, thank you, I understand.
Is it permissible to modify the Capability URIs in muse.xml after code
generation? I assume it won't cause any adverse affects?
Thanks
Jared
-----Original Message-----
From: Daniel Jemiolo [mailto:danjemiolo@us.ibm.com]
Sent: Wednesday, August 29, 2007 3:07 PM
To: muse-user@ws.apache.org
Subject: Re: Capability URIs and Resource Property Namespaces
I explained the convention in another reply, but to answer your question on
standards-compliance: Muse uses the proper namespace URIs for standard
properties and the proper capability URIs for standard capabilities; only
custom capabilities are subject to our convention, because those are the
ones we need to generate code for.
Dan
"Jared A. Zebedee" <ze...@cs.queensu.ca> wrote on 08/29/2007 02:36:02 PM:
> I have built a Manageable Resource which includes custom Capabilities.
>
> It appears that Muse interprets each Resource Property Schema referenced
in
> the WSDL as a Capability. Each Capability is assigned a URI that matches
> the namespace of the corresponding Resource Property Schema.
>
> In the WSDM specification, Capability URIs are not the same as Resource
> Property namespaces:
>
> For example, the 'ResourceID' Resource Property is part of the 'Identity'
> Capability.
>
> The 'Identity' Capability's URI is:
> http://docs.oasis-open.org/wsdm/muws/capabilities/Identity
>
> The 'ResourceID' Property's Namespace is:
> http://docs.oasis-open.org/wsdm/muws1-2.xsd
>
> But for each of my custom Capabilities, the Capability URI is the same as
> the Namespace URI of all the Properties that are part of the Capability.
I
> personally like the idea of them being the same, but I'm not sure if this
is
> allowable by the Standard. Am I doing something wrong, or is this how
Muse
> is designed to deal with Capabilities?
>
> Jared Zebedee
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
Re: Capability URIs and Resource Property Namespaces
Posted by Daniel Jemiolo <da...@us.ibm.com>.
I explained the convention in another reply, but to answer your question on
standards-compliance: Muse uses the proper namespace URIs for standard
properties and the proper capability URIs for standard capabilities; only
custom capabilities are subject to our convention, because those are the
ones we need to generate code for.
Dan
"Jared A. Zebedee" <ze...@cs.queensu.ca> wrote on 08/29/2007 02:36:02 PM:
> I have built a Manageable Resource which includes custom Capabilities.
>
> It appears that Muse interprets each Resource Property Schema referenced
in
> the WSDL as a Capability. Each Capability is assigned a URI that matches
> the namespace of the corresponding Resource Property Schema.
>
> In the WSDM specification, Capability URIs are not the same as Resource
> Property namespaces:
>
> For example, the 'ResourceID' Resource Property is part of the 'Identity'
> Capability.
>
> The 'Identity' Capability's URI is:
> http://docs.oasis-open.org/wsdm/muws/capabilities/Identity
>
> The 'ResourceID' Property's Namespace is:
> http://docs.oasis-open.org/wsdm/muws1-2.xsd
>
> But for each of my custom Capabilities, the Capability URI is the same as
> the Namespace URI of all the Properties that are part of the Capability.
I
> personally like the idea of them being the same, but I'm not sure if this
is
> allowable by the Standard. Am I doing something wrong, or is this how
Muse
> is designed to deal with Capabilities?
>
> Jared Zebedee
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>