[WISEMAN-172] wsman requests failing with jre 1.7, but used to work correctly with jre 1.6 Created: 06/Mar/13  Updated: 06/Mar/13

Status: Open
Project: wiseman
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: sathya_kas Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

In jre 1.7, I'm seeing problem when making a wsman request. Same code works fine with jre 1.6



 Description   

Here is the soap messages with jre 1.6 (working case) and jre 1.7 (not working case). My code is same for both cases. (so I dont think there is any problem with my code). The only message I see when it fails is : java.net.MalformedURLException: no protocol:

Here are the request messages :
jre 1.6, working case :
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
xmlns:mdo="http://schemas.wiseman.dev.java.net/metadata/messagetypes"
xmlns:mex="http://schemas.xmlsoap.org/ws/2004/09/mex"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns:wse="http://schemas.xmlsoap.org/ws/2004/08/eventing"
xmlns:wsen="http://schemas.xmlsoap.org/ws/2004/09/enumeration"
xmlns:wsman="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd"
xmlns:wsmeta="http://schemas.dmtf.org/wbem/wsman/1/wsman/version1.0.0.a/default-addressing-model.xsd"
xmlns:wxf="http://schemas.xmlsoap.org/ws/2004/09/transfer" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<env:Header>
<wsa:Action env:mustUnderstand="true" xmlns:ns11="http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd">http://schemas.xmlsoap.org/ws/2004/09/transfer/Get</wsa:Action>
<wsa:ReplyTo xmlns:ns11="http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd">
<wsa:Address env:mustUnderstand="true">http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
</wsa:ReplyTo>
<wsa:MessageID env:mustUnderstand="true" xmlns:ns11="http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd">uuid:05029cc2-0a2f-4d86-9d6e-45215db8cba0</wsa:MessageID>
<wsa:To env:mustUnderstand="true" xmlns:ns11="http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd">https://16.125.30.46:443/wsman</wsa:To>
<wsman:ResourceURI xmlns:ns11="http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd">http://www.hp.com/servers/oa/partitions/</wsman:ResourceURI>
<wsman:OperationTimeout xmlns:ns11="http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd">PT1M0.000S</wsman:OperationTimeout>
</env:Header>
<env:Body>
<empty/>
</env:Body>
</env:Envelope>

jre 1.7, failing case :
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
xmlns:mdo="http://schemas.wiseman.dev.java.net/metadata/messagetypes"
xmlns:mex="http://schemas.xmlsoap.org/ws/2004/09/mex"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns:wse="http://schemas.xmlsoap.org/ws/2004/08/eventing"
xmlns:wsen="http://schemas.xmlsoap.org/ws/2004/09/enumeration"
xmlns:wsman="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd"
xmlns:wsmeta="http://schemas.dmtf.org/wbem/wsman/1/wsman/version1.0.0.a/default-addressing-model.xsd"
xmlns:wxf="http://schemas.xmlsoap.org/ws/2004/09/transfer" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<env:Header>
<wsa:Action env:mustUnderstand="true" xmlns:ns11="http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd"/>
<wsa:ReplyTo xmlns:ns11="http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd"/>
<wsa:MessageID env:mustUnderstand="true" xmlns:ns11="http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd"/>
<wsa:To env:mustUnderstand="true" xmlns:ns11="http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd"/>
<wsman:ResourceURI xmlns:ns11="http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd"/>
<wsman:OperationTimeout xmlns:ns11="http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd"/>
</env:Header>
<env:Body>
<empty/>
</env:Body>
</env:Envelope>

While debugging, I see that even though the code is trying to populate the ResourceURI, timeout fields etc, these fields do not have any value when I capture the entire request flowing from the client. As I already said, my source code is the same for both cases. But only with jre 1.7, the use case is failing.






[WISEMAN-171] Subscribe response soap invalide wse:Identifier Created: 02/Apr/10  Updated: 02/Apr/10

Status: Open
Project: wiseman
Component/s: eventing
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Blocker
Reporter: mrunnals Assignee: wiseman-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 171

 Description   

The WsEventingSupport class is missing addition of the UUID_SCHEME (e.g.
"urn:uuid") prefix to the GUID used in the subscribe response. This results in
an invalid WS-Eveting Identifier in the WS-Addressing ReferenceParameters.

Line 579 of WsEventingSupport.java is:
identifier.setTextContent(context.toString());
And should be:
identifier.setTextContent(UUID_SCHEME+context.toString());

Line 669:
final UUID uuid = UUID.fromString(identifier);
may need to be update to handle the "urn:uuid" prefix.






[WISEMAN-170] Client transport should be configurable per resource factory Created: 11/Mar/10  Updated: 11/Mar/10

Status: Open
Project: wiseman
Component/s: client
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: sjones4 Assignee: wiseman-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File wiseman.patch    
Issuezilla Id: 170

 Description   

This is related to issue 133 but generalized to any transport mechanism and
extended to allow use of the API against multiple services concurrently.

The client API currently has a static ResourceFactory which is limiting if you
want to use the API against multiple services (it seems like transport /
authentication settings should be factory scoped, though this may be a
misunderstanding on my part).

The current HTTP client sets the JDK global defaults for the Authenticator and
the SSLSocketFactory which may be too restrictive for some usages.

There is currently no way to add in functionality such as including the SOAP 1.2
action parameter in the Content-Type header.



 Comments   
Comment by sjones4 [ 11/Mar/10 ]

Created an attachment (id=23)
Patch against wiseman_1_0_final

Comment by sjones4 [ 11/Mar/10 ]

The patch adds a new TransportClient interface and alters ResourceFactory so
that it is no longer static.

To use the ResourceFactory you now need to create an instance
"ResourceFactory.newInstance()". The ResourceFactory now has static properties
for the default XmlBinding and TransportClient, but these properties can also be
customized on a ResourceFactory instance.

A default implementation of TransportClient is provided
(DefaultHTTPTransportClient) that delegates to the existing HttpClient class. An
alternative ConfigurableHTTPTransportClient is provided to permit customization
of HTTP settings without modifying the JDK defaults. This class also permits
customization of the content-type header and preemptive HTTP Basic
authentication (this relies on Sun specific classes for the base 64 encoding)





[WISEMAN-169] Product does not run with a war file on Weblogic Server Created: 19/Jun/09  Updated: 24/Jun/09

Status: Open
Project: wiseman
Component/s: management
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: bpbailey Assignee: denis_rachal
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: x86


Issuezilla Id: 169

 Description   

Wiseman throws an NPE on Weblogic Server upon first access. The offending code
is in com.sun.ws.management.server.servlet.WSManServlet, in methods getFilenames
() and getQueryFilename().

More specifically, the problem is in the use of the Java Servlet API method
ServletContext.getRealPath() which, per the Javadoc, is allowed to return Null
if the servlet container does not resolve resource locations to paths on disk.
This method always returns Null on Weblogic.

Here is a potential solution that works on both Weblogic and Tomcat.

Original getFilenames() method:

private List<String> getFilenames(ServletContext context, String path) {
final List<String> xsdFilenames = new ArrayList<String>();

final Set<String> xsdLocSet = context.getResourcePaths(path);

if ((xsdLocSet == null) || (xsdLocSet.size() == 0))
return xsdFilenames;

final List<String> xsdLocList = new ArrayList<String>(xsdLocSet);
final Iterator<String> xsdLocIterator = xsdLocList.iterator();

// find the files and add them to the list
// make a recursive call for directories
for (int i = 0; xsdLocIterator.hasNext(); i++) {
String xsdLoc = xsdLocIterator.next();
final File f = new File(context.getRealPath(xsdLoc));
if (f.isFile())

{ xsdFilenames.add(xsdLoc); }

else

{ if (xsdLoc.charAt(xsdLoc.length() - 1) == '/') xsdLoc = xsdLoc.substring(0, xsdLoc.length() - 1); List<String> subList = getFilenames(context, xsdLoc); xsdFilenames.addAll(subList); }

}
return xsdFilenames;
}

Replacement:

private List<String> getFilenames(ServletContext context, String path) {
final List<String> xsdFilenames = new ArrayList<String>();
final Set<String> xsdLocSet = context.getResourcePaths(path);

if ((xsdLocSet == null) || (xsdLocSet.size() == 0))
return xsdFilenames;

final List<String> xsdLocList = new ArrayList<String>(xsdLocSet);
final Iterator<String> xsdLocIterator = xsdLocList.iterator();

// find the files and add them to the list
// make a recursive call for directories
for (int i = 0; xsdLocIterator.hasNext(); i++) {
String xsdLoc = xsdLocIterator.next();
try {
URL url = context.getResource(xsdLoc);
URI uri = url.toURI();
final File f = new File(uri);
if (f.isFile())

{ xsdFilenames.add(xsdLoc); }

else

{ if (xsdLoc.charAt(xsdLoc.length() - 1) == '/') xsdLoc = xsdLoc.substring(0, xsdLoc.length() - 1); List<String> subList = getFilenames(context, xsdLoc); xsdFilenames.addAll(subList); }

} catch (Exception e)

{ LOG.log(Level.SEVERE, "Error resolving schemas", e); }

}
return xsdFilenames;
}

And in getQueryFilename(), there is code that reads:

