You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@mina.apache.org by "Michael Jakl (JIRA)" <ji...@apache.org> on 2009/07/05 12:26:14 UTC

[jira] Created: (VYSPER-92) Stanzas don't get enriched with a "from" Attribute when the client omits it.

Stanzas don't get enriched with a "from" Attribute when the client omits it.
----------------------------------------------------------------------------

                 Key: VYSPER-92
                 URL: https://issues.apache.org/jira/browse/VYSPER-92
             Project: VYSPER
          Issue Type: Bug
          Components: core protocol
            Reporter: Michael Jakl
            Assignee: Bernd Fondermann


RFC3920 9.1.2:

When a server receives an XML stanza within the context of an authenticated stream qualified by the 'jabber:client' namespace, it MUST do one of the following:

   1. validate that the value of the 'from' attribute provided by the client is that of a connected resource for the associated entity
   2. add a 'from' address to the stanza whose value is the bare JID (<no...@domain>) or the full JID (<node@domain/resource>) determined by the server for the connected resource that generated the stanza (see Determination of Addresses).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Immutable objects [WAS: Re: [jira] Closed: (VYSPER-92) Stanzas don't get enriched...]

Posted by Bernd Fondermann <be...@googlemail.com>.

On Mon, Jul 6, 2009 at 22:52, Michael Jakl<ja...@gmail.com> wrote:
> Hi!
>
> On Mon, Jul 6, 2009 at 10:10, Bernd Fondermann<bf...@brainlounge.de> wrote:
>> Michael Jakl wrote:
>>> On Mon, Jul 6, 2009 at 07:01, Bernd
>>> Fondermann<be...@googlemail.com> wrote:
>>>> On Sun, Jul 5, 2009 at 16:38, Michael Jakl (JIRA)<ji...@apache.org> wrote:
>>>>> Actually I don't think immutable object make much sense in an imperative language, even though I know the advantages of immutable objects due to my experience with functional programming.
>>>> Wow, don't let your prof read this ;-)
>>>>
>>>> Java is an object-oriented languages. A major feature of OO is data
>>>> encapsulation, immutable objects are a certain strict kind of data
>>>> encapsulation.
>>>
>>> Encapsulation and immutable objects don't have much common ground, IMHO.
>>> Encapsulation is *hiding* the internals of an object, returning immutable
>>> objects is not.
>>
>> Of course they have (IMHO). Object = behavior + data. Immutable object =
>> don't change my data! how these data is represented internally is up to
>> the (immutable) object. If we decide to check for duplicates in the
>> constructor, that's internal behavoir.
>
> Hmm, it seems we're already talking on different levels. By returning
> the list of
> attributes we're exposing how XMLElement stores its attributes. That's
> what I meant
> with the difference between immutable and encapsulation.

Without data encapsulation, you cannot have immutable objects. The
getter-side of things has nothing to do with immutable as long as you
don't expose your internal representation as a mutual object. (And I'm
sure you noted that XMLElement returns an unmodifyable (=immutable)
attribute list! This is fixated in the constructor.).

So with Java we have protected and private fields and can lock down
object to be immutable. All by the means of encapsulation.

>
>>> This is exactly the reason why we can't easily change the list of Attribute
>>> objects to a set of Attribute objects in XMLElement, even when it is immutable:
>>> we told the world that we use a List<Attribute> to store them.
>>
>> That's more a contract problem. Even if we there were accessors for
>> attributes (mutability), the internal representation would not be more
>> easy to change from List -> Set.
>
> Agreed, but again, the different levels. If we didn't expose the attribute-list
> to the outside there wouldn't be a problem in changing the List to a Set.

Well we could change our code like this:
 Set<Attributes> getAttributes() { return new HashSet(attributes)); }

This would only change the contract, not the internal representation.

And what about changing List/Set to Collection, the superinterface of both?

