Bugs item #1901290, was opened at 2008-02-25 11:21
Message generated for change (Settings changed) made by blaschke-oss
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1901290&group_id=128809
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Java Client
Group: Function
Status: Open
Resolution: None
Priority: 8
Private: No
Submitted By: chrisreich (chrisreich)
>Assigned to: RAVI GUMMADAVELLI (rgummada)
Summary: SLP error: "java.io.IOException" on Linux and IPv6
Initial Comment:
Using the IPv6 enabled sblimSLPClient on Linux returns the following error:
[SEVERE main 2008.02.25 12:17:42 795 org.sblim.slp.internal.ua.DatagramRequester.run(DatagramRequester.java:166)]
Cannot assign requested address
java.io.IOException: Cannot assign requested address
at java.net.PlainDatagramSocketImpl.send(Native Method)
at java.net.PlainDatagramSocketImpl.send(PlainDatagramSocketImpl.java:84)
at java.net.DatagramSocket.send(DatagramSocket.java:634)
at org.sblim.slp.internal.ua.DatagramRequester.mcastNegotiate(DatagramRequester.java:231)
at org.sblim.slp.internal.ua.DatagramRequester.run(DatagramRequester.java:160)
at org.sblim.slp.internal.ua.DatagramRequester.start(DatagramRequester.java:133)
at org.sblim.slp.internal.ua.SLEnumerationImpl.getDAList(SLEnumerationImpl.java:166)
at org.sblim.slp.internal.ua.SLEnumerationImpl.hasMoreElements(SLEnumerationImpl.java:108)
at org.sblim.slp.example.SLPTool.dumpEnum(SLPTool.java:196)
at org.sblim.slp.example.SLPTool.serviceRequest(SLPTool.java:160)
at org.sblim.slp.example.SLPTool.main(SLPTool.java:99)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1901290&group_id=128809

Bugs item #1902375, was opened at 2008-02-26 17:41
Message generated for change (Settings changed) made by blaschke-oss
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1902375&group_id=128809
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Java Client
Group: Usability
Status: Open
Resolution: None
Priority: 8
Private: No
Submitted By: Todd Schlomer (toddsch)
>Assigned to: Dave Blaschke (blaschke-oss)
Summary: Can Not Close CIMClient During Open Requests
Initial Comment:
Hello,
We need to be able to close the CIMClient during an open request to the CIMOM server. Currently all the methods on the CIMClient are synchronized so it is not possible to issue the CIMClient.close() while a CIMClient .enumerateInstances() method or some other request is running.
This is a problem because at times the requests to the CIMOM server will hang and never return. Hangs usually occur when the CIMClient loses connection with the CIMOM server during an open request. Other times, the CIMOM server gets an internal deadlock and never services the request causing the client to hang.
These client hangs will basically hang the thread that is currently issuing the request as it will no longer be usable.
After a while, out of memory thread limit exceptions will occur due to the fact that there are rampant threads still running since they are unable to be stopped. With thread pools, this causes a deadlock as all the threads will eventually be eaten by hangs as the open requests are not able to be stopped.
What we need is the ability to issue the CIMClient.close() method while a CIMClient request is currently being run. This should preemptively close all IO streams and sockets to the CIMOM server and return an error to the pending client request.
Let me know if any further information is needed.
Thanks for your time,
Todd
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1902375&group_id=128809

Bugs item #1904340, was opened at 2008-02-28 17:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1904340&group_id=128809
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: sfcb
Group: None
Status: Open
Resolution: None
Priority: 2
Private: No
Submitted By: Chris Buccella (buccella)
Assigned to: Chris Buccella (buccella)
Summary: shared library error after configuring with --enable-slp
Initial Comment:
After the configure/make/make install process, starting sfcbd resulted in:
sfcbd: error while loading shared libraries: libslpAgent.so.0: cannot open shared object file: No such file or directory
Maybe running ldconfig was skipped along the way...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1904340&group_id=128809