final File f = new File(getServletContext().getRealPath(name));
if (f.canRead() == true) { ...

Replace it with:

File f = null;
try {
URL url = getServletContext().getResource(name);
URI uri = url.toURI();
f = new File(uri);
} catch (MalformedURLException e) {
} catch (URISyntaxException e) {
}
if (f != null && f.canRead() == true) { ...



 Comments   
Comment by denis_rachal [ 24/Jun/09 ]

Taking ownership.





[WISEMAN-168] Request to add episode file to jarfile Created: 05/Jun/09  Updated: 05/Jun/09

Status: Open
Project: wiseman
Component/s: jaxws-deployment
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: denis_rachal Assignee: denis_rachal
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 168

 Description   

We have the problem that XJC generates sources for schemas that are
already existing in other JARs (in this case: wiseman.jar)

XJC therefore has the feature to not generate schemas that are already
included in other files. For this to work these JAR files must contain
the file META-INF/sun-jaxb.episode. Unfortunately the wiseman.jar does
not contain this file.

Please see https://maven-jaxb2-plugin.dev.java.net/docs/guide.html
under the headline "Separate schema compilation" for more information.

The inclusion of this file in wiseman would make the life for
developers much easier.






[WISEMAN-166] Add Wiseman published jarfiles to the java.net Maven2 respository Created: 04/Nov/08  Updated: 04/Nov/08

Status: Open
Project: wiseman
Component/s: Tooling
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Task Priority: Blocker
Reporter: denis_rachal Assignee: denis_rachal
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 166

 Description   

Add Wiseman published jarfiles to the java.net Maven2 respository:

https://maven2-repository.dev.java.net/






[WISEMAN-165] ManagementUtility.getAsResourceState undoc'd/unthrown Exception Created: 30/Sep/08  Updated: 30/Sep/08

Status: Open
Project: wiseman
Component/s: management
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Improvement Priority: Minor
Reporter: remmy412 Assignee: wiseman-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows
Platform: All


Issuezilla Id: 165

 Description   

ManagementUtility.getAsResourceState(Addressing response) declares throwing an
Exception even though Exception is never thrown by the method. The Exception is
also undocumented and it is not clear why Exception would be thrown. This places
a burden on the user of the API to try and figure out why Exception is being
thrown and how to recover from it. The throws should be removed or documented.






[WISEMAN-163] A problem of Subscription Created: 09/Sep/08  Updated: 21/Sep/08

Status: Open
Project: wiseman
Component/s: eventing
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: steve9522 Assignee: jfdenise
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File A problem of Subscription.ppt     Text File Analysis_of_J.F.Denise_idea.ppt    
Issuezilla Id: 163

 Description   

Hi Dear jfdenise:
We use the Wiseman to manage the resources of our system. The problem is as
following:
When we subscribe to a resource and get the Events in the Event Sink,
Sometimes we need to unsubscribe the subscription and then subscribe again. For
example ,the Event Sink is down and can not receive the Events. Then the
subscription end automatically or we unsubscribe the subscription manually,
restart the Event Sink and subscribe to the resource again so that we can
continue to receive the Events. However, the Events happen during the periods
between the "Subscription-end" and the "subscribe-again" are lost.
How Can we receive the "Lost Events" ?
Can you please tell me how to solve this problem?
More details see in the attachment:A problem of Subscription.ppt
I am looking forward to your reply.

Best Regards!

steve.JL
2008/09/09



 Comments   
Comment by jfdenise [ 09/Sep/08 ]

Hello,
I was not able to find your attachment.
Not sure that it is related to Wiseman. Wiseman doesn't offer a reliable Event
channel. You could build your own reliable channel using WiseMan.

I would say that you need to persist in some way the emitted events during the
End-Again period.
To achieve such feature you could :
1- Construct a new resource (named R1) that subscribes to the current resource
that emits notifications.
2- When R1 receives a Notification, it put it in a FIFO list.
3- Your event Sink subscribes to R1.
4- R1 lookup the list of received events and push to the sink all the received
notifications.
5- R1 then keeps track of the latest emitted notification for your EventSink
(based on the NotifyTo header). It does this to avoid to re-emit already emitted
notifications.
6- Your event Sink unsubscribe from R1. This is the start of the disconnected
period.
6bis- Or, your event sink is down and Notification delivery fails. The event is
not considered to have been delivered.
7- R1 continue to store received events.
8- Your event sink is back and subscribes again. This is the end of the
disconnected period.
8bis- Or your event sink is online again and can receive again notifications.
9- You are then back to step 4

Following this procedure you shouldn't loose event.
Let me know if this approach could solve your problem.

Jean-Francois

Comment by cxiao [ 10/Sep/08 ]

The target of Denise's idea is that the emited events are not lost during the
End-Again period.
But can the normal operations of one operator be supported if this idea is
adopted to solve its original issue?
We consider this idea in detail and find one problem.
In addition, this idea seems a bit complex.
The detail information is presented in the attachment.
Welcome any different opinions.

Comment by cxiao [ 10/Sep/08 ]

Created an attachment (id=21)
one attachment (Analysis of J.F.Denise's idea)

Comment by denis_rachal [ 10/Sep/08 ]

Hello Steve,

The official solution is outlined in the WS Management specification. See
chapter 10, Bookmarks. It states "Reliable delivery of events is difficult to
achieve, so management subscribers need to have a way to be certain of
receiving all events from a source...". Mode details are described in the
specification.

Bookmarks are not yet supported by Wiseman. If you need such a feature and wish
to implement this functionality, I would suggest you read this section of the
specification and attempt to use the Bookmark method. If you have any questions
or need any clarification of the specification, please do not hesitate to ask.

We would, of course, be interested in any success you have in getting Bookmarks
to work.

The latest copy of the specification can be found here:

http://www.dmtf.org/standards/published_documents/DSP0226_1.0.0.pdf

See section 10.2.6.

Regards,

Denis Rachal

Comment by steve9522 [ 11/Sep/08 ]

Created an attachment (id=22)
A problem of Subscription.ppt

Comment by cxiao [ 11/Sep/08 ]

Hello Denis,

Nice to see you again.

The Bookmark, we think, can not solve the issue posted by Steve.

One event first is emitted by event source, then it is delivered to event
source. Before its delivery, the event is marked with one bookmark.

For example, the bookmark is adopted,
the event source emitted some events,
E-1, ..., E-98, E-99, E-100,
The number indicates the bookmark of an event.
we suppose events from 1 to 99 (i.e. from E-1 to E-99) are delivered
successfully.
When E-100 is being sent, the network broke,
then the subscription at event source is terminated abnormally.
At the same time the E-100 and its bookmark(i.e.100) is logged at event source
side, (as WS-Man spec says, the log may be kept for short-term or long-term),
and the event sink(i.e. client) records the last bookmark 100.

During the subscription is canceled, some events (for example E-a and E-b) may
occur. Because the subscription had been terminated, these events are lost.

Only after the event sink (i.e. client) re-subscribes successfully the same
subscription with bookmark=100 which had been recorded, the events newly-
emitted by event source will be marked from 101 which is 1 pluses the logged
100. For example, E-101, E-102, E-103, ...
Then the event sink(i.e. client) will receive the following events in order: E-
100, E-101, E-102,...

After analyzing, we reach the conclusion that the bookmark can solve the
repeatation and omittance of events delivery, but the loss of events at event
source side caused by abnormal termination of one subscription can not be
solved by the bookmark.

Do you agree ?

Comment by denis_rachal [ 11/Sep/08 ]

Hello Cxiao,

I disagree with the analysis . I read the chapter again and will try to
point out how I believe it works.

1. Sink subscribes and requests bookmarks.
2. Source starts sending events (and logging bookmarks). Each send contains a
bookmark. As you describe E-1, ..., E-98, E-99, E-100 ...
3. Sink receives and acknowledges each delivery.
4. Between delivery of E100 & E101 the connection is broken.
5. E101 cannot be delivered and the subscription is cancelled by the source.
6. Events E101, E102, ... occur.
7. Sink re-subscribes and specifies the last known bookmark E-100.
8. Source starts delivering events to sink beginning with event E101. No events
are lost.

A variation on the above:

1-7. As stated above.
8. Source detects that the bookmark is no longer valid.
9. Source faults with "Expired".
10. Sink detects lost events.
11. Sink re-subscribes and specifies bookmark:
http://schemas.dmtf.org/wbem/wsman/1/wsman/bookmark/earliest
Subscription is renewed and the event source replays all possible events
that match the filter and any events that subsequently occur for that event
source. The absence of any bookmark means "begin at the next available event".

While the second scenario does have lost events, the sink can detect the lost
events. The source cannot be expected to maintain a bookmark log for infinity,
but it is expected to be a reasonable log. At the very least it should allow
for short network disconnections.

The first scenario does not lose any events.

Can you see my point?

Denis

Comment by cxiao [ 12/Sep/08 ]

Hello Denis,

Let's discuss the step 5, 6, 7.
You said:
5. E101 cannot be delivered and the subscription is cancelled by the source.
6. Events E101, E102, ... occur.
7. Sink re-subscribes and specifies the last known bookmark E-100.

Do you mean the events keep occuring and are persisted even if the subscription
has been cancelled because the client may

subscribe it again later?
Do you mean one subscription is not really cancelled or terminated?
If so, what will happen if the client dose not re-subscribe any more after the
subscription was 'cancelled'?
One obvious result is that this will lead to unnecessary consumption of memory
and CPU.

Another question, how does the client really terminate one subscription if the
client will not subscribe it any more?

As we know, one subscription can be terminated in one of the following cases
even if this subscription has been subscribed

with bookmark option:
case 1. the client sends one Unsubscribe request
case 2. the subscription expires
case 3. One event delivered fails to be acknowledged

Usually we can say that
case 3 will often lead to subscribe again, and
case 2 will be possible to lead to subscribe again, and
case 1 will be hardly to lead to subscribe again.
However, we can not exclude, for any case, the possibility that the client will
never subscribe it again.

The event source is, of course, aware of the current case.

When the current case is case 1, i.e. the client sends one Unsubscribe request
to cancel one subscription,
the subscription is really deleted from subscriptionMgr, so no new events is
emitted from event source.
But the filter and the last bookmark are logged for a long-term or short-term.

When the current case is case 2, i.e. one subscription is cancelled because it
expires,
the subscription is really deleted from subscriptionMgr, so no new events is
emitted from event source.
But the filter and the last bookmark are logged for a long-term or short-term.

When the current case is case 3, i.e. one event can not be sent to event sink,
the subscription is terminated (not deleted from subscriptionMgr), and new
events are emitted from event source and are

persisted.
Likewise, the filter and the last bookmark are logged for a long-term or short-
term.
When the subscription expires, it will be implicitly deleted from
subscriptionMgr and all related events are also deleted.

Because the WS-Management dose not explicitly say whether events keep occuring
or not during one subscription is cancelled,
the 3 ways are the different implemenations to solve different cases.
The most important is that they are WS-Management compliant.

In this way we can avoid the unnecessary consumption of memory and CPU.
But the loss of events during one subscription is really deleted are not solved
yet.
One better solution is required to propose.

Comment by steve9522 [ 12/Sep/08 ]

Hello, jfdenise,cxiao,Denis Rachal, all:
First, I appreciate jfdenise's idea very much. It seems useful for us to
solve the "lost" problem.
However, I think it is a little complicated and I am afraid that It might
cause some other troubles.
1-We have to create another R1 which might be memory-wasting twice as
before.
2-We have to subscribe twice and use a FIFO list so that might be time-
wasting .
3-We have to maintain the FIFO list so that might be hard to implement.
4-When The R1 should be deleted ? How can we know that?
Above is my confusion, anyway ,your idea is very helpful for our
consideration.
hmm,the discussion between cxiao and denis rachal is also professional.And
It seems like can solve the a kind of lost problem .But the Wiseman is not
support Bookmark yet...

Best Regards!
steve
2009.9.12

Comment by jfdenise [ 12/Sep/08 ]

Hello,
having a system that relies on event when such events are not delivered in a
reliable will lead to problem. If you are not planning to invest in a reliable
event channel, you should change your system a bit not to rely exclusively on
events.

For example, before to re-subscribe, the client could check a status (status
TBD) that contains the information of some exceptional state.

Another way could be to acknowledge at the Resource level. When something
abnormal occurs, the resource change its state and starts to emit regularly
events until the client explicitely change the state of the resource.
Doing so you the state of your system becomes reliable and not only the event
channel.

Comment by denis_rachal [ 14/Sep/08 ]

Hello Cxiao,

To answer your questions:

> Do you mean the events keep occuring and are persisted even if the
subscription
has been cancelled because the client may subscribe it again later?

Yes. Booknarks require the source to maintain a log of events even if the
subscription has been cancelled. It does not specify how big the log must be or
how long the events are persisted. That is up to the implementor.

> Do you mean one subscription is not really cancelled or terminated?

The subscription is cancelled. The log is independent from the subscription.
When you re-subscribe you specify from what bookmark to begin sending events.

> If so, what will happen if the client dose not re-subscribe any more after
the subscription was 'cancelled'?

The log can have a limit, both time and size. This is up to the source. I would
think that if Bookmarks are available the source always keeps a log of events,
for example of all events occuring in the last 15 minutes, up to 1 megabyte, or
at least start keeping the log after the first subscriber registers. The log is
not specific to a subscriber. It is for all events that occur at the source.
When re-subscribing a sink could change its filter and specify a bookmark. It
should get all events occuring since the bookmark (if it is not already gone
from the log) that match the new filter. The log must be maintained even if all
subscribers are cancelled.

> One obvious result is that this will lead to unnecessary consumption of
memory and CPU.

It is not "unnecessary". This provides a necessary service for the sink. This
is the functionality Steve is asking for, and that descibed in the WS Managment
specification.

> Another question, how does the client really terminate one subscription if
the client will not subscribe it any more?

The client simply un-subscribes. As I pointed out before the source must
maitain the log even if there are no subscribers. The log is for all events
emitted by the source, not just for one specific subscriber. There is just one
log, not one per subscriber. When you subscribe you have the option of starting
at a particular point in the log (if you have a valid bookmark).

Does this make it more clear. Try reading the section in the specification once
more.

Denis

Comment by cxiao [ 15/Sep/08 ]

Hello Denis,

We have some different opinions about the events log.

The WS-Management is the protocol between one resource instance and the
management software.
The WS-Management does not concern about the communication between the resource
instance and the physical resource.
One operator only subscribes to the resource instance.
For one resource instance there are two ways to get the events from one
physical resource:
way 1: polling the physical resource every a fix interval, such as every 3 ms.
way 2: subscribe to the physical resource which supports subscribe-publish
mechnism.

As you said, "The source must maitain the log even if there are no subscribers."
If so, the implementor can only adopt way 1 so that the events are emitted by
the source even if there are no subscribers.
Otherwise, if the implementor adopts way 2, there will not be emitted events
during one subscription is cancelled because the corresponding subscription to
the physical resource is deleted, which will lead to the loss of events.

So the kind of bookmark implementation which you specified can not solve this
problem.
Do you agree?

Chuan Xiao

Comment by denis_rachal [ 17/Sep/08 ]

Hello Cxiao,

> The WS-Management is the protocol between one resource instance and the >
management software.
> The WS-Management does not concern about the communication between the >
resource instance and the physical resource.
> One operator only subscribes to the resource instance.

I would not necessarily agree with all of the above.
First to quote the first statement of the specification:

"The Web Services for Management (WS-Management) Specification describes a
general Web services protocol based on SOAP for managing systems such as PCs,
servers, devices, Web services and other applications, and other manageable
entities."The WS-Management does not concern about the communication between
the resource instance and the physical resource."

I would not say that an operator "One operator only subscribes to the resource
instance".

A "sink" subscribes to "events", which are resource instances themselves, that
are emitted by a "managed resource" (3.15). The "event" is not necessarily
a "resource instance" that is described at the endpoint where the Subscription
was executed, for example:

The "traffic light" sample exposes "resource instances" of "resource class"
traffic light described in the XSD light.xsd. I could imagine someone
subscribing to "events" at this endpoint that notify a "sink" whenever a
trafiic light changes color. The event delivered to the sink is not constrained
to the "resource class". It can be of any "resource class".

I would say the protocol exposes "representations" of the state of a particular
resource, at any given point of time, in terms of a "resource class", defined
in 3.16 of the specification (see also 3.15 & 3.17). As you point out, "The WS-
Management does not concern about the communication between the resource
instance and the physical resource.". This point I would agree with.

Next you point out:

> For one resource instance there are two ways to get the events from one >
physical resource:
> way 1: polling the physical resource every a fix interval, such as > every 3
ms.
> way 2: subscribe to the physical resource which supports > subscribe-publish
mechnism.

It really does not matter how the "representation" of the physical resource is
updated. Let's just agree that it is updated. It also does not matter how the
software that monitors the physical resource detects a change in the "physical
resournce", or what we call an event of interest. Let's just say that an event
occurs at some point in time, the software monitoring the resource detects the
physical event, and creates an event "resource instance" of type "resource
class" to represent the event. This event is now represented in software as
a "resource instance". They can be archived and a WS could be created to
provide CRUD access to the events. They are "resource instances" in and of
themselves and have a lifecycle and "resource class" independent of
the "managed resource", its "resource class", or its "resource instance".

Let's consider your next points:

> As you said, "The source must maitain the log even if there are no >
subscribers."
> If so, the implementor can only adopt way 1 so that the events are > emitted
by the source even if there are no subscribers.
> Otherwise, if the implementor adopts way 2, there will not be emitted >
events during one subscription is cancelled because the corresponding >
subscription to the physical resource is deleted, which will lead to > the loss
of events.

This I disagree with. How the monitoring sofware/hardware detects a physical
event is totally independent from software subscriptions. Physical events
occur. Monitoring software/hardware is designed to detect those events and
create representations of them in the form of event "resource instances".
Event "resources instances" occur at some point in time and what the monitoring
software does with this "resource instance" is totally independant of whether
or not a WS has been created to expose these "resource instances". They can be
written to a log, discarded, added to a DB archive, etc...

With WS Management it is possible to expose these event "resource instances"
either as simply "resource instances" via CRUD (WS-Transfer) operations or
events (WS-Eventing) to subscribers. As WS Management event subscribers
consumers can receive them in real time through "push" subscription, or later
through "batch push" or "pull" mode. "pull" mode is, by the way, a form of a
log for the subscriber. It is just that the log is deleted if the subscription
expires.

> So the kind of bookmark implementation which you specified can not > solve
this problem.
> Do you agree?

No. I do not agree. The bookmark mechanism was specifically designed to solve
this problem. In the specification (10.2.6) it states:

"Reliable deilvery of events is difficult to achieve, so management subscribers
need a mechanism to have a way to be certain of receiving all events from a
source. When subscribptions expire or when deliveries fail, windows of time can
occur in which the client cannot be certain whether critical events have
occurred. Rather than using a highly complex, transacted delivery model, WS
Management defines a simple mechanism for ensuring that all events are
delivered or that dropped events can be detected."

This first paragraph clearly states that this feature exists for "ensuring that
all events are delivered or that dropped events can be detected". That is the
purpose of Bookmarking and it is designed to do that.

The source is responsible for maintaining a log of events in the order they
have been received. It is not mandated how large or how long the events must be
maintained in the log, but in order to implement bookmarking there must be some
sort of log kept. When a sink subscribes, the sink may specify a point in the
log from which to start receiving events, regardless of whether this sink was
ever subscribed at this source. Look at the XML example for the subscription
with bookmarks. Of course the sink must first get a valid bookmark, but that
could have been passed from another subscriber. There is nothing in the
subscription that mandates or says this subscriber has previously subscribed at
this source. In fact the specification states:

"If multiple new subscriptions are made using a previous bookmark, the service
can allow multiple reuse or may limit bookmarks to a single subscriber, and can
even restrict how long bookmarks can be used before becoming invalid."

The above would suggest that the source "could" keep a log per subscriber or a
single log for all subscribers. That is up to the implementation, but it is not
mandated by the specification.

If the source maintains a log per subscriber, it would need to periodically
clean up the stale logs. The bookmark itself whould need to somehow point to
the correct log in order to re-create the subscription and pick up where it
left off. I would not recommend this implementation as it would require keeping
multiple copies of the events, or reference counters on the events. This could
actually cost extra resources.

I would prefer to keep one log of a maximum size. Once the maximum size is
reached new events drop the oldest events and then add themselves. Each entry
contains an incremental bookmark. In this way a subscriber can easily pick up
where he left off, or detect that the event(s) missed have been dropped.

Hope this makes some sense. Please let me know.

Regards,

Denis Rachal

Comment by cxiao [ 18/Sep/08 ]

Hello Denis,

Thank you very much for your interpretation in detail.
We agree with you on the whole.
We draw the two conclusions from your comments:
(1) If the WS-Management supports bookmark, the source will log the events
regardless of whether one subscription exists or not. i.e. The events emitted
by source is independent from the existence of one subscription.
(2) The logs are delivered to the event sink when the subscription is
subscribed again with a valid bookmark or the subscription is subscribed at the
first time.

The following thoughts are based on the above two conclusions.
There are two states for one subscription in current WS-Management:
(a) null(or cancel)
(b) active

One operator can use WS-Eventing:Subscribe operation to transfer one
subscription from null state to active state, he also can use WS-
Eventing:Unsubscribe operation to transfer one subscription from active state
to null state.

The null state means one subscription does not exist, and event source emits
events but these events are not delivered to the event sink (because the
subscription does not exist).

The active state means events are delivered from the event source to the event
sink (because the subscription exists).

Are these thoughts identical to yours?

Best Regards.
Chuan Xiao

Comment by denis_rachal [ 21/Sep/08 ]

Hello Xiao,

Glad to hear that my last explanation helped you to understand WS Management
bookmarks better, and to answer your question:

> Are these thoughts identical to yours?

Yes, these are correct.

Regards,

Denis Rachal





[WISEMAN-164] Resource files are not generated as mentioned in the Wiseman Tutorial.pdf Created: 14/Sep/08  Updated: 14/Sep/08

Status: Open
Project: wiseman
Component/s: Tooling
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: vponnuru Assignee: denis_rachal
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 164

 Description   

I am trying to build the traffic_server example as explained in the tutorial. I
have followed the steps as described in the tutorial, I noticed
<resource>Handler.java and resources folder is missing after executing the “ant
generate� command.

Wiseman Tutorial.pdf
Page: 13
Notes:
To implement the WS-Transfer operations for the traffic light resource:
1 Using a text or Java editor, open WORK_DIR\gen-src\net\java\dev\wiseman\
resources\traffic_1\light\LightHandler.java.

Reply from Denis about issue,
I took a closer look at this and it seems that xsd2wsdl is generating code
differently that the documentation describes. I think it is a defect in the
generator, as it is not generating source for the requested resource
URI: “urn:resources.wiseman.dev.java.net/traffic/1/light�, but for resource
URI: “http://schemas.wiseman.dev.java.net/traffic/1/light.xsd/lightService/light
Resource�. Hence, the generated source are named differently and in another
directory. Can you file a defect for the problem?

Denis Rachal






[WISEMAN-162] Enumerate Pull MaxTime can not be removed Created: 27/Aug/08  Updated: 27/Aug/08

Status: Open
Project: wiseman
Component/s: enumeration
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: remmy412 Assignee: wiseman-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows
Platform: x64


Issuezilla Id: 162

 Description   

When creating an enumeration pull request using EnumerationMessageValues when no
MaxTime is specified a value of 30s is entered into the message by default.
MaxTime is not a required element and shouldn't be entered into the message by
default. At the least an API should be provided to remove it from the message.
Some elements are removed by passing -1 to the setter, but this doesn't work for
MaxTime.






[WISEMAN-161] Consideration on Persistence of WiseMan by InSTech Laboratory Created: 31/Mar/08  Updated: 31/Mar/08

Status: Open
Project: wiseman
Component/s: eventing
Affects Version/s: current
Fix Version/s: milestone 1

Type: New Feature Priority: Major
Reporter: cxiao Assignee: denis_rachal
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File ConsiderationOnPersistence.ppt    
Issuezilla Id: 161

 Description   

You can get more information from the attachment.



 Comments   
Comment by cxiao [ 31/Mar/08 ]

Created an attachment (id=20)
consideration on persistence of WiseMan





[WISEMAN-160] Persistency of subscription in Wiseman? Created: 29/Feb/08  Updated: 29/Feb/08

Status: Open
Project: wiseman
Component/s: eventing
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: yxxu Assignee: wiseman-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 160

 Description   

Hi,

Recently, I and some InSTech members are surveying on the subscription process
in Wiseman.
It seems that currently the subscription information is only stored in memory.
Is Wiseman going to include a persistency mechanism of subscriptions inside
itself, or is that already out of the function domain in Wiseman?

It will be happiness for me if I could recieve any comments and/or thoughts
from you. And I (and/or with some other member) would like to make some
contributions to it in the future if the necessity of the enhancement is
recognized and agreed in the community.

Yixuan.Xu
Fudan-Hitachi InSTech






[WISEMAN-157] Add two functions used in Batched Delivery mode Created: 16/Jan/08  Updated: 19/Feb/08

Status: Open
Project: wiseman
Component/s: eventing
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: cxiao Assignee: jfdenise
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 157

 Description   

In order to support the Batched Delivery mode of eventing,
We would like to add two static methods to
com.sun.ws.management.server.WSEventingBaseSupport .

Function 1:Create an empty notify message used in Batched Delivery mode.
public static Addressing createEmptyMessageBatched(
final EventingContextBatched ctx)

Function 2:Add one event to the notify message in Batched Delivery mode.
public static boolean addEventToMessageBatched(
final EventingContextBatched ctx,
final Addressing msg,
final Object content,
final String eventAction)

the detail code is below:
public static Addressing createEmptyMessageBatched(final
EventingContextBatched ctx)
throws SOAPException, JAXBException, IOException,
InvalidSubscriptionException {

final Addressing msg = new Addressing();
msg.setAction(Management.EVENTS_URI);

final EndpointReferenceType notifyTo = ctx.getNotifyTo();
msg.setTo(notifyTo.getAddress().getValue());
final ReferenceParametersType refparams =
notifyTo.getReferenceParameters();
if (refparams != null)

{ msg.addHeaders(refparams); }

final ReferencePropertiesType refprops = notifyTo.getReferenceProperties
();
if (refprops != null)

{ msg.addHeaders(refprops); }

msg.setMessageId(UUID_SCHEME + UUID.randomUUID().toString());

ObjectFactory FACTORY = new ObjectFactory();

final JAXBElement<EndpointReferenceType> element = FACTORY.createReplyTo
(ctx.getEventReplyTo());
msg.getXmlBinding().marshal(element, msg.getHeader());

org.dmtf.schemas.wbem.wsman._1.wsman.ObjectFactory factory = new
org.dmtf.schemas.wbem.wsman._1.wsman.ObjectFactory();
final AttributableDuration durationType =
factory.createAttributableDuration();
durationType.setValue(ctx.getOperationTimeout());
final JAXBElement<AttributableDuration> durationElement =
factory.createOperationTimeout(durationType);
msg.getXmlBinding().marshal(durationElement, msg.getHeader());

final QName ACK_Requested = new QName
(Management.NS_URI,ACKREQUESTED,Management.NS_PREFIX);
msg.getHeader().addChildElement(ACK_Requested);

return msg;
}

public static boolean addEventToMessageBatched(final EventingContextBatched
ctx, final Addressing msg, final Object content, final String eventAction)
throws SOAPException, JAXBException, IOException,
InvalidSubscriptionException {

String EVENT = "Event";
String EVENTS = "Events";
String ACTION= "Action";

final Document eventDoc = Management.newDocument();
final Element event = eventDoc.createElementNS
(Management.NS_URI, Management.NS_PREFIX + ":" + EVENT);
if (eventAction!=null) event.setAttribute(ACTION, eventAction);

if (ctx.getFilter() == null) {
if (content instanceof Node)
event.appendChild(eventDoc.importNode((Node)content, true));

else

{ msg.getXmlBinding().marshal(content, event); }

} else {
final Element item;

// Convert the content to an Element
if (content instanceof Element)

{ item = (Element) content; }

else if (content instanceof Document) {
item = ((Document) content).getDocumentElement();
// append the Element to the owner document
// if it has not been done
// this is critical for XPath filtering to work
final Document owner = item.getOwnerDocument();
if (owner.getDocumentElement() == null)

{ owner.appendChild(item); }

} else {
Document doc = Management.newDocument();
try

{ // TODO: Use a better binding... msg.getXmlBinding().marshal(content, doc); }

catch (Exception e)

{ removeContext(null, ctx); final String explanation = "XML Binding marshall failed for object of type: " + content.getClass().getName(); throw new InternalErrorFault(SOAP .createFaultDetail(explanation, null, e, null)); }

item = doc.getDocumentElement();
}
final NodeList filteredContent;
try

{ filteredContent = ctx.evaluate(item); }

catch (XPathException xpx)

{ removeContext(null, ctx); throw new CannotProcessFilterFault( "Error evaluating XPath: " + xpx.getMessage()); }

catch (Exception ex)

{ removeContext(null, ctx); throw new CannotProcessFilterFault( "Error evaluating Filter: " + ex.getMessage()); }

if ((filteredContent != null) && (filteredContent.getLength() > 0))
{
// Then send this instance
if (filteredContent.item(0).equals(item))

{ // Whole node was selected event.appendChild(item); }

else

{ // Fragment(s) selected final JAXBElement<MixedDataType> fragment = createXmlFragment(filteredContent); msg.getXmlBinding().marshal(fragment, event); }

} else

{ return false; }

}

NodeList eventsList = msg.getBody().getElementsByTagName
(Management.NS_PREFIX + ":" + EVENTS);
if(eventsList.getLength()==0)

{ QName Events = new QName (Management.NS_URI,EVENTS,Management.NS_PREFIX); msg.getBody().addBodyElement(Events); eventsList = msg.getBody().getElementsByTagName (Management.NS_PREFIX + ":" + EVENTS); }

((Element)eventsList.item(0)).appendChild(((Element)eventsList.item
(0)).getOwnerDocument().importNode(event,true));

return true;
}



 Comments   
Comment by jfdenise [ 17/Jan/08 ]

Some feedbacks :
1) You need to use the WSEventingRequest, WSEventingResponse instead of Addressing.
2) Having a method to add a list of Events seems of interest. Adding 1 element
being similar to add a list of size == 1.

Comment by cxiao [ 17/Jan/08 ]

To feedback 1) You need to use the WSEventingRequest, WSEventingResponse
instead of Addressing.

I can not find the appropriate method in WSEventingRequest to add one Node to
Body of message. Could you give some hints?

To feedback 2) Having a method to add a list of Events seems of interest.
Adding 1 element being similar to add a list of size == 1.

The eventAction of Event may differ from one another.
if we use a list of Events as the parameter, the function signature looks like :

public static boolean addEventListToMessageBatched(
final EventingContextBatched ctx,
final WSEventingRequest msg,
final Object[] content,
final String[] eventAction)

Do you agree ?

Comment by jfdenise [ 17/Jan/08 ]

You should better define an Even tclass that contains 2 fields and provide a
List<WSManEvent>.
WSEventingResponse can be updated with the needed method. This API is the way to
take benefit of new features. Feel free to extend thsi interface wit hthe needed
methods.

Comment by cxiao [ 17/Jan/08 ]

As Jean-Fancois commented, we would like to define such two classes first:

public class WSEventMessage extends Addressing
implements WSEventingResponse,WSEventingResponse{

public WSEventMessage()

{ super(); }

//TODO : define other constructors for WSEventMessage.
}

public class WSManEvent {
private Object content;
private String eventAction;

public WSManEvent(Object content, String eventAction)

{ this.content = content; this.eventAction = eventAction; }

public Object getContent()

{ return content; }

public String getEventAction()

{ return eventAction; }

}

After the class WSEventMessage and class WSManEvent are defined,
we can add four static methods to
com.sun.ws.management.server.WSEventingBaseSupport .

Function 1:Create an empty notify message used in Batched Delivery mode.

public static WSEventMessage createEmptyMessageBatched(
final EventingContextBatched ctx)

Function 2:Add one Event to a given notify message in Batched Delivery mode.

public static boolean addEventToMessageBatched(
final EventingContextBatched ctx,
final WSEventMessage msg,
final WSManEvent)

Function 3: Add a list of Events to a given notify message in Batched Delivery
mode.

public static boolean addEventListToMessageBatched(
final EventingContextBatched ctx,
final WSEventMessage msg,
final List<WSManEvent> eventList)

Function 4: Create an notify message used in Batched Delivery mode by a list of
Events.

public static WSEventMessage createMessageBatched(
final EventingContextBatched ctx,
final List<WSManEvent> eventList)

What is your comment on these work?

Comment by cxiao [ 17/Jan/08 ]

Oh, there is one fault.
the class WSEventMessage should implement WSEventingRequest &
WSEventingResponse. Just like this:

public class WSEventMessage extends Addressing
implements WSEventingRequest,WSEventingResponse{

public WSEventMessage()

{ super(); }

//TODO : define other constructors for WSEventMessage.
}

Comment by cxiao [ 27/Jan/08 ]

We found there are some significant changes in the new version of code.
The class Addressing�Enumeration and Eventing will be abondoned in the future.

We think the WSEventingBatchedEventMessage can extend
com.sun.ws.management.Management.SAAJMessage.

public class WSEventingBatchedEventMessage extends SAAJMessage{

public WSEventingBatchedEventMessage(Management mgt)

{ super(mgt); }

}

Besides, In order to retrieve a EventingContextBatched to create a message,
we should add more methods to
com.sun.ws.management.server.WSEventingBaseSupport like this:

public static WSEventingBatchedEventMessage createMessageBatched(
final UUID id,
final List <WSManEvent > eventList) {

WSEventingBatchedEventMessage msg = null;

final BaseContext bctx = retrieveContext(id); // retrieveContext(UUID)
already existed in the WSEventingBaseSupport
if (bctx instanceof EventingContextBatched)

{ final EventingContextBatched ctxbatched = (EventingContextBatched) bctx; msg = createMessageBatched(ctxbatched , eventList); }

return msg;
}

So we would like to define such two classes first:

public class WSEventingBatchedEventMessage extends SAAJMessage

{ // As statements above }

public class WSManEvent {
private Object content;
private String eventAction;
public WSManEvent(Object content, String eventAction)

{ this.content = content; this.eventAction = eventAction; }

public Object getContent()

{ return content; }

public String getEventAction()

{ return eventAction; }

}

After the class WSEventingBatchedEventMessage and class WSManEvent are defined,
we can add eight static methods to
com.sun.ws.management.server.WSEventingBaseSupport .

Function 1-a:Create an empty notify message used in Batched Delivery mode.

public static WSEventingBatchedEventMessage createEmptyMessageBatched(
final EventingContextBatched ctx)

Function 1-b:Create an empty notify message used in Batched Delivery mode.

public static WSEventingBatchedEventMessage createEmptyMessageBatched(
final UUID id)

Function 2-a:Add one Event to a given notify message in Batched Delivery mode.

public static boolean addEventToMessageBatched(
final EventingContextBatched ctx,
final WSEventingBatchedEventMessage msg,
final WSManEvent)

Function 2-b:Add one Event to a given notify message in Batched Delivery mode.

public static boolean addEventToMessageBatched(
final UUID id,
final WSEventingBatchedEventMessage msg,
final WSManEvent)

Function 3-a: Add a list of Events to a given notify message in Batched
Delivery
mode.

public static boolean addEventListToMessageBatched(
final EventingContextBatched ctx,
final WSEventingBatchedEventMessage msg,
final List <WSManEvent > eventList)

Function 3-b: Add a list of Events to a given notify message in Batched
Delivery
mode.

public static boolean addEventListToMessageBatched(
final UUID id,
final WSEventingBatchedEventMessage msg,
final List <WSManEvent > eventList)

Function 4-a: Create an notify message used in Batched Delivery mode by a list
of
Events.

public static WSEventingBatchedEventMessage createMessageBatched(
final EventingContextBatched ctx,
final List <WSManEvent > eventList)

Function 4-b: Create an notify message used in Batched Delivery mode by a list
of
Events.

public static WSEventingBatchedEventMessage createMessageBatched(
final UUID id,
final EventingContextBatched ctx,
final List <WSManEvent > eventList)

What is your comments on our consideration?

Comment by jfdenise [ 28/Jan/08 ]

Xciao, I think that there is a little confusion between the Message interfaces
and classes.
In your proposal you are defining a new class that extends SAAJMessage.
SAAJMessage is a concrete implementation of WS-Management request based on SAAJ
API. The class JAXWSMessageRequest does the same thing but by using JAX-WS API.

You have the choice to use SAAJ or JAX-WS API. You can't impose to use one or
the other. Forget about SAAJMessage and start thinking in term of interface.

You should follow these steps:

  • Firstly you need to add to the interface WSEventingRequest the set of methods
    you need to compose your batched message (mainly add a list of event to it).
  • Secondly implement these newly added methods in the SAAJMessageRequest and
    JAXWSMessageRequest
  • Thirdly, use JAXWSMessageRequest class when implementing WSEventingSupport
    methods.
  • Finally, use SAAJMessageRequest class when implementing EventingSupport methods.

Does it helps you better understand how to add the Batched delivery?

Comment by cxiao [ 29/Jan/08 ]

Thanks for Jean-Francois' comments.
We first deal with Batched mode based on SAAJ API.
We need some time to master the JAXWS.

(1) define class WSManEvent.
package com.sun.ws.management.server;

public class WSManEvent {
private Object content;
private String eventAction;

public WSManEvent(Object content, String eventAction)

{ this.content = content; this.eventAction = eventAction; }

public Object getContent()

{ return content; }

public String getEventAction()

{ return eventAction; }

}

(2) add two methods to interface WSEventingRequest .

/* Batched Message */
public void setEventList(final EventingContextBatched ctx,final
List<WSManEvent> eventList) throws Exception;
public int getEventAmounts();

(3) add the following methods to class SAAJMessage.

public int getEventAmounts() ;

public void setEventList(EventingContextBatched ctx,
List<WSManEvent> eventList)
throws SOAPException, JAXBException,
IOException,InvalidSubscriptionException;

private boolean addWSEvent(
final EventingContextBatched ctx,
final WSManEvent wsEvent)
throws SOAPException, JAXBException, IOException,
InvalidSubscriptionException;

(4) add the following methods to class WSEventingBaseSupport.

public static WSEventingRequest createEventMessageBatched(
final UUID id,
final List<WSManEvent> eventList)
throws Exception;

public static WSEventingRequest createEventMessageBatched(
final EventingContextBatched ctx,
final List<WSManEvent> eventList)
throws SOAPException, JAXBException,
IOException,InvalidSubscriptionException;

The following is the detail code of methods above.
What is your comments on them?

------ The detail code of methods above in SAAJMessage.java --------------------
------

public int getEventAmounts()

{ NodeList eventsList = this.mgt.getBody().getElementsByTagName (Management.NS_PREFIX + ":" + EVENTS); if(eventsList.getLength()==0) return 0; else return eventsList.item(0).getChildNodes().getLength(); }

private boolean addEventElement(final Element event) throws
SOAPException{

NodeList eventsList = this.mgt.getBody().getElementsByTagName
(Management.NS_PREFIX + ":" + EVENTS);

if(eventsList.getLength()==0)

{ QName Events = new QName (Management.NS_URI,EVENTS,Management.NS_PREFIX); mgt.getBody().addBodyElement(Events); eventsList = mgt.getBody().getElementsByTagName (Management.NS_PREFIX + ":" + EVENTS); }

((Element)eventsList.item(0)).appendChild(((Element)eventsList.item
(0)).getOwnerDocument().importNode(event,true));
return true;
}

private boolean addWSEvent(
final EventingContextBatched ctx,
final WSManEvent wsEvent)
throws SOAPException, JAXBException, IOException,
InvalidSubscriptionException{

if(this.getEventAmounts()==ctx.getMaxElements()) return
false;
Object content = wsEvent.getContent();

String eventAction = wsEvent.getEventAction();

final Document eventDoc = Management.newDocument();
final Element event = eventDoc.createElementNS
(Management.NS_URI, Management.NS_PREFIX + ":" + EVENT);
if (wsEvent.getEventAction()!=null)
event.setAttribute(ACTION, eventAction);

if (ctx.getFilter() == null) {
if (content instanceof Node)
event.appendChild(eventDoc.importNode((Node)content,
true));
else

{ mgt.getXmlBinding().marshal(content, event); }

} else {
final Element item;
// Convert the content to an Element
if (content instanceof Element)

{ item = (Element) content; }

else if (content instanceof Document) {
item = ((Document) content).getDocumentElement();
// append the Element to the owner document
// if it has not been done
// this is critical for XPath filtering to work
final Document owner = item.getOwnerDocument();
if (owner.getDocumentElement() == null)

{ owner.appendChild(item); }

} else {
Document doc = Management.newDocument();
try

{ // TODO: Use a better binding... mgt.getXmlBinding().marshal(content, doc); }

catch (Exception e)

{ //removeContext(null, ctx); final String explanation = "XML Binding marshall failed for object of type: " + content.getClass().getName(); throw new InternalErrorFault(SOAP.createFaultDetail (explanation, null,e, null)); }

item = doc.getDocumentElement();
}

final NodeList filteredContent;
try

{ filteredContent = ctx.evaluate(item); }

catch (XPathException xpx)

{ //removeContext(null, ctx); throw new CannotProcessFilterFault("Error evaluating XPath: "+ xpx.getMessage()); }

catch (Exception ex)

{ //removeContext(null, ctx); throw new CannotProcessFilterFault("Error evaluating Filter: " + ex.getMessage()); }

if ((filteredContent != null) && (filteredContent.getLength()
> 0)) {
// Then send this instance
if (filteredContent.item(0).equals(item))

{ // Whole node was selected event.appendChild(item); }

else

{ // Fragment(s) selected final JAXBElement<MixedDataType> fragment = BaseSupport.createXmlFragment(filteredContent); mgt.getXmlBinding().marshal(fragment, event); }

} else

{ return false; }

}
return addEventElement(event);
}

public void setEventList(EventingContextBatched ctx,
List<WSManEvent> eventList)
throws SOAPException, JAXBException,
IOException,InvalidSubscriptionException{
// TODO Auto-generated method stub
if(this.getEventAmounts()+eventList.size()>ctx.getMaxElements())

{ throw new InvalidSubscriptionException("The event amount exceeds the MaxElements."); }

for (int i=0;i<eventList.size();i++)

{ this.addWSEvent(ctx,eventList.get(i)); }

}

-------The detail code of methods above in WSEventingBaseSupport.java ----------
-------------------

public static WSEventingRequest createEventMessageBatched(
final EventingContextBatched ctx,
final List<WSManEvent> eventList)
throws SOAPException, JAXBException,
IOException,InvalidSubscriptionException{

final Management mgmt = new Management();
mgmt.setAction(Management.EVENTS_URI);
mgmt.setMessageId(UUID_SCHEME + UUID.randomUUID().toString());
mgmt.setReplyTo(ctx.getEventReplyTo());
mgmt.setTimeout(ctx.getOperationTimeout());

final EventingExtensions evt = new EventingExtensions(mgmt);
evt.setAckRequested();

final EndpointReferenceType notifyTo = ctx.getNotifyTo();
mgmt.setTo(notifyTo.getAddress().getValue());
final ReferenceParametersType refparams =
notifyTo.getReferenceParameters();
if (refparams != null)

{ mgmt.addHeaders(refparams); }

final ReferencePropertiesType refprops = notifyTo.getReferenceProperties
();
if (refprops != null)

{ mgmt.addHeaders(refprops); }

SAAJMessage saajMsg = new SAAJMessage(mgmt);

saajMsg.setEventList(ctx,eventList);

return saajMsg;
}

public static WSEventingRequest createEventMessageBatched(
final UUID id,
final List<WSManEvent> eventList)
throws Exception{

WSEventingRequest wseReq = null;

final BaseContext bctx = retrieveContext(id);
if (bctx instanceof EventingContextBatched){
final EventingContextBatched ctxbatched =
(EventingContextBatched) bctx;
try

{ wseReq = createEventMessageBatched(ctxbatched , eventList); }

catch(Exception e)

{ removeContext(null, ctxbatched); throw e; }

}
return wseReq;
}

Comment by cxiao [ 31/Jan/08 ]

We found it is not necessary to add operations to WSEventingRequest.
Our objective is to add one static method to WSEventingBaseSupport.

public static WSEventingRequest createEventMessageBatched(
final UUID id,
final List<WSManEvent> eventList)

In the method we can
(1) construct Management object,
(2) put the eventList to the Management object (by calling one private method)
(3) wrap Management in SAAJMessage
(4) return SAAJMessage, i.e. WSEventingRequest

Why is the method added to WSEventingBaseSupport?
Because in WSEventingBaseSupport, there are similar methods like

public static Addressing createPushEventMessage(UUID id, Object content)
&
public static Addressing createEventMessagePushWithAck(...)

What is your comments on it?

Comment by cxiao [ 19/Feb/08 ]

Thank Denis very much for your work.
As you commented, we have designed one unit test
in class framework.WSEventingBaseSupportTest for function

public static Addressing createEventMessageBatched(
final EventingContextBatched ctx,
final EventsType events).

The detail unit code is below.

When we did the unit test, we found that the function
createEventMessageBatched(...) did not check the MaxElements constraint.
So we suggest to change the code fragment in createEventMessageBatched(...)
from

evtx.setAckRequested();
evtx.setBatchedEvents(events);
to
evtx.setAckRequested();
if (ctx.getMaxElements() < events.getEvent().size())

{ throw new UnsupportedFeatureFault (UnsupportedFeatureFault.Detail.MAX_ELEMENTS); }

evtx.setBatchedEvents(events);

-------Begin of the detail code of unit test -------------

import foo.test.Foo;
import javax.xml.datatype.DatatypeConfigurationException;

public static final String EVENTS = "Events";

public void testCreateEventMessageBatched()throws SOAPException,
DatatypeConfigurationException{

String ACTION
= "http://schemas.xmlsoap.org/2005/02/diskspacechange";
final String recvrAddress = "http://localhost:8080/events";
final EndpointReferenceType notifyTo = Addressing
.createEndpointReference(recvrAddress, null,
null, null, null);

final Addressing request = new Addressing();

final ReferencePropertiesType props = Addressing.FACTORY
.createReferencePropertiesType();
final Document tempDoc1 = request.newDocument();
final Element tempelement = tempDoc1.createElementNS(NS_URI,
NS_PREFIX
+ ":" + "tempelement");
tempelement.appendChild(tempDoc1.createTextNode("tempelement"));
tempDoc1.appendChild(tempelement);
props.getAny().add(tempDoc1.getDocumentElement());

final ReferenceParametersType params = Addressing.FACTORY
.createReferenceParametersType();
final Document refParametersDoc = request.newDocument();
final Element refParameters = refParametersDoc.createElementNS
(NS_URI,
NS_PREFIX + ":" + "refParameters");
refParameters.setAttributeNS(NS_URI, NS_PREFIX + ":" + "type",
"celsius");
refParametersDoc.appendChild(refParameters);
params.getAny().add(refParametersDoc.getDocumentElement());

final AttributedQName portType = Addressing.FACTORY
.createAttributedQName();
final QName port = new QName(NS_URI, "thePortType", NS_PREFIX);
portType.setValue(port);

final ServiceNameType serviceName = Addressing.FACTORY
.createServiceNameType();
final String portName = "thePortName";
serviceName.setPortName(portName);
final QName service = new QName(NS_URI, "theServiceName",
NS_PREFIX);
serviceName.setValue(service);

EndpointReferenceType eventReplyTo = Addressing
.createEndpointReference(Addressing.NS_URI,
props, params,
portType, serviceName);
int sizeOfEvent = 3;
int maxElements = 5;
Duration maxTime = DatatypeFactory.newInstance().newDuration
(50* 1000);
EventingContextBatched ctx = new EventingContextBatched(null,
null,
notifyTo, null,
eventReplyTo,DatatypeFactory.newInstance().newDuration(5*
1000),maxElements,maxTime);

EventsType events = Management.FACTORY.createEventsType();

ArrayList<EventType> event = new ArrayList<EventType>
(maxElements);
for(int i=0;i<maxElements;i++)
{
EventType evt = new EventType();
evt.setAction(ACTION);
for(int j = 0;j<sizeOfEvent;j++)

{ Foo object = new Foo(); object.setBar("object foo "+i); evt.getAny().add(object); }

event.add(evt);
events.getEvent().add(evt);
}

try{

Addressing addr =
WSEventingBaseSupport.createEventMessageBatched(ctx,events);
NodeList eventsList = addr.getBody
().getElementsByTagName(Management.NS_PREFIX + ":"+
EVENTS).item(0).getChildNodes();
final Management mgmt = new Management(addr);
final EventingExtensions evt = new EventingExtensions
(mgmt);
assertEquals(event.size(),eventsList.getLength());
//System.out.println(eventsList.item(0).getAttributes
().item(0).getTextContent());
for(int i=0;i<event.size();i++){
assertEquals(eventsList.item.getChildNodes
().getLength(),event.get.getAny().size());
assertEquals(eventsList.item.getAttributes().item
(0).getTextContent(),ACTION);
for(int j=0;j<sizeOfEvent;j++)

{ assertEquals(eventsList.item(i).getChildNodes ().item(j).getTextContent(),((Foo)event.get(i).getAny().get(j)).getBar()); }

}

assertEquals(eventReplyTo.getAddress().getValue(), addr
.getReplyTo().getAddress().getValue());
assertEquals(eventReplyTo.getReferenceProperties
().getAny()
.toString(), addr.getReplyTo
().getReferenceProperties()
.getAny().toString());
assertEquals(eventReplyTo.getReferenceParameters
().getAny()
.toString(), addr.getReplyTo
().getReferenceParameters()
.getAny().toString());
assertEquals(eventReplyTo.getPortType().getValue(), addr
.getReplyTo().getPortType().getValue());
assertEquals(eventReplyTo.getPortType
().getOtherAttributes(), addr
.getReplyTo().getPortType
().getOtherAttributes());
assertEquals(eventReplyTo.getServiceName().getValue(),
addr
.getReplyTo().getServiceName().getValue
());
assertEquals(eventReplyTo.getServiceName().getPortName
(), addr
.getReplyTo().getServiceName
().getPortName());
assertEquals(eventReplyTo.getServiceName
().getOtherAttributes(),
addr.getReplyTo().getServiceName
().getOtherAttributes());

assertEquals(DatatypeFactory.newInstance().newDuration
(5 * 1000)
.toString(), mgmt.getTimeout().toString());

assertTrue("AckRequested not set in response",
evt.isAckRequested());
System.out.println(addr);

}
catch(Exception e)

{ e.printStackTrace(); }

}

-------End of the detail code of unit test -------------

what is your comment on unit test and the sugguestion of modification ?





[WISEMAN-155] Expiration scheduling fails after renewal with no expires Created: 10/Jan/08  Updated: 16/Jan/08

Status: Open
Project: wiseman
Component/s: eventing
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: jfdenise Assignee: denis_rachal
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 155

 Description   

Scenario :
1) Subscribe with an expiration specified of 5 second
2) Renew after 2.5 sec with no expiration ==> Makes the context to have an
infinite life time.
3)After 5 seconds, server side Scheduling task tries to schedule the infinite
time and fails.



 Comments   
Comment by denis_rachal [ 16/Jan/08 ]

Taking ownership.





[WISEMAN-154] Subscribe response expires is not of the same type as the request Created: 10/Jan/08  Updated: 16/Jan/08

Status: Open
Project: wiseman
Component/s: eventing
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: jfdenise Assignee: denis_rachal
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 154

 Description   

WS-Eventing says SHOULD (meaning you need a strong reason not to do it). We are
not doing it with no reason. We should



 Comments   
Comment by denis_rachal [ 16/Jan/08 ]

Taking ownership.





[WISEMAN-153] RenewResponse is not set when sending back the response Created: 10/Jan/08  Updated: 16/Jan/08

Status: Open
Project: wiseman
Component/s: eventing
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: jfdenise Assignee: denis_rachal
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 153

 Description   

The Summary says it all.



 Comments   
Comment by denis_rachal [ 16/Jan/08 ]

Taking ownership.





[WISEMAN-156] Add A Sample for PushWithACK Delivery Mode Created: 10/Jan/08  Updated: 10/Jan/08

Status: Open
Project: wiseman
Component/s: client
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: ywu Assignee: ywu
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 156

 Description   

Hi,all,

The new feature PushWithACK delivery mode has been updated into the head. We
think it is better to have a sample of this new feature. We have the following
considerations:

  • using the DICE example as the basic architecture
  • add an option for users to choose PushWithAck mode
  • users should be able to view the ackowledged message

-------------------------------------------------------
Yu Wu
InSTech (Fudan-Hitachi Innovative Software Technology Joint Laboratory)
Network and Information Engineering Center, Fudan University, Shanghai, China
-------------------------------------------------------






[WISEMAN-152] Eventing subscription infinite expiration is not well supported Created: 04/Jan/08  Updated: 06/Jan/08

Status: Open
Project: wiseman
Component/s: eventing
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: jfdenise Assignee: denis_rachal
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 152

 Description   

When subscribing with no expiration duration, WiseMan is defaulting to a 1 day
duration. If this subscription is then renewed with no expiration, then the
subscription expiration becomes infinite.
WS-Eventing and WS-Management specification allow for infinite subscription
being only ended when unsubscribe is received. To achieve this behavior, one
need to renew the subscription with no expiration. This is not the right behavior.

We need to protect against badly written clients or client that die unexpectedly
so we need such behavior (in such a case, 1 day seems too long) but we also need
the ability to deactivate it.
If EnumerationContext leasing is implemented (lease based on client activity),
we can accept infinite subscription that will be cleared by the leasing processing.



 Comments   
Comment by jfdenise [ 04/Jan/08 ]

Possible solution would be to ;

  • fix the renew to make it behave as the subscribe behave.
  • add a boolean parameter to the subscribe operation to disable this bahavior.
  • add a boolean parameter to the renew operation to disable this behavior.
Comment by denis_rachal [ 06/Jan/08 ]

Taking ownership.

Comment by denis_rachal [ 06/Jan/08 ]

Taking ownership.





[WISEMAN-151] Eventing-Renew request returns without error for an enumeration context from Enumerate Created: 10/Dec/07  Updated: 06/Jan/08

Status: Open
Project: wiseman
Component/s: eventing
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: cahei Assignee: denis_rachal
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 151

 Description   

1) Do an enumerate request.
2) For the returned context, do an eventing renew request

I would have expected an error message of some kind (Invalid enumeration context
or Destination Unreachable)



 Comments   
Comment by denis_rachal [ 06/Jan/08 ]

Taking ownership.

Comment by denis_rachal [ 06/Jan/08 ]

Taking ownership.





[WISEMAN-150] implement PushWithAck mode in eventing module Created: 06/Dec/07  Updated: 12/Dec/07

Status: Open
Project: wiseman
Component/s: eventing
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: cxiao Assignee: denis_rachal
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Source File EventingContextBatched.java     Java Source File EventingContextWithAck.java     Java Source File EventingSupport.java     Java Source File HttpClient.java     Text File patch_PushWithAckMode.txt     Java Source File WSEventingBaseSupport.java     Java Source File WSEventingBaseSupportTest.java     Java Source File WSEventingSupport.java     Java Source File WSEventingSupportSink.java     Java Source File WSEventingSupportTest.java    
Issuezilla Id: 150

 Description   

We are from Fudan-Hitachi Innovative Software Technology Labratory (InSTech
Joint Lab) .
We are ready to contribute to wiseman communication.

The PushWithAck mode in eventing module has not been implemented in wiseman
project yet,
we would like to implement it.

While we communicate with Jean-Francois Denise and Rachal Denis,
we get many valuable comments from them .

Thank you very much, Jean-Francois and Rachal .

Now we summarize the proposal on PushWithAck mode in eventing module.

1.In package of com.sun.ws.management.server we add two subscription context
classes:
one class EventingContextWithAck for PushWithAck mode,
the other class EventingContextBatched for Batched Delivery mode.
EventingContextWithAck which is a subclass of EventingContext which is for Push
mode,
EventingContextBatched which is a subclass of EventingWithAckContext.

About EventingContextWithAck,
we add two member variables to EventingContextWithAck :
private EndpointReferenceType eventReplyTo;
private Duration operationTimeout;

then add getters & setters for the two member variables.

About EventingContextBatched,
we add two member variables to EventingContextBatched :
private int maxElements;
private Duration maxTime;

then add getters & setters for the two member variables.

2.In class of com.sun.ws.management.server.WSEventingSupport
we add four static "set" methods for the four options, i.e.
eventReplyTo,operationTimeout,maxElements,maxTime so that
the application developer can set values after the subscription context has
been created.

public static void setSendReplyTo(final UUID id, final EndpointReferenceType
eventReplyTo);
public static void setSendOperationTimeout(final UUID id, final Duration
operationTimeout);
public static void setSendMaxElements(final UUID id, final int maxElements);
public static void setSendMaxTime(final UUID id, final Duration maxTime);

3.In class of com.sun.ws.management.server.WSEventingBaseSupport
we add two delivery modes which was not supported in version 1.0 .

private static final String[] SUPPORTED_DELIVERY_MODES =

{ Eventing.PUSH_DELIVERY_MODE, EventingExtensions.PULL_DELIVERY_MODE, EventingExtensions.PUSH_WITH_ACK_DELIVERY_MODE, EventingExtensions.EVENTS_DELIVERY_MODE }

;

This time we focus on the PushWithAck mode.
The Batched Delivery mode will be supported later by us.

4.In class of com.sun.ws.management.server.WSEventingSupport
we update the static function:

public static UUID subscribe(final HandlerContext handlerContext,
final WSEventingRequest request,
final WSEventingResponse response,
final boolean isFiltered,
final int queueSize,
final ContextListener listener,
final Object factory)
throws DatatypeConfigurationException, SOAPException,
JAXBException, FaultException

{ ... }

So that the subscription context , i.e. the EventingContextWithAck or
EventingContextBatched object
would be initialized as the server receives the subscription request with
PushWithAck or Batched Delivery mode.

5.In class of com.sun.ws.management.server.EventingSupport
we update the static function:

public static boolean sendEvent(UUID id, Object content)
throws SOAPException, JAXBException, IOException { ... }

So that the application developer will use this uniform interface to send
events
from EventSource to EventSink regardless of the delivery mode specified by
users.
We add the support for the PushWithAck mode this time.

6.In class of com.sun.ws.management.server.WSEventingBaseSupport
we add one static function similar to function
public static Addressing createPushEventMessage(UUID id, Object content):

protected static Addressing createEventMessagePushWithAck(
final EventingContextWithAck ctx,
final Object content)
throws SOAPException, JAXBException, IOException

{ ... }

In function of com.sun.ws.management.server.EventingSupport.sendEvent(...)
we call this function to create event message in PushWithAck mode.

We provide the unit test code for this function
in file of
wiseman/se/test/src/com/sun/ws/management/server/WSEventingBaseSupportTest.java
.

7.In class of com.sun.ws.management.transport.HttpClient
we add one static function:
public static Addressing sendRequest(
final Addressing addressing,
final String destination)
throws IOException, SOAPException, JAXBException { ... }

In function of com.sun.ws.management.server.EventingSupport.sendEvent(...)
we call this function to send event and get the response, i.e. acknowledgement
or fault message .

8.In class of com.sun.ws.management.server.EventingSupport
we add ont private static function:

private static boolean parseEventResponse(Addressing eventResponse)
throws SOAPException, JAXBException, IOException

{ ... }

If the eventResponse is one ACK message, it will return true,
if the eventResponse is one Fault message, it will return false.

In function of com.sun.ws.management.server.EventingSupport.sendEvent(...)
we call this function to get the type of response message.

9.As Jean-Francois said, there will be many issues on the EventSink side.
This time we add one new package for event sink:
com.sun.ws.management.server.sink .
And we add one class named WSEventingSupportSink to this package.
In class of com.sun.ws.management.server.sink.WSEventingSupportSink
we add two static functions:

public static Addressing createEventACKAcknowledgement(Addressing
request)
throws SOAPException, JAXBException, IOException { ... }

public static Addressing createDeliveryRefusedFaultMessage(
Addressing request,
String reason)
throws SOAPException, JAXBException, IOException

{ ... }

Both functions can be called on EventSink side to create the response message,
e.g. ACK message,
after the event is received by sink.

We provide the unit test code for the two functions
in file of wiseman/se/test/src/management/WSEventingSupportTest.java .

That is all for the proposal this time.
The following is the file list:
Added:
wiseman/se/src/com/sun/ws/management/server/EventingContextWithAck.java
wiseman/se/src/com/sun/ws/management/server/EventingContextBatched.java
wiseman/se/src/com/sun/ws/management/server/sink/WSEventingSupportSink.java

wiseman/se/test/src/management/WSEventingSupportTest.java

wiseman/se/test/src/com/sun/ws/management/server/WSEventingBaseSupportTest.java

Modified:
wiseman/se/src/com/sun/ws/management/server/WSEventingSupport.java
wiseman/se/src/com/sun/ws/management/server/WSEventingBaseSupport.java
wiseman/se/src/com/sun/ws/management/server/EventingSupport.java
wiseman/se/src/com/sun/ws/management/transport/HttpClient.java

Thanks to Jean-Francois and Rachal again.
Merry X'mas ahead.



 Comments   
Comment by cxiao [ 06/Dec/07 ]

Created an attachment (id=10)
java file for EventingContextBatched, added.

Comment by cxiao [ 06/Dec/07 ]

Created an attachment (id=11)
java file for EventingContextWithAck, added.

Comment by cxiao [ 06/Dec/07 ]

Created an attachment (id=12)
java file for EventingSupport, modified.

Comment by cxiao [ 06/Dec/07 ]

Created an attachment (id=13)
java file HttpClient, modified.

Comment by cxiao [ 06/Dec/07 ]

Created an attachment (id=14)
java file for WSEventingBaseSupport, modified

Comment by cxiao [ 06/Dec/07 ]

Created an attachment (id=15)
java file for WSEventingBaseSupportTest, added.

Comment by cxiao [ 06/Dec/07 ]

Created an attachment (id=16)
java file for WSEventingSupport, modified.

Comment by cxiao [ 06/Dec/07 ]

Created an attachment (id=17)
java file for WSEventingSupportSink, added.

Comment by cxiao [ 06/Dec/07 ]

Created an attachment (id=18)
java file for WSEventingSupportTest, added.

Comment by cxiao [ 06/Dec/07 ]

We are ready to contribute to wiseman community. sorry, not communication.

Comment by cxiao [ 12/Dec/07 ]

Created an attachment (id=19)
a diff file which can be applied to wiseman. a patch for pushwithack .

Comment by cxiao [ 12/Dec/07 ]

If the diff file in attachment is applied to wiseman,
it will add or modify the following files:

Added:
wiseman/se/src/com/sun/ws/management/server/EventingContextWithAck.java
wiseman/se/src/com/sun/ws/management/server/EventingContextBatched.java
wiseman/se/src/com/sun/ws/management/server/sink/WSEventingSupportSink.java

wiseman/se/test/src/management/WSEventingSupportSinkTest.java
wiseman/se/test/src/management/WSEventingBaseSupportTest.java

Modified:
wiseman/se/src/com/sun/ws/management/server/WSEventingSupport.java
wiseman/se/src/com/sun/ws/management/server/WSEventingBaseSupport.java
wiseman/se/src/com/sun/ws/management/server/EventingSupport.java
wiseman/se/src/com/sun/ws/management/transport/HttpClient.java
wiseman/se/src/com/sun/ws/management/server/EventingContext.java





[WISEMAN-143] Fragment in-scope NamespaceContext is wrong Created: 22/Oct/07  Updated: 22/Oct/07

Status: Open
Project: wiseman
Component/s: transfer
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: jfdenise Assignee: wiseman-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 143

 Description   

Specification says that the "in-scope" namespace fr Fragment Transfer must be
the first element inside the body.
Implementation in TransferExtensions class takes the Fragment header node.






[WISEMAN-137] Problems with dependencies in generated build.xml files Created: 18/Sep/07  Updated: 26/Sep/07

Status: Open
Project: wiseman
Component/s: addressing
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Bug Priority: Minor
Reporter: nbeers Assignee: nbeers
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 137

 Description   

When the user generates a wiseman enabled web service using our wsdl-war-
template.jar file, there are some problems with the target dependencies in the
generated build.xml.

1) The war target does not depend on the compile target.
2) The compile target depends on the generate target (this causes the code to
be re-generated in the gen-src directory every time you compile it).

The documentation also needs to be fixed to tell the user to copy all of the
gen-src directory files to the src directory before modifying them, otherwise
they will get overwritten and they won't be included in the war.



 Comments   
Comment by nbeers [ 26/Sep/07 ]

Started. The war - compile dependency change has been checked in.





[WISEMAN-139] ?WSDL request doesn't provide wsdl file Created: 24/Sep/07  Updated: 26/Sep/07

Status: Open
Project: wiseman
Component/s: meta-data
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: stanullo Assignee: simeonpinder
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Other


Issuezilla Id: 139

 Description   

I generated a Wiseman server stack according to the Wiseman Server Developer's
Guide. I tried following request on the Server:
https://<server>:port/my-service/?WSDL
Then I got following error message: "The system cannot locate the object
specified. Error processing resource 'https://marcus.deu.hp.com:8443/opr-
webservice/?WS..."
I found out, that my WSDL file was available, but under the wrong path.
Following request provided the file:
.../my-service/schemas/wsdls/IncidentService.wsdl

I stopped the web service and copied the file to another location:
From: /schemas/wsdls/IncidentService.wsdl
To: /wsdls/IncidentService.wsdl
... and now it works!

Unfortunatelly I didn't find a workaround for further wsdl and xsd files
referenced by the initial wsdl file. So it was e.g. not possible to generate a
Windows WCF client based on the ?WSDL response.



 Comments   
Comment by nbeers [ 26/Sep/07 ]

We're having some problems trying to reproduce this issue, especially the
location of the wsdl file (my-service/schemas/wsdls/). Could you please zip up
all of your project files and attach them to this issue ? Thanks.





[WISEMAN-136] Support for SOAP with attachments Created: 17/Sep/07  Updated: 17/Sep/07

Status: Open
Project: wiseman
Component/s: management
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: nbeers Assignee: nbeers
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 136

 Description   

Both the server and the client toolkit need to be updated to support SOAP
messages with attachments. The underlying JAAS classes support the
attachments – the functionality needs to be exposed in the wiseman code.



 Comments   
Comment by nbeers [ 17/Sep/07 ]

started

Comment by nbeers [ 17/Sep/07 ]

started





[WISEMAN-135] Missing metadata.properties file causes null pointer exception in mviewer Created: 17/Sep/07  Updated: 17/Sep/07

Status: Open
Project: wiseman
Component/s: Tooling
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: nbeers Assignee: wiseman-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 135

 Description   

If your web service is missing the metadata.properties file or the metadata-
handlers.properties file, a NullPointerException will be thrown if the user
tries to use the metadata viewer tool to browse the web service.






[WISEMAN-133] HttpClient.setUseApacheCommonsHttpClient() ignored Created: 10/Sep/07  Updated: 12/Sep/07

Status: Open
Project: wiseman
Component/s: transfer
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: stephen_m_barrett Assignee: simeonpinder
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 133

 Description   

It appears that the class com.sun.ws.management.transport.HttpClient ignores the
setting of the “setUseApacheCommonsHttpClient� method. Examination of the code
indicates that it will only deal with the java.net.Authenticator class; a flawed
authentication implementation. The java.net.Authenticator class, which should
be an interface, uses the method signature “protected final String
getRequestingScheme()� which prohibits the use of authentication schemes other
then those hard-coded in the JVM. The Apahce Commons HttpClient will, according
to its documentation, respond to non-standard scheme requests which are
pre-registered by the local implementation.

Is this something that is going to be corrected or are you trying to phase out
the possibility of replacing your transport layer with the Commons HttpClient
package?



 Comments   
Comment by simeonpinder [ 12/Sep/07 ]

The plan is to modify the HttpClient to support alternative connection apis like
the Apache Commons HttpClient. The method that you encountered is part of that
effort but was not completed due to lack of resources. This will be resolved
before the next release.





[WISEMAN-127] No way to express optionset options in metadata exposed. Created: 21/Aug/07  Updated: 21/Aug/07

Status: Open
Project: wiseman
Component/s: meta-data
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Bug Priority: Minor
Reporter: simeonpinder Assignee: wiseman-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 127

 Description   

The DefaulAddressingModelAnnotation does not currently provide a mechanism to
define service options via the OptionSet mechanism defined in the specification.
This means that WS-Management server implementations cannot currently
preconfigure these options to potential clients. The only alternative at this
time is to use the apis to add these elements.

This fix must occur in several areas:
-root annotation definition(will probably require a new annotation type).
-translated xml being exposed via metadata to include optionsets now.
-subsequent modifications must be made to the metadata viewer to expose them if
available
-unit tests that currently exercise metadata need to be enhanced to test for
these options.






[WISEMAN-126] Metadata Resource Accessor should used tabbed panes Created: 21/Aug/07  Updated: 21/Aug/07

Status: Open
Project: wiseman
Component/s: Tooling
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Improvement Priority: Trivial
Reporter: simeonpinder Assignee: wiseman-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 126

 Description   

The Metadata Resource Accessor GUI should use Tabbed panes within a scroll panel
to allow users to define task specific information.

Ex. For defining client requests for Enumerations, instead of the existing check
box to indicate that an optimizedEnumerate request should be sent, there should
be an 'Enumerations' tab where all possible Enumeration options can be defined.

Transfer and Eventing functionality should be also be broken out onto their own
customized/scrollable tabs. Pending 'missing optionset issue with metadata', an
customizable list of optionsets should be able to be defined for each request as
well.

There is far too little space in the GUI to display all of the information that
is required, but tabbed panes could help with that.






[WISEMAN-29] Code generation requires automated testing Created: 25/Aug/06  Updated: 13/Aug/07

Status: Open
Project: wiseman
Component/s: Tooling
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: obiwan314 Assignee: nbeers
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 29

 Description   

Generated code should be tested against the current wiseman classes with its own
unit tests. These tests could be as simple as generating and compiling a
resource and halting the build if compile errors occur.



 Comments   
Comment by nbeers [ 13/Aug/07 ]

Start investigation

Comment by nbeers [ 13/Aug/07 ]

start investigation





[WISEMAN-25] Create tests around the JAXBResource Created: 18/Aug/06  Updated: 09/Aug/07

Status: Open
Project: wiseman
Component/s: client
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Minor
Reporter: obiwan314 Assignee: wiseman-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 25

 Description   

The JAXBResource currently has no test coverage.



 Comments   
Comment by simeonpinder [ 09/Aug/07 ]

Priority lowered. Still needs investigation.





[WISEMAN-124] Performance analysis numbers of Wiseman soap stack Created: 08/Aug/07  Updated: 08/Aug/07

Status: Open
Project: wiseman
Component/s: management
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: simeonpinder Assignee: wiseman-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 124

 Description   

We need to determine performance numbers for the Wiseman SOAP stack.

WS-Management SOAP stacks have a different processing model than traditional RPC
web service models like JAXWS/AXIS*/.Net and it would also be helpful if we can
generate comparative numbers between the two approaches as well.

This issue should track the performance analysis work that has already been done
for this task.






[WISEMAN-123] online/html documentation of Wiseman framework needed Created: 08/Aug/07  Updated: 08/Aug/07

Status: Open
Project: wiseman
Component/s: www
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: simeonpinder Assignee: wiseman-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 123

 Description   

The pdf/.doc formal documentation content delivered with Wiseman 1.0 needs to be
exposed in a web format. Printed/published documentation goes out of date as
soon as it is published and a mechanism needs to be in place to update the
published documentation for released versions. When the API docs have been
cleaned up they should also be exposed via html.

A link should be added to the project home indicating where to get specific
versions of the documentation.






[WISEMAN-21] Add Eventing Support to Client Created: 18/Aug/06  Updated: 06/Aug/07

Status: Open
Project: wiseman
Component/s: client
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: obiwan314 Assignee: obiwan314
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 21

 Description   

The client has no support for eventing beyond what is already present in
wiseman. This should be enhanced to include an Observer Pattern based way to
create listeners and bind their events to java objects inside a client
application, optionally using JAXB on the received events. A method of creating
a simple listener for J2SE environments should also be provided.



 Comments   
Comment by simeonpinder [ 06/Aug/07 ]

Upon further investigation it was discovered that a full implementation of
WS-Eventing as described via WS-Management quickly involves model specific
decisions, which makes this task of defining generic helper functionality
non-trivial. This is a result of insufficient direction when building eventing
implementations from the WS-Management and WS-Eventing specifications. To
further demonstrate this explanation the following questions, required to
successfully build client side eventing were uncovered:

  • How does one find a list of subscribers to subscribe to? Currently apriori
    knowledge of subscriptions is assumed.
  • To successfully interact with an eventing implementation, how does one
    determine what strategy is to be used to access the events being generated? Is
    it PUSH/PULL/Custom mechanism? Assuming the approach is known, how does one
    find/learn the symantics of using the Eventing mechanism defined? Should a
    client framework provide support for PUSH/PULL out of the box only? Is there a
    more generic approach to subscription/Events?
  • How does one find out what the Event message payloads look like so that they
    may be processed? Event payloads are custom by definition?

These are just a few of the model specific implementation details that made this
task much more difficult than originally assumed.

This task has been deferred for later releases until more direction from
users/consumers emerges.





[WISEMAN-122] Add SOAP header definitions to WSDL Created: 03/Aug/07  Updated: 03/Aug/07

Status: Open
Project: wiseman
Component/s: client
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: nbeers Assignee: wiseman-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 122

 Description   

When we generate the WSDL for a wiseman web service, we are currently not
adding the definitions for any of the operation's SOAP headers. This should be
added for better 3rd party client code generation. If these headers are added
to the WSDL, the Visual Studio client generation tool (wsdl.exe) will define
the C# objects for these headers.

Note that there does seem to be a few problems with this generation which will
require the user hand modifying these generated headers. For example, the
SelectorSet header does not have the name attribute generated, but it can be
added manually.

Also note that this will change the method signatures for the wiseman calls
from an Axis client. Each of the headers will be added as a parameter to the
operation call (ex. Get(ActionHeader, ToHeader, ...).

JAX-WS will ignore the headers unless they are definied using the explicit
definition method. (as opposed to the implicit method which ws-man currently
uses).






[WISEMAN-121] Calls to "Put" fail with 3rd party client tools Created: 03/Aug/07  Updated: 03/Aug/07

Status: Open
Project: wiseman
Component/s: client
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Bug Priority: Critical
Reporter: nbeers Assignee: wiseman-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 121

 Description   

Attempts to invoke the Put method through a 3rd party SOAP client toolkit
(Axis, JAX-WS) will fail due to an error in the web service's WSDL. The WSDL
defines the Put operation as taking a AnyXml object as an input parameter.
This should actually be an instance of the web service's schema type object
(i.e. TrafficLight). Additionally, the Put operation should also define the
output type as an instance of this schema type and not AnyXmlOptional.

We were unable to correctly define this operation in ws-man 1.0, because JAX-WS
would not allow two operations to have the same type of input parameter (Create
and Put). This will be fixed in JAX-WS 2.1.2 with the addition of action based
dispatching.

After the release of JAX-WS 2.1.2, the WSDL template should be updated to
correctly make the input parameter of the Put method a <UserType> object, not
an AnyXml object. The output parameter should also be updated to this type.






[WISEMAN-116] WSManAgent can't select a transport for Non Anonymous reply Created: 13/Jun/07  Updated: 13/Jun/07

Status: Open
Project: wiseman
Component/s: addressing
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: jfdenise Assignee: wiseman-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 116

 Description   

HttpClient.sendResponse usage is hardcoded. very limitative. Should be pluggable.






[WISEMAN-110] Invalid WSMAN WSDL File Created: 17/May/07  Updated: 11/Jun/07

Status: Open
Project: wiseman
Component/s: management
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: ywu Assignee: denis_rachal
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 110

 Description   

When trying to stimulate multiple SOAP requests to the WSMAN for performance
test using JMeter, JMeter can not load WSDL file and report invalid WSDL file error.
(http://jakarta.apache.org/jmeter/ )

The WSMAN wsdl can be access through http://localhost:8080/wsman?wsdl.
But it can not be loaded in JMeter tools.

WSMAN is based on JAWS(Java API for XML Based Web Services). I wonder if there
is any other kind of test tools available to run the performance test.



 Comments   
Comment by denis_rachal [ 11/Jun/07 ]

Take ownership.





[WISEMAN-112] Wiseman optimization required Created: 04/Jun/07  Updated: 04/Jun/07

Status: Open
Project: wiseman
Component/s: management
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Critical
Reporter: jfdenise Assignee: wiseman-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 112

 Description   

It appears that unmarshaling/marshaling message elements is very costly.
This processing must be reduced. Reducing this processing has a non negligeable
impact on the current API of major classes (Message, Management, SOAP...).
Unmarshalling is done each time a piece of data is get from Message class.
Marshaling and unbind of existing element is done each time a piece of
information is set to the Message. This is required when you want the internal
SOAPMessage to be in sync with the wrapper. Do we really want this perpetual
synchronization?

We should be able to get/set information without doing any marshal/unmarshal
processing and finally ask for a SOAPMessage. Currently the Message.getMessage()
returns the actual internal SOAPMessage. It should be replaced by a SOAPMessage
createMessage() that will create a SOAPMessage based on what was previously get/set.
As said, it changes the way these core classes are behaving.






[WISEMAN-93] JAXWS agent not handling UTF-16 encoding. Created: 20/Mar/07  Updated: 30/Apr/07

Status: Open
Project: wiseman
Component/s: jaxws-deployment
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: simeonpinder Assignee: wiseman-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 93

 Description   

In JAXWS deployment mode the server is not responding with the correct content
encoding type.
******************
junit.framework.AssertionFailedError:
expected:<application/soap+xml;charset=utf-16> but
was:<application/soap+xml;charset=utf-8>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:71)
at management.ManagementTest.testGet(ManagementTest.java:258)
...

                              • To Reproduce:
                                -Run the test-jaxws target.
                                -see the test results for ManagementTest.testGet()/testGetResponseEncoding()



 Comments   
Comment by yxxu [ 30/Apr/07 ]

The same problem occurs too when doing ant build target 'test-j2se-jaxws'.
The reason is that it is not yet implemented to support UTF-16 contentType in
the source .

Reproduce that:
1)ant build target 'deploy-j2se-jaxws'
2)ant build target 'test-j2se-jaxws'
3)then the problem reports





