UnmarshalException on connecting ExternalComponent to Server

[Max Bit]

I am trying to create an ExternalComponent using sample provided in the repo and following https://sco0ter.bitbucket.io/babbler/xep/externalcomponents.htm. However, I am seeing the following Exception when connect() method is called.

Can someone advise?

rocks.xmpp.core.XmppException: java.xmlbind.UnmarshalException
-with linked exception
unexpected element (uri:"http://etherx.jabber.org/streams",local:"stream").  Expected elements are ..........
 at rocks.core.session.XmppSession.throwAsXmppExceptionIfNotNull(XmppSession.java:272)
 at rocks.xmpp.extensions.component.accept.ExternalComponent.connect(ExternalComponent.java:144)

I did see stream opened with xmlns="jabber:component:accept" and then closed stream in the inbound message of XML viewer.

[Christian Schudt]

Do you have XMPP logs here? Which server are you using? It works for me with Openfire.

[Christian Schudt]

hm, I wonder what namespace your server is expecting then. The external components implementation follows this spec:

https://xmpp.org/extensions/xep-0114.html#proto

See the example for the stream header which it is sending (you should be able to see it in the log).

[Max Bit]

Below is the stream i saw in the XML viewer.

<stream:stream xml:lang="en-US" to="mycomponent" version="1.0" xmlns="jabber:component:accept" xmlns:stream="http://etherx.jabber.org/streams">

[Christian Schudt]

can you check what your server is expecting then? The namespace in accordance with the specification, not sure what your server is complaining about.

[Max Bit]

Yeah. The namespace is in accordance with the specification. Do external components need another port to communicate? Also,I do see in the logs a statement i.e. "Expecting TLS/SASL Support from client". Could it be related?

StreamException: this namespace http://etherx.jabber.org/streamsnot allowed on this port

[Christian Schudt]

Port 5222 is not for component connections (but for client-to-server connections). Can you find out the real port and try this one? (Openfire uses 5275).

[Max Bit]

Thanks. I am no longer seeing port error after updating the correct port. However, there is a different exception now XMLStreamException.

[Christian Schudt]

Frankly said, it looks like your server requires TLS negotiation and encrypts the channel. I assume the <handshake/> is then sent in plain text, but the server already expects it encrypted and then closes the connection.

TLS negotiation is not specified in XEP-0114, that's why it's not implemented or respected.

Unfortunately I don't see an easy workaround now for you.

Maybe you can try to disable TLS on the server (for External Components).

Is your server open source, so I could test it?

[Max Bit]

Thanks for the reply. messaging server is not open source. I will see if there is an option to disable TLS on the server (for External Components

[Max Bit]

I disabled TLS and the required attribute is no longer in the server response for starttls. However, I am still seeing the exception.

    rocks.xmpp.core.XmppException: javax.xml.bind.JAXBException: class rocks.xmpp.extensions.component.accept.model.Handshake nor any of its super class is known to this context.

  OUT (null): <?xml version="1.0" encoding="UTF-8"?><stream:stream xml:lang="en-US" to="mycomponent" version="1.0" xmlns="jabber:component:accept" xmlns:stream="http://etherx.jabber.org/streams">
    IN  (123443423534534543): <?xml version="1.0" encoding="UTF-8"?><stream:stream xmlns="jabber:component:accept" xmlns:stream="http://etherx.jabber.org/streams" from="dummy.com" id="123443423534534543" version="1.0">
    IN  (123443423534534543): <stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"></starttls></stream:features>
    OUT (123443423534534543): <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"></starttls>
    IN  (null): <proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"></proceed>

[Christian Schudt]

The server is still sending stream features though. I fear the implementation does not support it, because it's not specified.

The exception you get is yet another exception, which is also weird. because the Handshake element should actually be found. Do you have the xmpp-extensions.jar on your classpath?

[Max Bit]

Okay. I do have the following in my pom.xml and running the jar with all dependencies(0.7.5) included (descriptorRef jar-with-dependencies as part of maven-assembly-plugin) Do you mean anything else?

             <artifactId>xmpp-addr</artifactId>
            <artifactId>xmpp-core</artifactId>
            <artifactId>xmpp-core-client</artifactId>
            <artifactId>xmpp-extensions</artifactId>
            <artifactId>xmpp-extensions-client</artifactId>
            <artifactId>xmpp-debug</artifactId>

implementation does not support it, because it's not specified.

Does it mean babbler doesn't support it?. Please see if it can be fixed. I haven't found any library apart from Babbler with so many extensions support.

Also, I do see different exception on running the component multiple times.

rocks.xmpp.core.XmppException: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,310]
Message: Socket closed
    at rocks.xmpp.core.session.XmppSession.throwAsXmppExceptionIfNotNull(XmppSession.java:272)
    at rocks.xmpp.extensions.component.accept.ExternalComponent.login(ExternalComponent.java:192)
    at rocks.xmpp.extensions.component.accept.ExternalComponent.connect(ExternalComponent.java:153)
    at rocks.xmpp.core.session.XmppSession.connect(XmppSession.java:318)