Bugs item #1903946, was opened at 2008-02-28 14:40
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1903946&group_id=128809
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Java Client (JSR48)
Group: Function
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dave Blaschke (blaschke-oss)
Assigned to: Dave Blaschke (blaschke-oss)
Summary: no CIMExeption thrown for wrong namespace using SAXParser
Initial Comment:
Up for consideration, apply 1893499 to 2.0.x
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1903946&group_id=128809

Bugs item #1874440, was opened at 2008-01-18 08:41
Message generated for change (Settings changed) made by blaschke-oss
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1874440&group_id=128809
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Java Client
Group: Function
Status: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: chrisreich (chrisreich)
Assigned to: Nobody/Anonymous (nobody)
Summary: sblimSLPClient PARSE_ERROR with large number of service urls
Initial Comment:
In a test lab the SLP discovery with sblimCIMClient 1.3 end with exception:
2008-01-18 09:22:52.901+01:00 ERROR java.lang.RuntimeException: org.sblim.slp.ServiceLocationException: PARSE_ERROR(37-byte long string field is expected but only 3 bytes could be read!)
at org.sblim.slp.internal.ua.SLEnumerationImpl.hasMoreElements(SLEnumerationImpl.java:121)
at com.ibm.tpc.discovery.cimom.SLPScanner.getCIMOMServices(SLPScanner.java:112)
at com.ibm.tpc.discovery.cimom.SLPScanner.run(SLPScanner.java:410)
Caused by: org.sblim.slp.ServiceLocationException: PARSE_ERROR(37-byte long string field is expected but only 3 bytes could be read!)
at org.sblim.slp.internal.msg.SLPInputStream.readRawString(SLPInputStream.java:298)
at org.sblim.slp.internal.msg.SLPInputStream.readString(SLPInputStream.java:104)
at org.sblim.slp.internal.msg.SLPInputStream.readURL(SLPInputStream.java:185)
at org.sblim.slp.internal.msg.SLPInputStream.readUrlList(SLPInputStream.java:200)
at org.sblim.slp.internal.msg.ServiceReply.parse(ServiceReply.java:59)
at org.sblim.slp.internal.msg.MsgFactory$8.parse(MsgFactory.java:132)
at org.sblim.slp.internal.msg.MsgFactory.parse(MsgFactory.java:222)
at org.sblim.slp.internal.msg.MsgFactory.parse(MsgFactory.java:204)
at org.sblim.slp.internal.ua.DatagramRequester.mcastNegotiate(DatagramRequester.java:216)
at org.sblim.slp.internal.ua.DatagramRequester.run(DatagramRequester.java:160)
at java.lang.Thread.run(Thread.java:813) com.ibm.tpc.discovery.cimom.SLPScanner run SLP (Thread-84)
Further investigation showed that a long list of cimom urls (approx. > 30) retrieved by the client causes this.
The problem can be recreated by setting up a SA/DA that gives back a large number of urls.
This is a severe limitation and makes the client unusable.
----------------------------------------------------------------------
Comment By: Dave Blaschke (blaschke-oss)
Date: 2008-02-26 21:28
Message:
Logged In: YES
user_id=1215427
Originator: NO
Patch is in HEAD and 1.3.5.
----------------------------------------------------------------------
Comment By: Endre Bak (ebak)
Date: 2008-02-15 16:38
Message:
Logged In: YES
user_id=1508775
Originator: NO
see 1892103 for details
File Added: patch.1874440_sblimSLPClient_PARSE_ERROR.txt.gz
----------------------------------------------------------------------
Comment By: RAVI GUMMADAVELLI (rgummada)
Date: 2008-01-25 20:26
Message:
Logged In: YES
user_id=1975918
Originator: NO
1. why is the iInBuf size limited to network MTU size ( 1500 bytes ).what
is the basis for setting it to this value?
2. is there a max limit of bytes (max message size) that can be put into
iInBuf, ( when iInbuf was increased to 8000, you were able to read all
urls, the problem would come back when message size exceeds 8000 bytes )
3. Though SLP allows TCP traffic for unicast, since UDP does not provide
sequencing of packets, entire message should arrive in right order. Can we
increase the iInBuf size to any arbitrary Max. value, or do we need to do
dynamic MTU discovery to support TCP traffic.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1874440&group_id=128809