>>> I don't think we should be defensive programmers, if we give out objects we
>>> give them out to be manipulated.
>>
>> Not in this case.
>>
>> Example: A handler processes a message which he distributes (broadcasts)
>> to a list of recipients.
>>  The developer decides to iterate through the list of recepients and
>> reuses the incoming stanza by setting the proper 'to' attributes and
>> immediately hands the stanza over to delivery, expecting that the stanza
>> is processed and gone when the delivery call returns. He continues to
>> process with the next recepient. His unit tests succeed!
>>  In production, recepients complain because they don't get messages or
>> get a lot of duplicated messages at once.
>>  What went wrong?
>
> Yes, that's indeed a problem. But one, every (powerful) language suffers, you
> can do a lot of fancy things with C, but you can also make some veeery bad
> mistakes with it.

That's why I'm exploiting the immutable pattern here.

>> I'm even more defensive than making Stanza immutable! For example, you
>> cannot call StanzaBuilder.getFinalStanza() more than once without
>> getting an exception.
>>
>>> If we don't want them to be manipulated,
>>> don't expose them.
>>
>> How can we not expose Stanza objects to Handlers?
>
> Now you got me completely. How 'bout making it, aehm, immutable ;).
>
> Frankly, I wouldn't care about malicious (or misbehaving modules) such errors
> are easily spotted and fixed.

Frankly, I had problems easily spotting those problems in the past.

> Changing objects is something we do all the time,
> this doesn't mean we have to do it via getters/setters, but via other methods
> like "addNode" or "handleSet".
>
> Just to make it clear: I didn't mean to open an object up to any change (that
> would be generating getters/setters for all members), but to make sure the
> changes that are necessary are possible - in a safe way.
>
> We can't secure our objects for everything we didn't think of, most of the time
> we're restricting ourselves instead of keeping others from doing bad things.
> Granted, this is sometimes a good thing, one no commercial software company
> would like to miss.
>
> Thanks for the insights, the arguments did change much of my point of view.

Thank you for discussing this.

  Bernd

Re: Immutable objects [WAS: Re: [jira] Closed: (VYSPER-92) Stanzas don't get enriched...]

Posted by Michael Jakl <ja...@gmail.com>.

Hi!

On Mon, Jul 6, 2009 at 10:10, Bernd Fondermann<bf...@brainlounge.de> wrote:
> Michael Jakl wrote:
>> On Mon, Jul 6, 2009 at 07:01, Bernd
>> Fondermann<be...@googlemail.com> wrote:
>>> On Sun, Jul 5, 2009 at 16:38, Michael Jakl (JIRA)<ji...@apache.org> wrote:
>>>> Actually I don't think immutable object make much sense in an imperative language, even though I know the advantages of immutable objects due to my experience with functional programming.
>>> Wow, don't let your prof read this ;-)
>>>
>>> Java is an object-oriented languages. A major feature of OO is data
>>> encapsulation, immutable objects are a certain strict kind of data
>>> encapsulation.
>>
>> Encapsulation and immutable objects don't have much common ground, IMHO.
>> Encapsulation is *hiding* the internals of an object, returning immutable
>> objects is not.
>
> Of course they have (IMHO). Object = behavior + data. Immutable object =
> don't change my data! how these data is represented internally is up to
> the (immutable) object. If we decide to check for duplicates in the
> constructor, that's internal behavoir.

Hmm, it seems we're already talking on different levels. By returning
the list of
attributes we're exposing how XMLElement stores its attributes. That's
what I meant
with the difference between immutable and encapsulation.

>> This is exactly the reason why we can't easily change the list of Attribute
>> objects to a set of Attribute objects in XMLElement, even when it is immutable:
>> we told the world that we use a List<Attribute> to store them.
>
> That's more a contract problem. Even if we there were accessors for
> attributes (mutability), the internal representation would not be more
> easy to change from List -> Set.

Agreed, but again, the different levels. If we didn't expose the attribute-list
to the outside there wouldn't be a problem in changing the List to a Set.

>> I don't think we should be defensive programmers, if we give out objects we
>> give them out to be manipulated.
>
> Not in this case.
>
> Example: A handler processes a message which he distributes (broadcasts)
> to a list of recipients.
>  The developer decides to iterate through the list of recepients and
> reuses the incoming stanza by setting the proper 'to' attributes and
> immediately hands the stanza over to delivery, expecting that the stanza
> is processed and gone when the delivery call returns. He continues to
> process with the next recepient. His unit tests succeed!
>  In production, recepients complain because they don't get messages or
> get a lot of duplicated messages at once.
>  What went wrong?

Yes, that's indeed a problem. But one, every (powerful) language suffers, you
can do a lot of fancy things with C, but you can also make some veeery bad
mistakes with it.

> I'm even more defensive than making Stanza immutable! For example, you
> cannot call StanzaBuilder.getFinalStanza() more than once without
> getting an exception.
>
>> If we don't want them to be manipulated,
>> don't expose them.
>
> How can we not expose Stanza objects to Handlers?

Now you got me completely. How 'bout making it, aehm, immutable ;).

Frankly, I wouldn't care about malicious (or misbehaving modules) such errors
are easily spotted and fixed. Changing objects is something we do all the time,
this doesn't mean we have to do it via getters/setters, but via other methods
like "addNode" or "handleSet".

Just to make it clear: I didn't mean to open an object up to any change (that
would be generating getters/setters for all members), but to make sure the
changes that are necessary are possible - in a safe way.

