Nabble - livetribe - dev

Re: SLP v2.1.0 release ready?

2009-12-07T12:26:05Z

Is there some way we can change the api by adding the new method and
having the old method perform some sane default? If not then I think
this would have to be a 3.0 release; not that I think it's bad but
kinda draconian for changing 1 method.

Regards,
Alan

On Dec 7, 2009, at 12:01 PM, Simone Bordet wrote:

> Hi,
>
> On Mon, Dec 7, 2009 at 20:42, Alan D. Cabrera <adc@...>
> wrote:
>> I think that interop is important too. Why do we need to change
>> the API?
>
> The failing interop cases are de-registering and updating a service.
> The change would be:
>
> IServiceAgent.deregister(ServiceURL serviceURL, String language)
>
> to:
>
> IServiceAgent.deregister(ServiceURL serviceURL, Scopes scopes,
> String language)
>
> or, perhaps:
>
> IServiceAgent.deregister(ServiceInfo service)
>
> And likewise for add/removeAttributes().
>
> OpenSLP requires that you deregister the service with the same scopes
> you registered it.
>
> Simon
> --
> http://bordet.blogspot.com
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless. Victoria Livschitz
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: SLP v2.1.0 release ready?

2009-12-07T12:01:49Z

Hi,

On Mon, Dec 7, 2009 at 20:42, Alan D. Cabrera <adc@...> wrote:
> I think that interop is important too. Why do we need to change the API?

The failing interop cases are de-registering and updating a service.
The change would be:

IServiceAgent.deregister(ServiceURL serviceURL, String language)

to:

IServiceAgent.deregister(ServiceURL serviceURL, Scopes scopes, String language)

or, perhaps:

IServiceAgent.deregister(ServiceInfo service)

And likewise for add/removeAttributes().

OpenSLP requires that you deregister the service with the same scopes
you registered it.

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: SLP v2.1.0 release ready?

2009-12-07T11:42:07Z

On Dec 7, 2009, at 11:39 AM, Simone Bordet wrote:

> Hi,
>
> On Mon, Dec 7, 2009 at 17:18, Alan D. Cabrera <adc@...>
> wrote:
>>
>> On Oct 30, 2009, at 12:45 PM, Simone Bordet wrote:
>>
>>> Hi,
>>>
>>> On Thu, Oct 29, 2009 at 02:26, Alan D. Cabrera <adc@...>
>>> wrote:
>>>>
>>>> I think we've got something good enough for a release. What do you
>>>> think?
>>>
>>> I agree. I would like to review the code and write a bit more tests,
>>> so I think by middle November could be a good date.
>>
>> I'm just about finished with the documentation. How are things w/
>> you?
>
> Found and fixed a couple of bugs, but somehow interoperability with
> OpenSLP is lost in at least one case.
> It's actually a divergence in spec interpretation, but fixing it would
> end up in a change in the API, which is bad...
>
> I am for changing the API and achieving interop again; your thoughts ?

I think that interop is important too. Why do we need to change the
API?

Regards,
Alan

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: SLP v2.1.0 release ready?

2009-12-07T11:39:07Z

Hi,

On Mon, Dec 7, 2009 at 17:18, Alan D. Cabrera <adc@...> wrote:

>
> On Oct 30, 2009, at 12:45 PM, Simone Bordet wrote:
>
>> Hi,
>>
>> On Thu, Oct 29, 2009 at 02:26, Alan D. Cabrera <adc@...>
>> wrote:
>>>
>>> I think we've got something good enough for a release. What do you
>>> think?
>>
>> I agree. I would like to review the code and write a bit more tests,
>> so I think by middle November could be a good date.
>
> I'm just about finished with the documentation. How are things w/ you?

Found and fixed a couple of bugs, but somehow interoperability with
OpenSLP is lost in at least one case.
It's actually a divergence in spec interpretation, but fixing it would
end up in a change in the API, which is bad...

I am for changing the API and achieving interop again; your thoughts ?

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: SLP v2.1.0 release ready?

2009-12-07T08:18:07Z

On Oct 30, 2009, at 12:45 PM, Simone Bordet wrote:

> Hi,
>
> On Thu, Oct 29, 2009 at 02:26, Alan D. Cabrera <adc@...>
> wrote:
>> I think we've got something good enough for a release. What do you
>> think?
>
> I agree. I would like to review the code and write a bit more tests,
> so I think by middle November could be a good date.

I'm just about finished with the documentation. How are things w/ you?

Regards,
Alan

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: SLP v2.1.0 release ready?

2009-10-30T13:04:06Z

Ok. This will also give me time to write some examples/documentation
for OSGi.

Regards,
Alan

On Oct 30, 2009, at 12:45 PM, Simone Bordet wrote:

> Hi,
>
> On Thu, Oct 29, 2009 at 02:26, Alan D. Cabrera <adc@...>
> wrote:
>> I think we've got something good enough for a release. What do you
>> think?
>
> I agree. I would like to review the code and write a bit more tests,
> so I think by middle November could be a good date.
>
> Simon
> --
> http://bordet.blogspot.com
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless. Victoria Livschitz
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: SLP v2.1.0 release ready?

2009-10-30T12:45:02Z

Hi,

On Thu, Oct 29, 2009 at 02:26, Alan D. Cabrera <adc@...> wrote:
> I think we've got something good enough for a release. What do you think?

I agree. I would like to review the code and write a bit more tests,
so I think by middle November could be a good date.

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

SLP v2.1.0 release ready?

2009-10-28T18:26:26Z

I think we've got something good enough for a release. What do you
think?

Regards,
Alan

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[jira] Resolved: (LIVETRIBE-62) OSGi Integration

2009-10-28T18:25:26Z