Bugs item #1835847, was opened at 2007-11-21 15:38
Message generated for change (Settings changed) made by blaschke-oss
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1835847&group_id=128809
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Java Client
Group: New Feature
Status: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Endre Bak (ebak)
Assigned to: Robert ILLES (krawalter)
Summary: property for configuration file location
Initial Comment:
Currently on Windows there is no absolute path for the configuration file.
It causes inconveniences for TPC.
A property should be introduced which could predefine the location of the configuration file e.g.:-Dsblim.wbem.configFile=C:/cim.defaults
----------------------------------------------------------------------
Comment By: Dave Blaschke (blaschke-oss)
Date: 2008-02-26 21:27
Message:
Logged In: YES
user_id=1215427
Originator: NO
Patch is in HEAD and 1.3.5.
----------------------------------------------------------------------
Comment By: Endre Bak (ebak)
Date: 2007-11-21 17:32
Message:
Logged In: YES
user_id=1508775
Originator: YES
The property name is "sblim.wbem.configFile".
File Added: patch.1835847_property_for_configuration_file_location.txt
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1835847&group_id=128809

Bugs item #1824094, was opened at 2007-11-01 14:27
Message generated for change (Settings changed) made by blaschke-oss
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1824094&group_id=128809
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Java Client
Group: Function
Status: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Murle Cleveland Meetze III (bubbameetze)
Assigned to: Robert ILLES (krawalter)
Summary: CIMNameSpace(String pURI) doesn't handle namespace properly.
Initial Comment:
CIMNameSpace constructor with a single String parameter pURI which I understand to be of the form:
protocol://hostname[:port]/file
Example: https://47.11.8.15:5989/root/cimv2
Calls the other constructor which accepts two Strings, one for host and the other for namespace however it calls it with the namespace as a null so this constructor always defaults to the hardcoded namespace root/cimv2.
public CIMNameSpace(String pURI) throws CIMException {
// TODO validate NameSpace
this(pURI, null);
}
So when one makes the call like this:
CIMNameSpace cns = new CIMNameSpace("http://10.5.2.91:5988/root/interop";);
The protocol, host and port come through ok, however the namespace gets thrown away. Suggest parsing the input to make sure that there is no namespace/file passed in at the end of the pURI.
----------------------------------------------------------------------
Comment By: Dave Blaschke (blaschke-oss)
Date: 2008-02-26 21:26
Message:
Logged In: YES
user_id=1215427
Originator: NO
Patch is in HEAD and 1.3.5.
----------------------------------------------------------------------
Comment By: Endre Bak (ebak)
Date: 2007-11-05 14:21
Message:
Logged In: YES
user_id=1508775
Originator: NO
The patch is ready to handle IPv6 and overwrites CIMNameSpace's IPv6
modification which was committed before.
File Added:
patch.1824094_CIMNameSpace_String_pURI_doesnt_handle_namespace_properly.txt
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1824094&group_id=128809