Further, If I disable TLS for everything. I still see the JAXBException after the xmpp traffic

Traffic:

   OUT (null): <?xml version="1.0" encoding="UTF-8"?><stream:stream xml:lang="en-US" to="mycomponent" version="1.0" xmlns="jabber:component:accept" xmlns:stream="http://etherx.jabber.org/streams">
    IN  (123443423534534543): <?xml version="1.0" encoding="UTF-8"?><stream:stream xmlns="jabber:component:accept" xmlns:stream="http://etherx.jabber.org/streams" from="dummy.com" id="123443423534534543" version="1.0">
    IN  (123443423534534543): <stream:features></stream:features>

Exception:

javax.xml.bind.JAXBException: class rocks.xmpp.extensions.component.accept.model.Handshake nor any of its super class is known to this context

[Christian Schudt]

Handshake should be found automatically via java.util.ServiceLoader by simply having the jar file on your classpath.

If you have built your own jar file ("fat jar") with jar-with-dependencies descriptor as part of maven-assembly-plugin, java.util.ServiceLoader won't work well, because multiple jars contain the same file META-INF/rocks.xmpp.core.session.Module which is required by ServiceLoader. E.g. xmpp-core-client and xmpp-extensions-client contain the same file and assmbly plugin probably only takes the one from xmpp-core-client.

I've worked around this issue by using maven-shade-plugin: https://bitbucket.org/sco0ter/babbler/src/0.7.5/xmpp-documentation/pom.xml?fileviewer=file-view-default#pom.xml-84 (org.apache.maven.plugins.shade.resource.ServicesResourceTransformer merges multiple files for ServiceLoader)

As for the other issue: I can try to fix it, but Oracle Server seems to use a non-standard way for external components, and since it's not open source I can't test it. I can only try best guesses and probably would need your help with testing.

[Max Bit]

Thank You for shade-plugin. I am able to see handshake now. However, there is still an exception

XMPP Traffic

OUT (null): <?xml version="1.0" encoding="UTF-8"?><stream:stream xml:lang="en-US" to="mycomponent" version="1.0" xmlns="jabber:component:accept" xmlns:stream="http://etherx.jabber.org/streams">
IN  (123443423534534543): <?xml version="1.0" encoding="UTF-8"?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:component:accept" from="dummy.com" id="123443423534534543" version="1.0">
IN  (123443423534534543): <stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"></starttls></stream:features>
OUT (123443423534534543): <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"></starttls>
IN  (123443423534534543): <proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"></proceed>
OUT (123443423534534543): <handshake>1234567abcdef</handshake>
OUT (null): </stream:stream>

Server Side:

javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?

Exception:

rocks.xmpp.core.XmppException: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,311]
Message: An invalid XML character (Unicode: 0x15) was found in the element content of the document.
    at rocks.xmpp.core.session.XmppSession.throwAsXmppExceptionIfNotNull(XmppSession.java:272)

[Christian Schudt]

Yes, this is probably because the library is sending the handshake before TLS is negotiated, i.e. in plain text.

I've uploaded a 0.8.0-SNAPSHOT, can you try this?