[WISEMAN-105] Convert XSD from MOF Created: 13/Apr/07  Updated: 18/Apr/07

Status: Open
Project: wiseman
Component/s: Mapping
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: ritujain26oct Assignee: akhilarora
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 105

 Description   

Hi,

I want to use Wiseman to convert my MOF files to XSD files. Can I do that? I am
unable to find this feature in the latest download. Do we have any other
separate download from which we can get the same?

Regards,
Ritu



 Comments   
Comment by akhilarora [ 18/Apr/07 ]

There is a prototype, partial implementation in the mapping subdirectory, please
check it out of the repository. Contributions welcome. I've moved on to another
project and will not be able to work on this anymore.





[WISEMAN-97] Allow WiseMan resource to be plugged into JSR262 Connector Created: 28/Mar/07  Updated: 09/Apr/07

Status: Open
Project: wiseman
Component/s: Tooling
Affects Version/s: current
Fix Version/s: milestone 1

Type: New Feature Priority: Major
Reporter: jfdenise Assignee: obiwan314
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 97

 Description   

JSR262 is currently defining a way to intercept requests targeted to a
ResourceURI. It would be nice to take benefit of this API in order to plug a
WiseManResourceHandler that would root requests to WiseMan resources
(implemented thanks to WiseMan tooling).