We can't secure our objects for everything we didn't think of, most of the time
we're restricting ourselves instead of keeping others from doing bad things.
Granted, this is sometimes a good thing, one no commercial software company
would like to miss.

Thanks for the insights, the arguments did change much of my point of view.

Cheers,
Michael

Re: Immutable objects [WAS: Re: [jira] Closed: (VYSPER-92) Stanzas don't get enriched...]

Posted by Bernd Fondermann <be...@googlemail.com>.

On Mon, Jul 6, 2009 at 11:06, Emmanuel Lecharny<el...@apache.org> wrote:
> Hi guys,
>
> here, I would go in Bernd's way. Immutable objects have another additional
> advantage over standard objects : they are thread safe, in any case.
>
> I would suggest to read Joshua Bloch's Effective Java, Itrem 13, for all the
> pros and cons of Immutable objects.

http://en.wikipedia.org/wiki/Immutable_object

is helpful, too.

  Bernd

Re: Immutable objects [WAS: Re: [jira] Closed: (VYSPER-92) Stanzas don't get enriched...]

Posted by Emmanuel Lecharny <el...@apache.org>.

Hi guys,

here, I would go in Bernd's way. Immutable objects have another 
additional advantage over standard objects : they are thread safe, in 
any case.

I would suggest to read Joshua Bloch's Effective Java, Itrem 13, for all 
the pros and cons of Immutable objects.

Bernd Fondermann wrote:
> Michael Jakl wrote:
>   
>> Hi!
>>
>> On Mon, Jul 6, 2009 at 07:01, Bernd
>> Fondermann<be...@googlemail.com> wrote:
>>     
>>> On Sun, Jul 5, 2009 at 16:38, Michael Jakl (JIRA)<ji...@apache.org> wrote:
>>>       
>>>> Actually I don't think immutable object make much sense in an imperative language, even though I know the advantages of immutable objects due to my experience with functional programming.
>>>>         
>>> Wow, don't let your prof read this ;-)
>>>
>>> Java is an object-oriented languages. A major feature of OO is data
>>> encapsulation, immutable objects are a certain strict kind of data
>>> encapsulation.
>>>       
>> Encapsulation and immutable objects don't have much common ground, IMHO.
>> Encapsulation is *hiding* the internals of an object, returning immutable
>> objects is not.
>>     
>
> Of course they have (IMHO). Object = behavior + data. Immutable object =
> don't change my data! how these data is represented internally is up to
> the (immutable) object. If we decide to check for duplicates in the
> constructor, that's internal behavoir.
>
>   
>> This is exactly the reason why we can't easily change the list of Attribute
>> objects to a set of Attribute objects in XMLElement, even when it is immutable:
>> we told the world that we use a List<Attribute> to store them.
>>     
>
> That's more a contract problem. Even if we there were accessors for
> attributes (mutability), the internal representation would not be more
> easy to change from List -> Set.
>
>   
>> There are better ways to keep the implementation hidden whilst still providing
>> a similar functionality to the outside. Concerning lists, Visitors are one way,
>> Iterators another.
>>     
>
> Yeah, I think an iterator would have been a much better choice.
>
>   
>> I don't think we should be defensive programmers, if we give out objects we
>> give them out to be manipulated. 
>>     
>
> Not in this case.
>
> Example: A handler processes a message which he distributes (broadcasts)
> to a list of recipients.
>   The developer decides to iterate through the list of recepients and
> reuses the incoming stanza by setting the proper 'to' attributes and
> immediately hands the stanza over to delivery, expecting that the stanza
> is processed and gone when the delivery call returns. He continues to
> process with the next recepient. His unit tests succeed!
>   In production, recepients complain because they don't get messages or
> get a lot of duplicated messages at once.
>   What went wrong?
>
> I'm even more defensive than making Stanza immutable! For example, you
> cannot call StanzaBuilder.getFinalStanza() more than once without
> getting an exception.
>
>   
>> If we don't want them to be manipulated,
>> don't expose them.
>>     
>
> How can we not expose Stanza objects to Handlers?
>
>   
>> In the end, there is no "good" or "bad", just "Way A" and "Way B", I guess ;).
>> Probably the purpose of an object plays a big role here (value objects, logic
>> etc).
>>
>>     
>>> Immuntable objects are helpful when sharing information with code you
>>> don't trust or cannot control and where giving away a copy might be
>>> too expensive.
>>>       
>> Not every sin can be justified by performance considerations ;)
>>     
>
> +1. But in this codebase, I always tried to be as stateless as possible
> and generate the least amount of duplicated objects as possible. These
> general patterns help to increase the probability of better scaling.
>
>   
>>> Especially in parallel processing, immutable objects are
>>> indespensible, see Erlang.
>>>       
>> Agreed.
>>
>> Sorry to bring this up again, but I like discussions like this. Are there other
>> views on it?
>>     
>
> I changed the subj to make it more visible to others.
>
>   Bernd
>
>   