Bugs item #1804532, was opened at 2007-09-28 21:44
Message generated for change (Settings changed) made by blaschke-oss
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1804532&group_id=128809
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Java Client
Group: Function
Status: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Dave Wolfe (dwolfe2)
Assigned to: Robert ILLES (krawalter)
Summary: trace for both req/res should be traced in the same file
Initial Comment:
Currently the trace (if enabled) is traced - depending on if the item to trace is a request or a response - to the console-window or to a trace-file.
The trace for both requests and responses should be traced within the same
file.
Unfortunately the SBLIMCimClient does not provide a way to have incoming
requests and corresponding responses to be traced into a single
file.
This would be a very important feature where
you need to correlate requests with their responses.
As a workaround I recommend downloading the sourcecode for the SBLIMCimClient.
One file needs to be extracted and added into the org.sblim.cim.client package
included in Aperi.
Fetch org.sblim.wbem.xml.XMLDefaultHandlerImpl.java and modify line 187 as
follows:
private static Writer cOut = new
PrintWriter(GlobalProperties.getDebugOutputStream()/*System.out*/);
----------------------------------------------------------------------
Comment By: Dave Blaschke (blaschke-oss)
Date: 2008-02-26 21:25
Message:
Logged In: YES
user_id=1215427
Originator: NO
Patch is in HEAD and 1.3.5.
----------------------------------------------------------------------
Comment By: Endre Bak (ebak)
Date: 2007-11-06 17:30
Message:
Logged In: YES
user_id=1508775
Originator: NO
File Added:
patch.1804532_trace_for_both_req_res_should_be_traced_in_the_same_file.txt
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1804532&group_id=128809

Bugs item #1892103, was opened at 2008-02-12 17:53
Message generated for change (Settings changed) made by blaschke-oss
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1892103&group_id=128809
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Java Client (JSR48)
Group: Function
Status: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Endre Bak (ebak)
Assigned to: Endre Bak (ebak)
Summary: SLP improvements
Initial Comment:
This bug is the JSR48 version of "[ 1874440 ] sblimSLPClient PARSE_ERROR with large number of service urls"
----------------------------------------------------------------------
Comment By: Dave Blaschke (blaschke-oss)
Date: 2008-02-26 21:17
Message:
Logged In: YES
user_id=1215427
Originator: NO
Patch is in HEAD and 2.0.4.
----------------------------------------------------------------------
Comment By: Endre Bak (ebak)
Date: 2008-02-15 15:20
Message:
Logged In: YES
user_id=1508775
Originator: YES
changes:
- parser handles cut messages (those which can be sent by OpenSLP DA)
- UDP receive buffer is 64KB (maximum possible size)
- clean-ups
- improved error handling
- fix for Alexander's multicore bug
- UA drops unwanted response types and responses which don't have the
same XID like the request
About the error handling:
ServiceLocationEnumeration.next() and
ServiceLocationEnumeration.nextElement() can throw RuntimeException, which
must be caught and logged or absorbed. After handling the exception, the
iteration can be (should be) continued. This behaviour makes possible to
gather (almost) all the exceptions which has been thrown during the
operation.
File Added: patch.1892103_SLP_improvements.txt
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1892103&group_id=128809