[WISEMAN-101] Client doesn't handle 'unsupported feature' fault for MaxTime Created: 02/Apr/07  Updated: 02/Apr/07

Status: Open
Project: wiseman
Component/s: client
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: rockybarney Assignee: wiseman-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 101

 Description   

If a service doesn't implement MaxTime or OperationalTimeout, but instead sends
a fault response indicating that this is an unsupported feature, the wiseman
client doesn't handle this case by retrying the request without the MaxTime
property.






[WISEMAN-96] Replace Wiseman static and servlet based configuration Created: 28/Mar/07  Updated: 28/Mar/07

Status: Open
Project: wiseman
Component/s: jaxws-deployment
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: jfdenise Assignee: wiseman-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 96

 Description   

Currently it is not possible to instantiate multiple WSMan JAX-WS endpoint
without having configuration shared by all the instances.
impacted classes :
WSManAgent
WSManJAXWSEndpoint
XmlBinding
Metadata

Servlet API is referenced in order to locate handlers configuration. This make
pure J2SE deployment not doable.






[WISEMAN-24] Client fragment support should be simplified Created: 18/Aug/06  Updated: 20/Mar/07

Status: Open
Project: wiseman
Component/s: client
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Minor
Reporter: obiwan314 Assignee: obiwan314
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 24

 Description   