ExternalComponent.create("component", "secret", TcpConnectionConfiguration.builder().channelEncryption(DISABLED).build();

Be aware, I never tested it, because I can't with your server.

[Max Bit]

Thanks. I had replaced all the artifacts with 0.8.0-SNAPSHOT and seeing the following error after running the jar

  Error: A JNI error has occurred, please check your installation and try again
  Exception in thread "main" java.lang.NoClassDefFoundError: rocks/xmpp/core/net/ConnectionConfiguration

If I build and run the class directly, I see the following exception:

Exception in thread "main" java.lang.IncompatibleClassChangeError: Implementing class
    at java.lang.ClassLoader.defineClass1(Native Method)
...............................................................
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    at rocks.xmpp.core.session.CoreModule.getExtensions(CoreModule.java:96)
    at rocks.xmpp.core.session.XmppSessionConfiguration.<init>(XmppSessionConfiguration.java:155)
    at rocks.xmpp.core.session.XmppSessionConfiguration.<init>(XmppSessionConfiguration.java:76)
    at rocks.xmpp.core.session.XmppSessionConfiguration$Builder.build(XmppSessionConfiguration.java:529)

[Christian Schudt]

You probably need the following artifacts now:

xmpp-addr
xmpp-core-common
xmpp-core-client
xmpp-extensions-common
xmpp-extensions-client

Is there any reason you re-assemble the artifact manually with assembly/shade plugin?

[Max Bit]

Thanks. I tested the changes and see the following error:

OUT (null): <?xml version="1.0" encoding="UTF-8"?><stream:stream xml:lang="en-US" to="mycomponent" version="1.0" xmlns="jabber:component:accept" xmlns:stream="http://etherx.jabber.org/streams">
IN  (123443423534534543): <?xml version="1.0" encoding="UTF-8"?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:component:accept" from="dummy.com" id="123443423534534543" version="1.0">

OUT (123443423534534543): <handshake>12345678</handshake>
IN  (123443423534534543): <stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"></starttls></stream:features>
OUT (123443423534534543): </stream:stream>
IN  (): <handshake></handshake>
rocks.xmpp.core.stream.StreamNegotiationException: The server requires TLS, but you disabled it.

Is there any reason you re-assemble the artifact manually with assembly/shade plugin?

I need to have a jar and assumed that assembly/shade plugin is required to avoid the java.util.ServiceLoader issue that you pointed earlier.

[Christian Schudt]

If you leave the jars alone (i.e. don't use assembly/shade plugin), ServiceLoader works. Otherwise you need org.apache.maven.plugins.shade.resource.ServicesResourceTransformer. So, generally in my experience, building assembled fat jars only complicates things.

With regards to the error exception: The server only advertises the starttls feature, which means it is mandatory in accordance with: https://xmpp.org/rfcs/rfc6120.html#tls-rules-mtn

If the receiving entity advertises only the STARTTLS feature [...], the parties MUST consider TLS as mandatory-to-negotiate.

Try to set a SSLContext in TcpConnectionConfiguration and set channelEncryption(OPTIONAL).

What is weird, is that it sends the <handshake> before receiving stream features. Without debugging this issue is hardly solvable. Can you imagine to debug this and create a pull request?

[Max Bit]

Thanks for Info. on the jar.

After the change, I see same error as seen with maven version 0.7.5. The only difference is that <handshake> is sent by client before acknowledgment(<proceed>) from server for tls as opposed to <handhsake> sent by client after <proceed> from server with maven version 0.7.5.

N  (123443423534534543): <stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"></starttls></stream:features>
OUT (123443423534534543): <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"></starttls>
OUT (123443423534534543): <handshake>1234567abcdef</handshake>
IN  (123443423534534543): <proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"></proceed>
OUT (123443423534534543): </stream:stream>
rocks.xmpp.core.XmppException: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,311]
Message: An invalid XML character (Unicode: 0x15) was found in the element content of the document.
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?

Can you advise on the below questions?

The following is the XMPP Traffic when I disable TLS on entire server(Tested with 0.7.5) and was able to connect.

Q1: Can't library send <handshake> instead of sending starttls when server sends <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"></starttls>?

I agree this might not be in accordance with https://xmpp.org/rfcs/rfc6120.html#tls-rules-mtn

OUT (null): <?xml version="1.0" encoding="UTF-8"?><stream:stream xml:lang="en-US" to="mycomponent" version="1.0" xmlns="jabber:component:accept" xmlns:stream="http://etherx.jabber.org/streams">
IN  (123443423534534543): <?xml version="1.0" encoding="UTF-8"?><stream:stream xmlns="jabber:component:accept" xmlns:stream="http://etherx.jabber.org/streams" from="dummy.com" id="123443423534534543" version="1.0">
IN  (123443423534534543): <stream:features></stream:features>
OUT (123443423534534543): <handshake>1234567abcdef</handshake>
IN  (123443423534534543): <handshake></handshake>
connected
IN  (null): <stream:features><gatewayed_session xmlns="xmpp:gatewayed:support:gatewayed_session"></gatewayed_session></stream:features>
OUT (null): </stream:stream>

Q2: Will sending <handshake> after TLS negotiation/handshake is completed solve the issue as XEP-0114: Jabber Component Protocol doesn't enable component to upgrade to TLS?

Q3: How do one know that TLS negotiation/handshake is completed as TLS messages are not logged? (See text below)

(Extract from XMPP definitive Guide)

If the server request TLS then, the following happens :

<starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"/> // Client switches to encrypted connectionId
<proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>  // acknowledgment from Server for the previous request

From the point where the <proceed/> happened, the regular XMPP stream ends, and the TLS handshake starts happening over the TCP connection itself. This handshake step involves the server sending a certificate to the client, and the client validating the certificate to ensure that the server is indeed the one it claims to be. This handshake occurs directly over the TCP connection using standard TLS messages (not an XML encapsulation of TLS), as defined in the TLS specification. After the handshake has successfully completed, the client restarts its XMPP session, only now encrypting everything it sends using the key received from the server during the TLS handshake

[Christian Schudt]

Q1: Now I am confused. When does server send: <stream:features></stream:features> and when does it send <stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"></starttls></stream:features> ? If <starttls/> is the only element, it is assumed it is required and it wants to negotiate it. I am not sure, if we should disabled the behavior.

Q2: Probably, but I don't know your server's behavior. I just spent one hour to figure out, how to wait on all stream features being negotiated, but I am too tired :-/ Ideally your server sends an empty <stream:features> after client restarted the stream (after <proceed/>).

Q3: Similar issue as described above. After <proceed/> the channel is encrypted, then client sends a stream restart. Then server sends stream header, then server sends new stream features (hopefully empty), then <handshake/> should be sent. Logic should go in StreamFeaturesManager, but unfortunately I didn't find a good solution yet.

[Max Bit]

Q1: Now I am confused. When does server send: <stream:features></stream:features> and when does it send <stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"></starttls></stream:features> ?

Disabling TLS for server component results in following

<stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"></starttls></stream:features>

Disabling TLS for entire server results in following

<stream:features></stream:features>

I am not sure if sending <handshake> after client restarts stream (post upgrade to TLS) will solve the issue.

The following two states that </required> attribute mandates TLS. Maybe, its implementation is different for different servers. As </required> is not present in the server stream features response, I think client should not send startTLS

4.3.2. Stream Features Format https://xmpp.org/rfcs/rfc6120.html#streams-negotiation-features

5.4.1. Exchange of Stream Headers and Stream Features https://xmpp.org/rfcs/rfc6120.html#tls-process-stream

Take rest. You have been very helpful. :)