Bugs item #1892041, was opened at 2008-02-12 16:08
Message generated for change (Comment added) made by blaschke-oss
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1892041&group_id=128809
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Java Client
Group: Function
>Status: Pending
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Dave Blaschke (blaschke-oss)
Assigned to: Dave Blaschke (blaschke-oss)
Summary: Basic/digest authentication problem for Japanese users
Initial Comment:
Bug reported by Tohru Hasegawa:
When we use Japanese username through an http basic authentication, sblim CIM client does not pass it to CIM server correctly. It causes no Japanese username can get access to CIM server even when we call the sblim CIM client from UTF-8 processes.
The sblim CIM client seems to handle the username as ASCII in org.sblim.wbem.http.WwwAuthInfo.java like the following.
-------------------------------------------------
} else if (iScheme.equalsIgnoreCase("Basic")) {
result.append("Basic ");
StringBuffer tmp = new StringBuffer();
tmp.append((iCredentials!=null && iCredentials.getUserName()!=null) ? iCredentials.getUserName() : "null");
tmp.append(':');
tmp.append((iCredentials!=null && iCredentials.getPassword()!=null) ? String.valueOf(iCredentials.getPassword()) : "null");
result.append(BASE64Encoder.encode(getBytes(tmp.toString(), "ASCII")));
}
-------------------------------------------------
My fix proposal for the basic authentication is;
-------------------------------------------------
} else if (iScheme.equalsIgnoreCase("Basic")) {
result.append("Basic ");
StringBuffer tmp = new StringBuffer();
tmp.append((iCredentials!=null && iCredentials.getUserName()!=null) ? iCredentials.getUserName() : "null");
tmp.append(':');
tmp.append((iCredentials!=null && iCredentials.getPassword()!=null) ? String.valueOf(iCredentials.getPassword()) : "null");
result.append(BASE64Encoder.encode(getBytes(tmp.toString())));
}
...
...
// Add getBytes() based on platform default
private static byte[] getBytes(String str) {
byte[] bytes ;
bytes = str.getBytes();
return bytes;
}
-------------------------------------------------
Also, I think we would need the same fix for the digest authentication.
----------------------------------------------------------------------
>Comment By: Dave Blaschke (blaschke-oss)
Date: 2008-02-26 21:28
Message:
Logged In: YES
user_id=1215427
Originator: YES
Patch is in HEAD and 1.3.5.
----------------------------------------------------------------------
Comment By: Dave Blaschke (blaschke-oss)
Date: 2008-02-14 02:41
Message:
Logged In: YES
user_id=1215427
Originator: YES
File Added: patch-1892041.txt
----------------------------------------------------------------------
Comment By: Dave Blaschke (blaschke-oss)
Date: 2008-02-13 21:17
Message:
Logged In: YES
user_id=1215427
Originator: YES
Well, this simple one-line fix ended up taking several days to verify.
The RFCs don't make any mention at all about what KIND of string is base64
encoded and sent out on the wire. In this customer's case the CIM Client
sent an ASCII string and Pegasus expected a UTF-8 string - doesn't work
with Japanese characters in the username or password, as was the case
here.
So I had to do some research and ask several questions of several folks.
Eventually I found out that Pegasus "expects base64 encoded utf8 strings"
so the better fix in is replace "ASCII" with "UTF-8" because just removing
"ASCII" will cause the default charset to be used which could be even worse
(EBCDIC anyone?)
Still have a few other outstanding questions about other CIMOMs, but it
looks like the two solutions are a) change "ASCII" to "UTF-8" or b) use
config option to specify.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1892041&group_id=128809