Currently, users of the client must implement their own fragment headers to
perform fragment operations. If we assume that many fragment use cases will
operate on individual fields in simple wrapped resource documents then we should
be able to add methods to get/set/create or delete individual fields using
fragment transfer and automatically generate these fragement headers.



 Comments   
Comment by obiwan314 [ 03/Oct/06 ]

Working on making fragment support automatic for xpath on projects generated
from schema.





[WISEMAN-86] Locate api components no longer used to create cleaner API interface Created: 04/Mar/07  Updated: 04/Mar/07

Status: Open
Project: wiseman
Component/s: Mapping
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: simeonpinder Assignee: simeonpinder
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 86

 Description   

There are several api segments with associated schema artifacts that are no
longer relevant in the current Wiseman architecture. This task involves:
-locating these elements
-removing those same elements from the code tree
-evaluating whether unused components should still be retained

A few of these located items are:

  • PreDMTF Wsman Catalog components
  • CIM Mapping section
  • etc..





[WISEMAN-70] Lack for freedom for EnumerationContext persistency Created: 16/Feb/07  Updated: 16/Feb/07

Status: Open
Project: wiseman
Component/s: enumeration
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: jfdenise Assignee: wiseman-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 70

 Description   

Currently EnumerationContext are stored in a staic Map, this can't be overloaded.
It could be nice to allow customer to provide their own EnumerationContext
persistency strategy.






