I recently tried binding based on RFC 6120 (9.1.3 pg 132) with:
<iq id='tn281v37' type='set'><bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/></iq>
I would get a response of 'not well formed':
<stream:error xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'><not-well-formed xmlns='urn:ietf:params:xml:ns:xmpp-streams'/></stream:error>
It took a few days to find out it needed xmlns='jabber:client' :
<iq id='tn281v37' type='set' xmlns='jabber:client'><bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/></iq>
It doesn't look like RFC 6120 has been superseded and every example of binding I find on the web doesn't have it. Is this due to implementation of the server? At the time I was binding to chinwag.im
This appears to be a misunderstanding of how XML namespaces work. In one of your comments you suggested that you are using a namespace of jabber:socket, but this is not a namespace that is defined anywhere in the XMPP specs and I could not find any reference to it online. Instead, you want to use jabber:client (or jabber:server if this were a server-to-server connection). A quick overview of XML namespaces is below:
All XML elements have a "name", this name is made of two parts: the local name and the namespace. The namespace is defined using an xmlns attribute, for example the following are different elements, they do not have the same name:
<iq xmlns="jabber:client"/>
<iq xmlns="jabber:server"/>
Namespaces declared using an xmlns attribute are inherited by their child elements (unless that element has its own xmlns attribute), therefore in the following:
<session xmlns="jabber:client">
<iq/>
<foo xmlns="bar"/>
</session>
Both the "session" element and the "iq" elements have the namespace "jabber:client" but "foo" has the namespace "bar".
There is also another way to declare a namespace: using a prefix. Prefixes are declared with an "xmlns:prefix" attribute (where "prefix" is the name of the prefix). The list of prefixes is inherited by child elements and don't need to be redeclared, and the namespace defined by the prefix only applies to elements that start with "prefix:". For example:
<stream:stream xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams">
<iq/>
<stream:error></stream:error>
</stream:stream>
In the above the "stream" element has the namespace "http://etherx.jabber.org/streams", because it has the "stream:" prefix. The "iq" element on the other hand has the "jabber:client" namespace because it inherits it from the parents "xmlns" attribute. Finally, the "error" element also has the "http://etherx.jabber.org/streams" namespace because it uses the "stream:" prefix as well. Notice that it did not have to redeclare the stream prefix because it also inherits a list of prefixes from its parent elements, so just applying the prefix without re-defining it is okay.
It's impossible to tell from the level of detail you provided, but chances are you need to add xmlns="jabber:client" to your root element. If you don't have a root element to add it to (ie. when you're using the websocket protocol that sends lot of separate XML documents instead of one long stream), you will have to apply it separately to the root element in every frame you send.
Related
I have the following type in my grammar:
TestSuite:
'TestSuite:' name = ID
'Type:' type = SuiteType;
enum SuiteType:
INTERNAL='1' | EXTERNAL='2';
I would like to read an xml file whenever the property gets a (new) value since I use the contents of that xml file for validation and content completion. Depending on the value of the property, the xml that will be read will be different.
How would you trigger an action that would read the value of a property of a type from the runtime environment's DSL instance?
You could maybe try adding an EMF Adapter to all TestSuite instances such that upon a Notification that changes your 'type' feature to a particular value, the XML file of your choice is read and acted upon.
this blog post seems to do the trick: at the end of the linking phase, an Adapter (this is EMF vocabulary, basically a Listener) can be registered for your TestSuite instances.
Then in your Adapter implementation, you can filter whether you need to react using the methods of Notification such as getFeature().
Since you mention you want to do this for content completion and validation, you may need to do all of this in the scoping / validation phases of Xtext. You will probably have a bit of "lag" upon hitting ctrl+space for auto-completion if your IDE needs to find and parse your XML file, but that's to be expected I guess...
I have been using XOM parser in a project that is mostly over. The parser is very good and I find it mostly stable. However today I was parsing an XML element with an attribute called "xml:lang"
The getAttributeValue("xml:lang") returned null instead of "English". I could find a work around to get the value by using getAttribute(int location).getValue()
However, it would be better to use the method getAttributeValue because the attribute's location changes for other elements.
I am not sure whether I am doing something wrong or a small bug lies there in the library method.
The xml:lang attribute is in a namespace.
To get the value of an attribute in a namespace, use the Element.getAttributeValue(String, String) method. The first parameter needs to be the local name of the attribute (after the colon), which is lang in this case. The second parameter needs to be the URI of the namespace, which is usually defined in an ancestor element. The xml namespace, however, is built in and always has the namespace URI http://www.w3.org/XML/1998/namespace.
Therefore, some code like this should do what you want (assuming you have a variable called element pointing to your element):
String lang = element.getAttributeValue("lang", "http://www.w3.org/XML/1998/namespace");
I have one property file linked both ways (using f:loadBundle and faces-config.xml) both with different var names. So it would look like the following:
datatypes.properties:
A=first
B=second
C=third
faces-config.xml:
<resource-bundle>
<base-name>datatypes</base-name>
<var>myProp</var>
</resource-bundle>
myPage.xhtml:
<f:loadBundle basename="datatypes" var="prop"/>
in myPage.xhtml I make a list of all the keys from the property file. What I can't seem to understand is that when I use #{prop} in the code below it works but when I replace it with #{myProp} the list no longer displays.
<h:form>
<h:selectManyListbox id="list">
<f:selectItems value="#{myProp}"></f:selectItems>
</h:selectManyListbox>
</h:form>
I figure this means the variables in both cases are not the same behind the scenes but I would appreciate it if someone could explain (or point me to an explaination) in what way they are different. I would ideally like to just use #{myProp} without having to pull the keys out in code and store them in a list.
Thanks.
Both <f:loadBundle> and <resource-bundle> are different ways to load properties with difference being in their access scopes. The latter has by the way the additional benefit that the bundle is also injectable in a managed bean by #ManagedProperty("#{myProp}")
Using <resource-bundle> in faces-config.xml creates a global resource bundle which can be accessed anywhere in your application. This is implemented through a java.util.ResourceBundle instance.
Using <f:loadBundle> in your view creates a view-specific resource bundle which is accessible only within that view. The tag handler implements this using an internal implementation of a Map. This is as specified in the VDL of the tag:
Load a resource bundle localized for the Locale of the current view,
and expose it as a java.util.Map in the request attributes of the
current request under the key specified by the value of the "var"
attribute of this tag.
Now since you're trying to use the values from datatypes.properties through <f:selectItems>, you'll get the said exception. This is because the value attribute for the tag should evaluate to a Collection or an array.
Value expression pointing at any Collection or array. The member
elements may be instances of SelectItem or any Java Object.
So in order to use the global bundle instance, you first have to convert the same into a List<SelectItem> inside your backing bean before using it.
NOTE: You can verify the above cases by setting a breakpoint in the initializeItems(Object) method in the com.sun.faces.renderkit.SelectItemsIterator class. This is, of course, assuming that you're using the Mojarra implementation.
GroovyWS is a framework which is internally using CXF. I want to make a request as follows:
<param2 xsi:type="ns2:Map">
<item xsi:type="ns2:Map">
<key xsi:type="xsd:string">param1</key>
<value xsi:type="xsd:string">param2</value>
</item>
</param2>
Currently I am trying to do this from a grails service as following:
def proxy = new WSClient("http://xyz", this.class.classLoader)
proxy.initialize()
proxy.client.invoke("call", new HashMap<String, String>())
Which gives
javax.xml.bind.JAXBException
class java.util.HashMap nor any of its super class is known to this context.
I even tried [:] and stuff but do not get it working.
Well, it's been a while since I did something like this, but I seem to remember that CXF-generated clients had a method called "create", similar to:
def mapObject = proxy.create( "ns2.Map" );
Give that a try and see if the mapObject has the methods or members you're expecting.
This is a known issue with using JAXB
The underlying problem is that your schema is ambiguous.
There are two solutions:
Use name spaces to remove any ambiguity
Resolve each Service individually into a different Java package.
How does exactly the following code work:
#{aaa.id}
<h:inputText id="txt1" binding="#{aaa}"/>
I mean, usually the component binding works, by specifying a property (of type UIComponent) in a bean. Here, there's no bean nor property but nevertheless the name "aaa" gets bound correctly (displaying the component id - "txt1"). How does it work/where is it specified?
Thanks
UPDATE: The JSF2.0 Spec [pdf] (Chapter 3.1.5) says:
"A component binding is a special value expression that can be used to facilitate “wiring up” a component instance to a
corresponding property of a JavaBean... The specified ValueExpression must point to a read-write JavaBeans property of type UIComponent (or
appropriate subclass)."
It's been put in the default EL scope during building of the view tree (that's when all binding attributes -- and attributes of tag handlers like JSTL <c:xxx> and JSF <f:xxx> -- are being evaluated). It's being shown by normal EL means during rendering of the view tree. Rendering of the view tree happens after building of the view tree, so it works that way. It's not that this code runs "line by line" as you seemed to expect from the source.
I can't point you out a single reference where it's been specified as there is none. You'd have to read both the EL spec and JSF spec separately and do a 1+1=2.
By the way, to avoid confusion among new developers and to avoid clashes with existing variables in the EL scopes, you can use a java.util.HashMap in the request scope which is been declared as follows in faces-config.xml:
<managed-bean>
<description>Holder of all component bindings.</description>
<managed-bean-name>components</managed-bean-name>
<managed-bean-class>java.util.HashMap</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
and is been used as follows
#{components.aaa.id}
<h:inputText id="txt1" binding="#{components.aaa}"/>
which is more self-documenting.
See also:
How does the 'binding' attribute work in JSF? When and how should it be used?