Bugs item #1874440, was opened at 2008-01-18 08:41
Message generated for change (Settings changed) made by blaschke-oss
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1874440&group_id=128809
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Java Client
Group: Function
>Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: chrisreich (chrisreich)
Assigned to: Nobody/Anonymous (nobody)
Summary: sblimSLPClient PARSE_ERROR with large number of service urls
Initial Comment:
In a test lab the SLP discovery with sblimCIMClient 1.3 end with exception:
2008-01-18 09:22:52.901+01:00 ERROR java.lang.RuntimeException: org.sblim.slp.ServiceLocationException: PARSE_ERROR(37-byte long string field is expected but only 3 bytes could be read!)
at org.sblim.slp.internal.ua.SLEnumerationImpl.hasMoreElements(SLEnumerationImpl.java:121)
at com.ibm.tpc.discovery.cimom.SLPScanner.getCIMOMServices(SLPScanner.java:112)
at com.ibm.tpc.discovery.cimom.SLPScanner.run(SLPScanner.java:410)
Caused by: org.sblim.slp.ServiceLocationException: PARSE_ERROR(37-byte long string field is expected but only 3 bytes could be read!)
at org.sblim.slp.internal.msg.SLPInputStream.readRawString(SLPInputStream.java:298)
at org.sblim.slp.internal.msg.SLPInputStream.readString(SLPInputStream.java:104)
at org.sblim.slp.internal.msg.SLPInputStream.readURL(SLPInputStream.java:185)
at org.sblim.slp.internal.msg.SLPInputStream.readUrlList(SLPInputStream.java:200)
at org.sblim.slp.internal.msg.ServiceReply.parse(ServiceReply.java:59)
at org.sblim.slp.internal.msg.MsgFactory$8.parse(MsgFactory.java:132)
at org.sblim.slp.internal.msg.MsgFactory.parse(MsgFactory.java:222)
at org.sblim.slp.internal.msg.MsgFactory.parse(MsgFactory.java:204)
at org.sblim.slp.internal.ua.DatagramRequester.mcastNegotiate(DatagramRequester.java:216)
at org.sblim.slp.internal.ua.DatagramRequester.run(DatagramRequester.java:160)
at java.lang.Thread.run(Thread.java:813) com.ibm.tpc.discovery.cimom.SLPScanner run SLP (Thread-84)
Further investigation showed that a long list of cimom urls (approx. > 30) retrieved by the client causes this.
The problem can be recreated by setting up a SA/DA that gives back a large number of urls.
This is a severe limitation and makes the client unusable.
----------------------------------------------------------------------
>Comment By: Dave Blaschke (blaschke-oss)
Date: 2008-02-26 21:28
Message:
Logged In: YES
user_id=1215427
Originator: NO
Patch is in HEAD and 1.3.5.
----------------------------------------------------------------------
Comment By: Endre Bak (ebak)
Date: 2008-02-15 16:38
Message:
Logged In: YES
user_id=1508775
Originator: NO
see 1892103 for details
File Added: patch.1874440_sblimSLPClient_PARSE_ERROR.txt.gz
----------------------------------------------------------------------
Comment By: RAVI GUMMADAVELLI (rgummada)
Date: 2008-01-25 20:26
Message:
Logged In: YES
user_id=1975918
Originator: NO
1. why is the iInBuf size limited to network MTU size ( 1500 bytes ).what
is the basis for setting it to this value?
2. is there a max limit of bytes (max message size) that can be put into
iInBuf, ( when iInbuf was increased to 8000, you were able to read all
urls, the problem would come back when message size exceeds 8000 bytes )
3. Though SLP allows TCP traffic for unicast, since UDP does not provide
sequencing of packets, entire message should arrive in right order. Can we
increase the iInBuf size to any arbitrary Max. value, or do we need to do
dynamic MTU discovery to support TCP traffic.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1874440&group_id=128809

Bugs item #1835847, was opened at 2007-11-21 15:38
Message generated for change (Comment added) made by blaschke-oss
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1835847&group_id=128809
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Java Client
Group: New Feature
>Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Endre Bak (ebak)
Assigned to: Robert ILLES (krawalter)
Summary: property for configuration file location
Initial Comment:
Currently on Windows there is no absolute path for the configuration file.
It causes inconveniences for TPC.
A property should be introduced which could predefine the location of the configuration file e.g.:-Dsblim.wbem.configFile=C:/cim.defaults
----------------------------------------------------------------------
>Comment By: Dave Blaschke (blaschke-oss)
Date: 2008-02-26 21:27
Message:
Logged In: YES
user_id=1215427
Originator: NO
Patch is in HEAD and 1.3.5.
----------------------------------------------------------------------
Comment By: Endre Bak (ebak)
Date: 2007-11-21 17:32
Message:
Logged In: YES
user_id=1508775
Originator: YES
The property name is "sblim.wbem.configFile".
File Added: patch.1835847_property_for_configuration_file_location.txt
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1835847&group_id=128809