[Max Bit]

I think the issue can be replicated if you enable TLS in openfire for everything.

If you run in debug mode and pause execution at streamFeatureManager.completeNegotiation() (10 sec or more ), and then jump to login(sharedSecret), <handhshake> happens but stream isn't restarted. It is observed that the babbler doesn't restarts the stream until it has executed login(sharedSecret).

Shouldn't stream restart happen before login(sharedSecret)?

During normal execution login(sharedSecret) is processed even before the results for streamFeatureManager.completeNegotiation() call are completed causing <handhshake> to happen before <proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"/> to . I am not familiar with Java 7/8 and wasn't able to understand StreamFeatureManager completely.

[Christian Schudt]

Yes, stream restarts should generally happen before login. However, stream negotiation is not specified for external components, that's why we have all the trouble now. (XEP-0225 also says, TLS is not supported). I will try to fix it nonetheless.

I had another idea in the meanwhile: Don't set the version attribute in the stream header, which should mean: "Don't use stream features, I don't understand them" (according to RFC 6120):

The inclusion of the version attribute set to a value of at least "1.0" signals support for the stream-related protocols defined in this specification, including TLS negotiation,

I've pushed 300b2c0 for that and deployed a new snapshot including it. Would you try it and see if the server stops sending stream features (and also ensure, that the version attribute is absent in the opening stream header)?

