I'll work on it. It looks like there's other changes to be made, for newer
smack jars, in establishing the connection in the first place also. I need
to get something going for my application. If it's useful for others, all
the better.
Chris Custine (Apache) wrote:
>
> IIRC, the GroupChat spec was an older predecessor to the MUC spec in XMPP.
> I think that any server implementing the newer MUC is supposed to also
> support the GroupChat part, but this isn't clear to me. Either way, I
> *think* the smackx.muc.* stuff probably abstracts this so that MUC works
> either way. Like Gert said, if you get something working please submit a
> Jira with a patch and we will get it applied.
>
> Thanks,
> Chris
>
> On Tue, May 27, 2008 at 12:38 PM, jsexton0 <[EMAIL PROTECTED]> wrote:
>
>>
>> Hi -
>> Correct me if this is not the case, but a group chat appears to use a
>> "room"
>> attribute rather than a "participant". I've just started looking at the
>> source code and one thing I see is that the Servicemix class uses a
>> GroupChat created by a call to createGroupChat() rather than a
>> MultiUserChat
>> instance. The Ignite folks seem to be recommending the MultiUserChat
>> class
>> over GroupChat, and that also happens to be what I used in my application
>> with Openfire already.
>>
>> I probably need to create a GroupChatEndpoint with the slightly different
>> smack usage (MultiUserChat).
>>
>>
>> bsnyder wrote:
>> >
>> > On Tue, May 27, 2008 at 11:50 AM, jsexton0 <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Going to the debug log level did not produce any additional output
>> >> unfortunately. This isn't really a problem though since I would
>> expect
>> >> it
>> >> to fail - it is supposed to be connected to a group chat but is still
>> >> failing to join the chat room on startup, although it does log into
>> the
>> >> Openfire server. Maybe this failure to join the chat room isn't
>> >> surprising
>> >> either since I've guessed at some of the syntax.
>> >
>> > I didn't see these above, so I think you need to set the chat and the
>> > participant attributes either via the URI syntax or using separate
>> > attributes for each in the xbean.xml configuration file.
>> >
>> >> In an additional note, "mvn jbi:projectDeploy" does not replace my
>> >> sample.
>> >> I have to shutdown servicemix, and go and delete the folder in
>> >> data\smx\service-assemblies, restart, and then I can redeploy
>> >> successfully
>> >> with the maven command.
>> >
>> > The jbi:projectDeploy is only going to build and package the SU/SA and
>> > deploy the SA to ServiceMix via JMX. It has nothing to do with the
>> > ServiceMix lifecycle or undeploying a SA.
>> >
>> > Bruce
>> > --
>> > perl -e 'print
>> > unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
>> > );'
>> >
>> > Apache ActiveMQ - http://activemq.org/
>> > Apache Camel - http://activemq.org/camel/
>> > Apache ServiceMix - http://servicemix.org/
>> > Apache Geronimo - http://geronimo.apache.org/
>> >
>> > Blog: http://bruceblog.org/
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/XMPP-tp17412424p17497195.html
>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>
>>
>
>
> --
> Chris Custine
> My Blog :: http://blog.organicelement.com
> Apache ServiceMix :: http://servicemix.apache.org
> Apache Directory Server :: http://directory.apache.org
>
>
--
View this message in context:
http://www.nabble.com/XMPP-tp17412424p17500419.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