Bugs item #1824094, was opened at 2007-11-01 14:27
Message generated for change (Comment added) made by blaschke-oss
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1824094&group_id=128809
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Java Client
Group: Function
>Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Murle Cleveland Meetze III (bubbameetze)
Assigned to: Robert ILLES (krawalter)
Summary: CIMNameSpace(String pURI) doesn't handle namespace properly.
Initial Comment:
CIMNameSpace constructor with a single String parameter pURI which I understand to be of the form:
protocol://hostname[:port]/file
Example: https://47.11.8.15:5989/root/cimv2
Calls the other constructor which accepts two Strings, one for host and the other for namespace however it calls it with the namespace as a null so this constructor always defaults to the hardcoded namespace root/cimv2.
public CIMNameSpace(String pURI) throws CIMException {
// TODO validate NameSpace
this(pURI, null);
}
So when one makes the call like this:
CIMNameSpace cns = new CIMNameSpace("http://10.5.2.91:5988/root/interop";);
The protocol, host and port come through ok, however the namespace gets thrown away. Suggest parsing the input to make sure that there is no namespace/file passed in at the end of the pURI.
----------------------------------------------------------------------
>Comment By: Dave Blaschke (blaschke-oss)
Date: 2008-02-26 21:26
Message:
Logged In: YES
user_id=1215427
Originator: NO
Patch is in HEAD and 1.3.5.
----------------------------------------------------------------------
Comment By: Endre Bak (ebak)
Date: 2007-11-05 14:21
Message:
Logged In: YES
user_id=1508775
Originator: NO
The patch is ready to handle IPv6 and overwrites CIMNameSpace's IPv6
modification which was committed before.
File Added:
patch.1824094_CIMNameSpace_String_pURI_doesnt_handle_namespace_properly.txt
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1824094&group_id=128809

Bugs item #1804532, was opened at 2007-09-28 21:44
Message generated for change (Settings changed) made by blaschke-oss
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1804532&group_id=128809
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Java Client
Group: Function
>Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Dave Wolfe (dwolfe2)
Assigned to: Robert ILLES (krawalter)
Summary: trace for both req/res should be traced in the same file
Initial Comment:
Currently the trace (if enabled) is traced - depending on if the item to trace is a request or a response - to the console-window or to a trace-file.
The trace for both requests and responses should be traced within the same
file.
Unfortunately the SBLIMCimClient does not provide a way to have incoming
requests and corresponding responses to be traced into a single
file.
This would be a very important feature where
you need to correlate requests with their responses.
As a workaround I recommend downloading the sourcecode for the SBLIMCimClient.
One file needs to be extracted and added into the org.sblim.cim.client package
included in Aperi.
Fetch org.sblim.wbem.xml.XMLDefaultHandlerImpl.java and modify line 187 as
follows:
private static Writer cOut = new
PrintWriter(GlobalProperties.getDebugOutputStream()/*System.out*/);
----------------------------------------------------------------------
>Comment By: Dave Blaschke (blaschke-oss)
Date: 2008-02-26 21:25
Message:
Logged In: YES
user_id=1215427
Originator: NO
Patch is in HEAD and 1.3.5.
----------------------------------------------------------------------
Comment By: Endre Bak (ebak)
Date: 2007-11-06 17:30
Message:
Logged In: YES
user_id=1508775
Originator: NO
File Added:
patch.1804532_trace_for_both_req_res_should_be_traced_in_the_same_file.txt
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1804532&group_id=128809

Bugs item #1892103, was opened at 2008-02-12 17:53
Message generated for change (Comment added) made by blaschke-oss
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1892103&group_id=128809
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Java Client (JSR48)
Group: Function
>Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Endre Bak (ebak)
Assigned to: Endre Bak (ebak)
Summary: SLP improvements
Initial Comment:
This bug is the JSR48 version of "[ 1874440 ] sblimSLPClient PARSE_ERROR with large number of service urls"
----------------------------------------------------------------------
>Comment By: Dave Blaschke (blaschke-oss)
Date: 2008-02-26 21:17
Message:
Logged In: YES
user_id=1215427
Originator: NO
Patch is in HEAD and 2.0.4.
----------------------------------------------------------------------
Comment By: Endre Bak (ebak)
Date: 2008-02-15 15:20
Message:
Logged In: YES
user_id=1508775
Originator: YES
changes:
- parser handles cut messages (those which can be sent by OpenSLP DA)
- UDP receive buffer is 64KB (maximum possible size)
- clean-ups
- improved error handling
- fix for Alexander's multicore bug
- UA drops unwanted response types and responses which don't have the
same XID like the request
About the error handling:
ServiceLocationEnumeration.next() and
ServiceLocationEnumeration.nextElement() can throw RuntimeException, which
must be caught and logged or absorbed. After handling the exception, the
iteration can be (should be) continued. This behaviour makes possible to
gather (almost) all the exceptions which has been thrown during the
operation.
File Added: patch.1892103_SLP_improvements.txt
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1892103&group_id=128809