[Max Bit]

Yes, the version attribute is absent in opening stream and the external component is able to connect.
Now, I have to enable SSL/TLS for external components and hoping if that could be supported by babbler.

I see another issue when i try to subscribe external component to node. The request sent by client looks incorrect.

testComponent.connect();
PuSubService testService=PubSubManager.createPubSubService(Jid.of("dummy.com"));
PubSubNode pubSubNode = testService.node("princely_musings”);
pubSubNode.subscribe();

actual:

<iq from="dummy.com" id="XXXX" to ="dummy.com" type="set">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<subscribe node="princely_musings" jid="dummy.com">
</subscribe>
<iq>

expected:

<iq  id="XXXX" to="dummy.com" type="set">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<subscribe node="princely_musings" jid="mycomponent">
</subscribe>
<iq>

[Christian Schudt]

I will try to implement TLS for external components.

To the other issue: The 'from' attribute is correct. It must be set:

All stanzas sent to the server MUST possess a 'from' attribute [...]. The domain identifier portion of the JID contained in the 'from' attribute MUST match the hostname of the component.

The bare JID of the 'jid' attribute in the <subscribe/> element must match the bare JID in the 'from' attribute of the IQ, as far as I understand https://xmpp.org/extensions/xep-0060.html#subscriber-subscribe

I think the following would be correct:

<iq from="mycomponent.dummy.com" id="XXXX" to="dummy.com" type="set">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<subscribe node="princely_musings" jid="mycomponent.dummy.com">
</subscribe>
<iq>

You can also try low-level API for this, similar to this:

return xmppSession.query(IQ.set(pubSubServiceAddress, PubSub.withSubscribe(Objects.requireNonNull(nodeId, "nodeId must not be null"), "mycomponent", null))).thenApply(result ->
                result.getExtension(PubSub.class).getSubscription());

[Christian Schudt]

Want to try latest snapshot? I changed stream feature negotiation (cb67ffb), so that it hopefully works for you. I've also looked into the other issue. According to Example 2 of XEP-114, the server should actually return from="mycomponent.dummy.com" in the response stream header. Openfire does this, too.

[Max Bit]

Thanks. I tried the latest snapshot and seeing that if server requires TLS in the stream features, then client library is initiating starttls and the stream is restarted. After restart, the handshake is performed. The change looks good to me.

On a different note, i tried the low-level API and it worked for me. However, the subscribe request send is different from the one you mentioned. It is similar to the one i posted previously and it works perfectly.

testComponent.connect();
String nodeId = "princely_musings";
return testComponent.query(IQ.set(Jid.of.("dummy.com"), PubSub.withSubscribe(Objects.requireNonNull(nodeId, "nodeId must not be null"), Jid.of.("mycomponent"), null))).thenApply(result ->
                result.getExtension(PubSub.class).getSubscription());

<iq from="dummy.com" id="XXXX" to ="dummy.com" type="set">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<subscribe node="princely_musings" jid="mycomponent">
</subscribe>
<options></options>
</pubsub>
<iq>

[Christian Schudt]

The only difference I see, are the 'from' and 'jid' attributes, which you can control yourself and the empty options element, which shouldn't do any harm. What's the issue?

[Max Bit]

Okay. The issue is how to control these values.

Do you mean I need to replace dummy.com, mycomponent to mycomponent.dummy.com in the code snippet pasted previously? I thought the code snippet sets 'to' and 'jid' attributes?

On another note, the changes for stream features will be out as part of 0.7.5 soon?

[Christian Schudt]

The real issue might be that the response stream header "only" contains "dummy.com" instead of "mycomponent.dummy.com" as it should be as per XEP-114.

For your testing purposes, you could replace them manually and see, if it solves your issue. Yes, the code snippet sets 'to' and 'jid', but isn't that what you want?

0.7.5 is already released. I don't plan to release 0.7.6. 0.8.0 is more likely.

[Max Bit]

Thanks. Please share when is 0.8.0 planned to be released.

Want to try latest snapshot? I changed stream feature negotiation (cb67ffb)

Everything is working fine. However, I do notice sometimes handshake happens before tls negotiation and exception occurs saying policy violation. However, If I retry the component creation, it succeeds.

The real issue might be that the response stream header "only" contains "dummy.com"

Yes, the 'from' attribute in stream header is 'dummy.com'.

For your testing purposes, you could replace them manually and see

How can I change it manually to 'mycomponent.dummy.com'?

Should the 'to' attribute in the stream header for the client request (xmlns:jabber:component.accept) be 'mycomponent.dummy.com' ? It is "mycomponent" in the xmpp traffic

Can a subdomain be white-listed using babbler? The component with jid = "mycomponent" is subscribed successfully. However, disco info from 'mycomponent.dummy.com' returns domain is blacklisted.

I see the following information in disco info after component is created and connected.

1. Pub Sub Service is at pubsub.dummy.com.
2. Disco Info from 'mycomponent.dummy.com' returns domain is blacklisted.
3. Disco information from 'mycomponent' returns identity of type component( added identity using service manager). This is the one that is subscribed to the node.

[Max Bit]

Any help is appreciated.

[Christian Schudt]

I do notice sometimes handshake happens before tls negotiation

I will look into this. Seems like a timing issue.

Hopefully fixed with: 895dfae

Yes, the 'from' attribute in stream header is 'dummy.com'.

This is unexpected. See here

the server would set the 'from' attribute to the component name.

How can I change it manually to 'mycomponent.dummy.com'?

Just pass the full JID as component name mycomponent.dummy.com. Maybe the server returns the right 'from' attribute then.

Can a subdomain be white-listed using babbler?

No. Or I am not sure what to do here. Your issue sounds like a server policy.

See also here: fcf48eb

I've uploaded a new snapshot containing the changes.

[Max Bit]

Hopefully fixed with: 895dfae

Earlier, the issue was once in awhile and could be mitigated by starting the creation component again. Now, I am seeing the handshake happening before client initiates starttls consistently resulting in policy violation error. The above change had made the issue worse.

Is it possible to replicate issue on openfire with ssl enabled for components?

[Christian Schudt]

I think you are right. Addressed with a79cf77. Snapshot not yet available, I can provide it later. is uploaded.

[Max Bit]

Thanks. I see jabber:client is sent instead of jabber:component:accept in the stream header(first request) from client resulting in unmarshal exception.

[Christian Schudt]

Arg, sorry. Missed it. I used jabber:client namespace for local testing only. Fixed snapshot is up.

[Max Bit]

Yes, the latest snapshot works.

[Christian Schudt]

Great! What about the other issue, setting {{mycomponent.domain.com}} as the component name?

[Max Bit]

I set {{mycomponent.domain.com}} as component name. However, server is not sending mycomponent.domain.com in the from attribute of the first stream response. I am not seeing any issues even though server is sending {{domain.com}} instead of {{mycomponent.domain.com}}.

Can you let me know how to read additional child elements that might be present in stanza of type message. e.g. my message stanza contains <attachment type="a" lang="eng"> as child element and I want to read type, lang attributes and their values.

I tried using below but it returns [attachment null].

message.getExtensions()

[Christian Schudt]

Can you try if that works for you:

myComponent.addOutboundIQListener(e -> e.getIQ().setFrom(Jid.of("mycomponent.dummy.com")));

(with regards to setting the from attribute for outgoing IQs).

The other question, see here: https://sco0ter.bitbucket.io/babbler/customextensions.html

Also please don't ask arbitrary questions here, use the mailing list instead.

[Max Bit]

Thank You. The snippet worked and I am able to see the from attribute as {{mycomponent.domain.com}} The issues are resolved.

I have another question when using external component for creating rooms. As the issue is not related to the current one, I have posted the details in the mailing group.

[Christian Schudt]

The start tls implementation for external component will be part of 0.8.0 (no release date yet). Closing this one.

[Christian Schudt]

Fixed with 0.8.0