-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Immutable objects [WAS: Re: [jira] Closed: (VYSPER-92) Stanzas don't get enriched...]

Posted by Bernd Fondermann <bf...@brainlounge.de>.

Michael Jakl wrote:
> Hi!
> 
> On Mon, Jul 6, 2009 at 07:01, Bernd
> Fondermann<be...@googlemail.com> wrote:
>> On Sun, Jul 5, 2009 at 16:38, Michael Jakl (JIRA)<ji...@apache.org> wrote:
>>> Actually I don't think immutable object make much sense in an imperative language, even though I know the advantages of immutable objects due to my experience with functional programming.
>> Wow, don't let your prof read this ;-)
>>
>> Java is an object-oriented languages. A major feature of OO is data
>> encapsulation, immutable objects are a certain strict kind of data
>> encapsulation.
> 
> Encapsulation and immutable objects don't have much common ground, IMHO.
> Encapsulation is *hiding* the internals of an object, returning immutable
> objects is not.

Of course they have (IMHO). Object = behavior + data. Immutable object =
don't change my data! how these data is represented internally is up to
the (immutable) object. If we decide to check for duplicates in the
constructor, that's internal behavoir.

> 
> This is exactly the reason why we can't easily change the list of Attribute
> objects to a set of Attribute objects in XMLElement, even when it is immutable:
> we told the world that we use a List<Attribute> to store them.

That's more a contract problem. Even if we there were accessors for
attributes (mutability), the internal representation would not be more
easy to change from List -> Set.

> There are better ways to keep the implementation hidden whilst still providing
> a similar functionality to the outside. Concerning lists, Visitors are one way,
> Iterators another.

Yeah, I think an iterator would have been a much better choice.

> 
> I don't think we should be defensive programmers, if we give out objects we
> give them out to be manipulated. 

Not in this case.

Example: A handler processes a message which he distributes (broadcasts)
to a list of recipients.
  The developer decides to iterate through the list of recepients and
reuses the incoming stanza by setting the proper 'to' attributes and
immediately hands the stanza over to delivery, expecting that the stanza
is processed and gone when the delivery call returns. He continues to
process with the next recepient. His unit tests succeed!
  In production, recepients complain because they don't get messages or
get a lot of duplicated messages at once.
  What went wrong?

I'm even more defensive than making Stanza immutable! For example, you
cannot call StanzaBuilder.getFinalStanza() more than once without
getting an exception.

> If we don't want them to be manipulated,
> don't expose them.

How can we not expose Stanza objects to Handlers?

> In the end, there is no "good" or "bad", just "Way A" and "Way B", I guess ;).
> Probably the purpose of an object plays a big role here (value objects, logic
> etc).
> 
>> Immuntable objects are helpful when sharing information with code you
>> don't trust or cannot control and where giving away a copy might be
>> too expensive.
> 
> Not every sin can be justified by performance considerations ;)