Bugs item #1855726, was opened at 2007-12-21 13:53
Message generated for change (Comment added) made by blaschke-oss
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1855726&group_id=128809
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Java Client (JSR48)
Group: Function
>Status: Pending
Resolution: Fixed
Priority: 5
Private: No
Submitted By: MBauschert (mbauschert)
Assigned to: Dave Blaschke (blaschke-oss)
Summary: CIMInstance.deriveInstance is setting wrong CIMObjectPath
Initial Comment:
The method public CIMInstance deriveInstance(CIMProperty[] pPropA)
creates a new CIMObjectPath. During this process the CIMObjectPath is created by using the hostname as port
So after setting a (non-key)property via derviceInstance the ObjectPath is not the same like before the modification
----------------------------------------------------------------------
>Comment By: Dave Blaschke (blaschke-oss)
Date: 2008-02-26 21:16
Message:
Logged In: YES
user_id=1215427
Originator: NO
Patch is in HEAD and 2.0.4.
----------------------------------------------------------------------
Comment By: Dave Blaschke (blaschke-oss)
Date: 2008-02-11 16:49
Message:
Logged In: YES
user_id=1215427
Originator: NO
Patch committed to experimental branch
File Added: patch.1855726.txt
----------------------------------------------------------------------
Comment By: Dave Blaschke (blaschke-oss)
Date: 2008-01-10 20:10
Message:
Logged In: YES
user_id=1215427
Originator: NO
Sorry for the delay in responding, we are still coming up to speed as new
project owners...
So yes, the new CIMObjectPath should be created with:
new CIMObjectPath(
iObjPath.getScheme(), iObjPath.getHost(), iObjPath.getPort(),
iObjPath.getNamespace(), iObjPath.getObjectName(), null
),
instead of the current code. Will get this defect rolling through the
process...
----------------------------------------------------------------------
Comment By: MBauschert (mbauschert)
Date: 2007-12-21 13:54
Message:
Logged In: YES
user_id=1423646
Originator: YES
File Added: 1855726.patch
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1855726&group_id=128809

Bugs item #1849235, was opened at 2007-12-12 10:02
Message generated for change (Comment added) made by blaschke-oss
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1849235&group_id=128809
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Java Client (JSR48)
Group: Function
>Status: Pending
Resolution: Fixed
Priority: 3
Private: No
Submitted By: MBauschert (mbauschert)
Assigned to: Dave Blaschke (blaschke-oss)
Summary: DTStringWriter.writeSigned parameter pDigits is not used
Initial Comment:
currently the parameter pDigits is not used. Instead of this the value '3' is used
----------------------------------------------------------------------
>Comment By: Dave Blaschke (blaschke-oss)
Date: 2008-02-26 21:15
Message:
Logged In: YES
user_id=1215427
Originator: NO
Patch is in HEAD and 2.0.4.
----------------------------------------------------------------------
Comment By: Dave Blaschke (blaschke-oss)
Date: 2008-02-11 16:52
Message:
Logged In: YES
user_id=1215427
Originator: NO
Patch committed to experimental branch
File Added: patch.1849235.txt
----------------------------------------------------------------------
Comment By: Dave Blaschke (blaschke-oss)
Date: 2008-01-10 22:37
Message:
Logged In: YES
user_id=1215427
Originator: NO
Again, sorry for the delay in responding...
And yes, the last line in DTStringWriter.writeSigned should be:
write(pDigits, pNum);
Will get this defect rolling through the process as soon as I master the
process :-)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1849235&group_id=128809

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

CountryState

JavaScript is required for this form.

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details