[ http://jira.codehaus.org/browse/LIVETRIBE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alan Cabrera resolved LIVETRIBE-62.
-----------------------------------

Resolution: Fixed

> OSGi Integration
> ----------------
>
> Key: LIVETRIBE-62
> URL: http://jira.codehaus.org/browse/LIVETRIBE-62
> Project: LiveTribe
> Issue Type: New Feature
> Reporter: Alan Cabrera
> Assignee: Alan Cabrera
> Fix For: SLP 2.1.0
>
>
> Create an OSGi bundle that wraps the "core" jar. Also this bundle will take its configuration from the Configuration Admin Service.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[jira] Resolved: (LIVETRIBE-62) OSGi Integration

2009-10-28T18:25:26Z

ServiceEvent and ServiceNotificationEvent

2009-10-21T09:17:37Z

These seem to be quite similar. Would it be possible to merge and
reuse a single event?

Regards,
Alan

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

SLP build seems to be broken

2009-10-19T12:10:39Z

It doesn't build for me on my Macs or SUSE machines.

Regards,
Alan

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: SLP UDP and MTU

2009-10-19T12:08:12Z

On Oct 19, 2009, at 10:43 AM, Simone Bordet wrote:

> Hi,
>
> On Mon, Oct 19, 2009 at 18:31, Alan D. Cabrera <adc@...>
> wrote:
>>
>> On Oct 19, 2009, at 1:41 AM, Simone Bordet wrote:
>>
>>> Hi,
>>>
>>> On Sat, Oct 17, 2009 at 04:21, Alan D. Cabrera <adc@...>
>>> wrote:
>>>>
>>>> So it seems that I should truncate the byte array to the MTU size
>>>> and set
>>>> the overflow bit on.
>>>
>>> But I think the way you do it is wrong ?
>>> You cannot truncate in the middle of the bytes since otherwise the
>>> client will choke.
>>
>> Are you sure? Does OpenSLP choke or is it just our clients that
>> will choke?
>> The spec says a vague truncate.
>>
>>> I have a better fix for this in trunk, which I can backport to the
>>> branch, hopefully.
>>
>> At first glance I see a lot of serializing and deserializing going
>> on.
>> Strikes me as odd. Can you explain what's going on?
>
> Take for example AttrRply. Its format says 2 bytes for error code, 2
> bytes for length, then a variable length bytes for the attributes.
>
> Say the attribute length, once serialized, is 2073 bytes. Say MTU is
> 1400
>
> You cannot truncate the packet with
> 00 - error code
> 2073 - length
> 1396 bytes - attributes
>
> where 1396 == 1400 - 2 bytes for error code - 2 bytes for length
> (let's ignore the message header for now).
>
> Note that you cannot say "I wait for the next message then read the
> rest", as the next message via UDP may not arrive, or be another
> unrelated one.
> The spec says that if you see an overflow message, you can connect via
> TCP, or use what's in the message, but that content of the message
> should be syntactically correct.
>
> That's my interpretation.

Yeah, it's vague but I think your interpretation is the safer one.

But my question was that the implementation that we have now
constantly serialize and de-serialize. This strikes me as a bit of
overkill. I was wondering if the message POJOs and their elements
already know their byte sizes a priori and just have method called
byteSize().

Regards,
Alan

Regards,
Alan

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: SLP UDP and MTU

2009-10-19T10:43:34Z

Hi,

On Mon, Oct 19, 2009 at 18:31, Alan D. Cabrera <adc@...> wrote:

>
> On Oct 19, 2009, at 1:41 AM, Simone Bordet wrote:
>
>> Hi,
>>
>> On Sat, Oct 17, 2009 at 04:21, Alan D. Cabrera <adc@...>
>> wrote:
>>>
>>> So it seems that I should truncate the byte array to the MTU size and set
>>> the overflow bit on.
>>
>> But I think the way you do it is wrong ?
>> You cannot truncate in the middle of the bytes since otherwise the
>> client will choke.
>
> Are you sure? Does OpenSLP choke or is it just our clients that will choke?
> The spec says a vague truncate.
>
>> I have a better fix for this in trunk, which I can backport to the
>> branch, hopefully.
>
> At first glance I see a lot of serializing and deserializing going on.
> Strikes me as odd. Can you explain what's going on?

Take for example AttrRply. Its format says 2 bytes for error code, 2
bytes for length, then a variable length bytes for the attributes.

Say the attribute length, once serialized, is 2073 bytes. Say MTU is 1400

You cannot truncate the packet with
00 - error code
2073 - length
1396 bytes - attributes

where 1396 == 1400 - 2 bytes for error code - 2 bytes for length
(let's ignore the message header for now).

Note that you cannot say "I wait for the next message then read the
rest", as the next message via UDP may not arrive, or be another
unrelated one.
The spec says that if you see an overflow message, you can connect via
TCP, or use what's in the message, but that content of the message
should be syntactically correct.

That's my interpretation.

I don't recall if OpenSLP handles overflow at all, will check.

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Classloading mumbo jumbo

2009-10-19T09:58:59Z

On Oct 19, 2009, at 1:34 AM, Simone Bordet wrote:

> Hi,
>
> On Fri, Oct 16, 2009 at 23:52, Alan D. Cabrera <adc@...>
> wrote:
>> If you look at the last test that I checked in you'll see that I
>> have to set
>> the context classloader. Not exactly elegant. What do others think?
>
> Why you had to set the context classloader ?
> Is this needed by the user of JUnit4 ?
> AFAICT, livetribe-slp does not need the set of the context
> classloader, so this is either an artifact of the tests or of osgi ?

It's an OSGi thing. Your SLP factory building code uses that
classloader to load the classes. PAX Exam runs the unit tests as if
they are bundles. So when the test executes the context classloader
is the unit test bundle's bundle classloader. The problem is that the
default properties file is not in a package that this classloader can
pick up.

Maybe a solution would be to put the properties file in
org.livetribe.slp.

> Can you also explain why we need to depend on 3 other project for
> just 2 tests ?

Well, there are going to be a more tests.

> What benefits bring ops4j

Runs tests in an OSGi container.

> junit4

Needed by ops4j but I think it would be nice if they supported
testingng; going to look into this.

> hamcrest ?
> For example, the overflow test written without hamcrest is shorter and
> more speaking.

I like hamcrest in general. I agree your test was better.

Regards,
Alan

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Last SLP changes

2009-10-19T09:43:17Z

On Oct 19, 2009, at 7:50 AM, Simone Bordet wrote:

> Hi,
>
> repeated plugins fixed.
>
> IntelliJ 8.1.3 loads the pom fine.
> Try to delete the idea files and then Open Project and choose the
> pom.xml.

Yeah, that's what I did. However, it loads fine for me at work. I'll
delete my caches at home and see if that fixes it.

Regards,
Alan

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: SLP UDP and MTU

2009-10-19T09:31:03Z

On Oct 19, 2009, at 1:41 AM, Simone Bordet wrote:

> Hi,
>
> On Sat, Oct 17, 2009 at 04:21, Alan D. Cabrera <adc@...>
> wrote:
>> So it seems that I should truncate the byte array to the MTU size
>> and set
>> the overflow bit on.
>
> But I think the way you do it is wrong ?
> You cannot truncate in the middle of the bytes since otherwise the
> client will choke.

Are you sure? Does OpenSLP choke or is it just our clients that will
choke? The spec says a vague truncate.

> I have a better fix for this in trunk, which I can backport to the
> branch, hopefully.

At first glance I see a lot of serializing and deserializing going
on. Strikes me as odd. Can you explain what's going on?

Regards,
Alan

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Last SLP changes

2009-10-19T07:50:43Z

Hi,

repeated plugins fixed.

IntelliJ 8.1.3 loads the pom fine.
Try to delete the idea files and then Open Project and choose the pom.xml.

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Last SLP changes

2009-10-19T07:16:39Z

On Oct 19, 2009, at 7:11 AM, Simone Bordet wrote:

> Hi,
>
> On Mon, Oct 19, 2009 at 16:06, Alan D. Cabrera <adc@...>
> wrote:
>>
>> On Oct 19, 2009, at 6:04 AM, Simone Bordet wrote:
>>
>>> Hi,
>>>
>>> I have committed the changes I had locally to fix a bunch of bugs,
>>> among which the latest reported.
>>>
>>> Alan, I have also reorganized the poms: now all OSGi dependencies
>>> are
>>> in the osgi module and not in the parent pom.
>>
>> Usually all of the dependencies versions for the whole project are
>> in the
>> root pom. But since these two modules are kinda orthogonal, in a
>> way, it
>> seems ok to push the versions up.
>>
>> The a few, maybe only one, plugins in the build element are
>> redundantly
>> repeated in the modules.
>
> Sorry don't follow...
> core does not depend on osgi, so I see no need to put in the root pom
> a dependency management for osgi, that's why I pushed it to the osgi
> module.
>
> Which are the repeated plugins ?

Something is busted w/ these POMs in that IntelliJ cannot load them up
and create a project. I'll look at this later today or, since you
"busted" them, you could do that for me. (pretty please) :D

Regards,
Alan

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Last SLP changes

2009-10-19T07:14:09Z

On Oct 19, 2009, at 7:11 AM, Simone Bordet wrote:

Since these are not shared it makes sense. However for larger
projects one would put all the dependencies and their versions at the
root one knows all the deps in the project and to make sure there are
no deps w/ different versions.

Again, in this case it's not a big deal.

>
> Which are the repeated plugins ?

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
<showDeprecation>true</showDeprecation>
<showWarnings>true</showWarnings>
<compilerArgument>-Xlint:all,-serial,-unchecked</
compilerArgument>
</configuration>
</plugin>

Regards,
Alan

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: MEGA checkins

2009-10-19T07:13:29Z

Hi,

On Mon, Oct 19, 2009 at 16:10, Alan D. Cabrera <adc@...> wrote:
> Ideally, it would have been nice to break these out into separate checkins
> per issue.

I know, but I had it locally well before the issues and they are kind
of intertwined.
But I'll promise to be kinder next time :)

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Last SLP changes

2009-10-19T07:11:18Z

Hi,

On Mon, Oct 19, 2009 at 16:06, Alan D. Cabrera <adc@...> wrote:

>
> On Oct 19, 2009, at 6:04 AM, Simone Bordet wrote:
>
>> Hi,
>>
>> I have committed the changes I had locally to fix a bunch of bugs,
>> among which the latest reported.
>>
>> Alan, I have also reorganized the poms: now all OSGi dependencies are
>> in the osgi module and not in the parent pom.
>
> Usually all of the dependencies versions for the whole project are in the
> root pom. But since these two modules are kinda orthogonal, in a way, it
> seems ok to push the versions up.
>
> The a few, maybe only one, plugins in the build element are redundantly
> repeated in the modules.

Sorry don't follow...
core does not depend on osgi, so I see no need to put in the root pom
a dependency management for osgi, that's why I pushed it to the osgi
module.

Which are the repeated plugins ?

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

MEGA checkins

2009-10-19T07:10:19Z

Ideally, it would have been nice to break these out into separate checkins per issue.

Regards,
Alan

On Oct 19, 2009, at 5:50 AM, ""@codehaus.org wrote:

Revision
575
Author
Date
2009-10-19 07:50:25 -0500 (Mon, 19 Oct 2009)
Log Message
Fixed LIVETRIBE-15, LIVETRIBE-16, LIVETRIBE-72, LIVETRIBE-73.
Modified Paths
garden/livetribe-slp/trunk/core/pom.xml
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/Attributes.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/ServiceType.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/da/DirectoryAgentInfo.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/da/StandardDirectoryAgentServer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/sa/StandardServiceAgentClient.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/sa/StandardServiceAgentServer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/settings/Keys.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/SrvAckPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/SrvRplyPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/TCPAttrRplyPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/TCPSrvAckPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/UDPSrvAckPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/da/MulticastDAAdvertPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/da/TCPSrvRplyPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/da/UDPSrvRplyPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/filter/Filter.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/msg/AttrRply.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/msg/DAAdvert.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/msg/Message.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/msg/SrvAck.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/msg/SrvRply.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/net/BroadcastSocketUDPConnector.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/net/BroadcastSocketUDPConnectorServer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/net/MulticastSocketUDPConnectorServer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/net/SocketTCPConnector.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/net/SocketTCPConnectorServer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/net/SocketUDPConnector.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/net/SocketUDPConnectorServer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/net/UDPConnector.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/sa/AbstractServiceAgent.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/sa/UDPSrvRplyPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/ua/AbstractUserAgent.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/ua/IUserAgent.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/ua/MulticastAttrRqstPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/ua/MulticastSrvRqstPerformer.java
garden/livetribe-slp/trunk/core/src/main/resources/livetribe-slp.properties
garden/livetribe-slp/trunk/core/src/test/java/org/livetribe/slp/AttributesTest.java
garden/livetribe-slp/trunk/core/src/test/java/org/livetribe/slp/ServiceTypeTest.java
garden/livetribe-slp/trunk/core/src/test/java/org/livetribe/slp/da/StandardDirectoryAgentServerTest.java
garden/livetribe-slp/trunk/core/src/test/java/org/livetribe/slp/sa/StandardServiceAgentServerTest.java
garden/livetribe-slp/trunk/core/src/test/java/org/livetribe/slp/sa/StandardServiceAgentTest.java
garden/livetribe-slp/trunk/core/src/test/java/org/livetribe/slp/spi/da/UDPSrvRplyPerformerTest.java
garden/livetribe-slp/trunk/core/src/test/java/org/livetribe/slp/spi/msg/MessageTest.java
garden/livetribe-slp/trunk/core/src/test/java/org/livetribe/slp/spi/sa/UDPSrvRplyPerformerTest.java
garden/livetribe-slp/trunk/core/src/test/java/org/livetribe/slp/ua/StandardUserAgentClientTest.java
garden/livetribe-slp/trunk/core/src/test/java/org/livetribe/slp/ua/StandardUserAgentTest.java
garden/livetribe-slp/trunk/osgi/pom.xml
garden/livetribe-slp/trunk/pom.xml
Added Paths
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/AttrRplyPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/SrvTypeRplyPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/TCPSrvTypeRplyPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/UDPAttrRplyPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/UDPSrvTypeRplyPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/msg/SrvTypeRply.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/msg/SrvTypeRqst.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/sa/UnicastSrvDeRegPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/sa/UnicastSrvRegPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/ua/MulticastSrvTypeRqstPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/ua/SrvRqstPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/ua/SrvTypeRqstPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/ua/UnicastAttrRqstPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/ua/UnicastSrvRqstPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/ua/UnicastSrvTypeRqstPerformer.java
garden/livetribe-slp/trunk/core/src/test/java/org/livetribe/slp/TestNGListener.java
garden/livetribe-slp/trunk/core/src/test/java/org/livetribe/slp/sa/StandardServiceAgentClientTest.java
Removed Paths
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/sa/TCPSrvDeRegPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/sa/TCPSrvRegPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/sa/UDPSrvDeRegPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/sa/UDPSrvRegPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/ua/TCPAttrRqstPerformer.java
garden/livetribe-slp/trunk/core/src/main/java/org/livetribe/slp/spi/ua/TCPSrvRqstPerformer.java
garden/livetribe-slp/trunk/core/src/test/java/org/livetribe/slp/mock/
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email

Re: Last SLP changes

2009-10-19T07:06:09Z

On Oct 19, 2009, at 6:04 AM, Simone Bordet wrote:

> Hi,
>
> I have committed the changes I had locally to fix a bunch of bugs,
> among which the latest reported.
>
> Alan, I have also reorganized the poms: now all OSGi dependencies are
> in the osgi module and not in the parent pom.

Usually all of the dependencies versions for the whole project are in
the root pom. But since these two modules are kinda orthogonal, in a
way, it seems ok to push the versions up.

The a few, maybe only one, plugins in the build element are
redundantly repeated in the modules.

>
> I am in favor of fixing/implementing a couple of other bugs/features,
> and then release 2.1.0 instead of releasing 2.0.2.
> Comments ?

Since 2.1.0 is totally backward compatible w/ 2.0.x I think that just
releasing 2.1.0 should be fine.

Regards,
Alan

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[jira] Created: (LIVETRIBE-77) Broken Failover Logic in Livetribe SLP

2009-10-19T06:06:26Z

Broken Failover Logic in Livetribe SLP
--------------------------------------

Key: LIVETRIBE-77
URL: http://jira.codehaus.org/browse/LIVETRIBE-77
Project: LiveTribe
Issue Type: Bug
Components: SLP
Affects Versions: SLP 2.0.1
Reporter: Simone Bordet

As reported by Nicholas White on the mailing list:

There is a bug in the SLP Server code that causes a problem...

TO REPRODUCE (using the standard directory server, and the client and
servers here: http://livetribe.codehaus.org/SLP-Examples-JMX

(1) Start the directory server, client and server. They should all
find each other
(2) Kill the directory server and the client
(3) Start the directory server, then the client
** the client will not find the server**

WHY

When the directory server restarts, it sends advertising messages.
However, the server doesn't respond as it thinks it has already
registered with that server. In the meantime, it advertises itself via
multicast. When the client is restarted, it finds the directory server
and interrogates it, so doesn't read the server's multicast messages.

CODE

In DirectoryAgentInfoCache, the following method is called when a
server receives a directory server advertisement:

public void handle(DirectoryAgentInfo directoryAgent)
{
if (directoryAgent.isShuttingDown())
{
DirectoryAgentInfo removed = remove(directoryAgent.getKey());
if (removed != null) notifyDirectoryAgentDied(directoryAgent);
}
else
{
DirectoryAgentInfo existing = add(directoryAgent);
if (existing == null)
notifyDirectoryAgentBorn(directoryAgent); //*******REMOVE if(existing
== null)*******
}
}

In the above situation, existing is not null when the restarted
directory agent sends its advertisements, so the server never
responds. To fix this, remove 'if (existing == null)' so the server
always tells the directory agent what services it has.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[jira] Created: (LIVETRIBE-77) Broken Failover Logic in Livetribe SLP

2009-10-19T06:06:26Z

Last SLP changes

2009-10-19T06:04:38Z

Hi,

I have committed the changes I had locally to fix a bunch of bugs,
among which the latest reported.

Alan, I have also reorganized the poms: now all OSGi dependencies are
in the osgi module and not in the parent pom.

I am in favor of fixing/implementing a couple of other bugs/features,
and then release 2.1.0 instead of releasing 2.0.2.
Comments ?

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[jira] Created: (LIVETRIBE-76) Implement command line tools

2009-10-19T06:00:26Z

Implement command line tools
----------------------------

Key: LIVETRIBE-76
URL: http://jira.codehaus.org/browse/LIVETRIBE-76
Project: LiveTribe
Issue Type: New Feature
Components: SLP
Affects Versions: SLP 2.0.1
Reporter: Simone Bordet

It would be useful to have command line tools to be able to check the functionality of SLP components, similar to the command line tools provided by OpenSLP.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[jira] Created: (LIVETRIBE-76) Implement command line tools

2009-10-19T06:00:26Z

[jira] Resolved: (LIVETRIBE-73) Handle correctly overflows in UDP communication

2009-10-19T05:58:27Z

[ http://jira.codehaus.org/browse/LIVETRIBE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Simone Bordet resolved LIVETRIBE-73.
-------------------------------------

Resolution: Fixed
Fix Version/s: SLP 2.1.0

Messages that may overflow are not checked and properly truncated.

> Handle correctly overflows in UDP communication
> -----------------------------------------------
>
> Key: LIVETRIBE-73
> URL: http://jira.codehaus.org/browse/LIVETRIBE-73
> Project: LiveTribe
> Issue Type: Improvement
> Components: SLP
> Affects Versions: SLP 2.0.1
> Reporter: Simone Bordet
> Assignee: Simone Bordet
> Fix For: SLP 2.1.0
>
>
> Several messages that are returned via UDP may overflow. In this case, the overflow bit must be set and the message reduced to fit.

[jira] Resolved: (LIVETRIBE-73) Handle correctly overflows in UDP communication

2009-10-19T05:58:27Z

[jira] Resolved: (LIVETRIBE-72) SLP - the unicast point-to-point sending doesn't check the MTU

2009-10-19T05:56:27Z

[ http://jira.codehaus.org/browse/LIVETRIBE-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Simone Bordet resolved LIVETRIBE-72.
-------------------------------------

Resolution: Fixed
Fix Version/s: (was: SLP 2.0.2)

Resolved as part of LIVETRIBE-73.

> SLP - the unicast point-to-point sending doesn't check the MTU
> --------------------------------------------------------------
>
> Key: LIVETRIBE-72
> URL: http://jira.codehaus.org/browse/LIVETRIBE-72
> Project: LiveTribe
> Issue Type: Bug
> Components: SLP
> Affects Versions: SLP 2.0.1
> Reporter: Nicholas White
> Assignee: Simone Bordet
> Fix For: SLP 2.1.0
>
>
> This is in org.livetribe.slp.spi.sa.UDPSrvRplyPerformer:
> {code}
> public void perform(InetSocketAddress remoteAddress, ServiceAgentInfo serviceAgent, Message message, List<? extends ServiceInfo> services)
> {
> // TODO: must be sure to fit the MTU in case of many services
> SrvRply srvRply = newSrvRply(serviceAgent, message, services);
> byte[] bytes = srvRply.serialize();
> udpConnector.unicastSend(serviceAgent.getHost(), remoteAddress, bytes);
> }
> {code}
> The UDPConnector indeed doesn't check the MTU before sending the packet - the receiver then truncates and throws an exception as the length field doesn't match the length of the packet.

[jira] Resolved: (LIVETRIBE-72) SLP - the unicast point-to-point sending doesn't check the MTU

2009-10-19T05:56:27Z

[jira] Resolved: (LIVETRIBE-16) Implement handling of SrvTypeRqst/SrvTypeRply messages

2009-10-19T05:56:26Z

[ http://jira.codehaus.org/browse/LIVETRIBE-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Simone Bordet resolved LIVETRIBE-16.
-------------------------------------

Resolution: Fixed
Fix Version/s: SLP 2.1.0
Assignee: Simone Bordet

Implemented in UserAgent and DirectoryAgent.

> Implement handling of SrvTypeRqst/SrvTypeRply messages
> ------------------------------------------------------
>
> Key: LIVETRIBE-16
> URL: http://jira.codehaus.org/browse/LIVETRIBE-16
> Project: LiveTribe
> Issue Type: Improvement
> Components: SLP
> Reporter: Simone Bordet
> Assignee: Simone Bordet
> Priority: Minor
> Fix For: SLP 2.1.0
>
>
> SrvTypeRqst/SrvTypeRply messages are optional in SLP.
> UserAgents should be able to send SrvTypeRqst and interpret SrvTypeRply, while ServiceAgent and DirectoryAgent should be able to interpret SrvTypeRqst and send SrvTypeRply.

[jira] Resolved: (LIVETRIBE-16) Implement handling of SrvTypeRqst/SrvTypeRply messages

2009-10-19T05:56:26Z