[WISEMAN-69] EventingSupport.unsubscribe throw not compliant Exception Created: 09/Feb/07  Updated: 09/Feb/07

Status: Open
Project: wiseman
Component/s: eventing
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: jfdenise Assignee: wiseman-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 69

 Description   

The following piece of code is to be fixed with the usage of
InvalidContextFault.

if (found == null)

{ /* * TODO: Convert to InvalidContextFault when available in * updated WS-Management specification */ throw new InvalidMessageFault("Subscription with Identifier: " + identifier + " not found"); }

 Comments   
Comment by jfdenise [ 09/Feb/07 ]

It will be fixed when ws-management spec. Need to track spec on this.





[WISEMAN-54] management.EventingTest is not robust Created: 18/Dec/06  Updated: 18/Dec/06

Status: Open
Project: wiseman
Component/s: unit tests
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: jfdenise Assignee: wiseman-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 54

 Description   

testEventingFiltering is failing randomly.
</env:Reason><env:Detail><ex:Exception
xmlns:ex="http://schemas.sun.com/ws/java/exception">java.lang.IllegalStateException:
handler timer already canceled.
XML sent back stack trace:
<ex:StackTrace><ex:t>Timer:354</ex:t><ex:t>Timer:222</ex:t><ex:t>eventing_Handler:109</ex:t><ex:t>NativeMethodAccessorImpl:-2</ex:t><ex:t>NativeMethodAccessorImpl:39</ex:t><ex:t>DelegatingMethodAccessorImpl:25</ex:t><ex:t>Method:597</ex:t><ex:t>ReflectiveRequestDispatcher:91</ex:t><ex:t>ReflectiveRequestDispatcher:35</ex:t><ex:t>FutureTask:303</ex:t><ex:t>FutureTask:138</ex:t><ex:t>Executors:441</ex:t><ex:t>FutureTask:303</ex:t><ex:t>FutureTask:138</ex:t><ex:t>ThreadPoolExecutor:885</ex:t><ex:t>ThreadPoolExecutor:907</ex:t><ex:t>Thread:619</ex:t></ex:StackTrace></ex:Exception></env






[WISEMAN-26] INVESTIGATION: Implementation Rules Created: 18/Aug/06  Updated: 25/Aug/06

Status: Open
Project: wiseman
Component/s: management
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: obiwan314 Assignee: wiseman-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 26

 Description   

The Ws Management spec contains behavior "Rules" which dictate how features
should behave. An example would be:

UTF16 Requests require UTF16 Responses.

These rules should be found and listed. Rules which are not supported should
become new requirements and should be entered as new issues as children of this
issue.



 Comments   
Comment by obiwan314 [ 25/Aug/06 ]

Changed to an enhancement





Generated at Mon Feb 08 00:18:44 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.