+1. But in this codebase, I always tried to be as stateless as possible
and generate the least amount of duplicated objects as possible. These
general patterns help to increase the probability of better scaling.

>> Especially in parallel processing, immutable objects are
>> indespensible, see Erlang.
> 
> Agreed.
> 
> Sorry to bring this up again, but I like discussions like this. Are there other
> views on it?

I changed the subj to make it more visible to others.

  Bernd

Re: [jira] Closed: (VYSPER-92) Stanzas don't get enriched with a "from" Attribute when the client omits it.

Posted by Michael Jakl <ja...@gmail.com>.

Hi!

On Mon, Jul 6, 2009 at 07:01, Bernd
Fondermann<be...@googlemail.com> wrote:
> On Sun, Jul 5, 2009 at 16:38, Michael Jakl (JIRA)<ji...@apache.org> wrote:
>> Actually I don't think immutable object make much sense in an imperative language, even though I know the advantages of immutable objects due to my experience with functional programming.
>
> Wow, don't let your prof read this ;-)
>
> Java is an object-oriented languages. A major feature of OO is data
> encapsulation, immutable objects are a certain strict kind of data
> encapsulation.

Encapsulation and immutable objects don't have much common ground, IMHO.
Encapsulation is *hiding* the internals of an object, returning immutable
objects is not.

This is exactly the reason why we can't easily change the list of Attribute
objects to a set of Attribute objects in XMLElement, even when it is immutable:
we told the world that we use a List<Attribute> to store them.

There are better ways to keep the implementation hidden whilst still providing
a similar functionality to the outside. Concerning lists, Visitors are one way,
Iterators another.

I don't think we should be defensive programmers, if we give out objects we
give them out to be manipulated. If we don't want them to be manipulated,
don't expose them.

In the end, there is no "good" or "bad", just "Way A" and "Way B", I guess ;).
Probably the purpose of an object plays a big role here (value objects, logic
etc).

> Immuntable objects are helpful when sharing information with code you
> don't trust or cannot control and where giving away a copy might be
> too expensive.

Not every sin can be justified by performance considerations ;)

> Especially in parallel processing, immutable objects are
> indespensible, see Erlang.

Agreed.

Sorry to bring this up again, but I like discussions like this. Are there other
views on it?

Michael