Jason Irwin

Ranch Hand
+ Follow
since Jun 09, 2009
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jason Irwin

I am trying to connect to a REST service using Restlet.
The service uses SOAP messages defined by a WSDL as the requests and responses.
I have used JAXB to create classes based on the WSDL.
What I cannot work out how get at the SOAP XML string.

My sample code is below, I can connect to the service as I successfully receive a challenge (which I need to write a custom authentication helper for...)

Maybe JAXB is not the right thing to be using?
Would something other than Restlet be better? I was using it as it seemed to allow me to define my own code to handle the authentication challenge.
12 years ago
I am not sure that JS is 100% valid Terry, I would have done it like this:

I don't see why you want the "value" of the anchor, you're going to call its "click" event.
13 years ago
When I was first trying it I was getting a NullPointerException from the EL value expression. That, coupled with Eclipse flagging the EL expression as being invalid, made me think I needed a special handler of some kind.

And, of course, when I now go to get a copy of the stack trace it works perfectly - which is what I thought was supposed to happen, hence why I was so confused!

Thanks for the help, I'll check the bug reports for Eclipse. It shouldn't be flagging that EL.
13 years ago
Whichever framework you are using should have a guessable way of generating the ID. It's usually something like "form:layout-panels:control-id" (if you are unsure, you can just do "View Source" in the browser and work out what convention your framework uses.
Once you know that, it's pretty simple JS to get the element by ID and then invoke the click function.
Even if you can't get the ID, you can either iterate the DOM or get elements by type and iterate those. What exact JS you use depends on what browser you are using.
13 years ago
I am having another period of frustration. Reading from the data map is easy enough, but how do you set a value on it?

And in the backing bean

I've been Googling my little fingers off, but I cannot find where this is documented. Is it even possible?
13 years ago
I've written a RichFaces application where I dynamically show/hide a modal panel and have it centralised as well. This is the definition I used (JSF 1.2, Richfaces; tested on IE6-8, FireFox [(Windows and Linux], Opera, Chrome[Windows and Linux]).

The "trick" is, I think, to have "left" and "right" set to"auto". I am not running a RichFaces environemtn at the moment, so I cannot test it myself (I have a nasty feeling that this does not re-centre itself if the browser window is resized).
If that does not work for you, your only other option is to use some JS to calculate the required position.
Also, there appears to be some few issues reported on JIRA with regards to the modalPanel (often down to a combination of RichFaces version and browser).
13 years ago

Tim Holloway wrote:You can also split the difference. If only some items in the backing bean are changeable, you can put them in a mapped object and use an EL expression that uses mapped data references such as "#{myBean.dataMap[mapKey]}".

Thanks Tim! You replied just as I was editing my own post. I'll look into using a map approach and see if it fits my needs.
I am not trying to do "one bean to bind them all" (or, at least, I don't think I am) it's just that a few of the use cases are a bit more dynamic than others.
Your solution of adding child controls dynamically may be something else I'll need to look at as it seems to be in a similar area to what I am investigating.
13 years ago
To answer my own question....use a value change listener with a dummy "set" method.

And then the bean...

When the form gets submitted, the value change listener will set the new value in the private map and this value will be read back in the getter. The setter is not actually used, but is still required by the framework. I would rather not use a value change listener for clarity in the page, but I was having issues getting the current component and this workaround seems to be OK.
13 years ago
According to the API docs, UIComponent.getCurrentComponent(FacesContext) should return the UICompnoent that is currently processing. Unfortunately it is not doing this, or I am not understanding why it returns the component I am seeing. I am using JSF 2.0, Mojarra.

I have a very simple form:

The backing bean has the relevant getter and setter:

As I have stated in the comments, "UIComponent.getCurrentComponent" does not consistently return the "inputText", it quite often returns the "panelGrid". I totally understand that the "panelGrid" will be restored during the Faces lifecycle, but it is not bound to "[get|set]AttrValue", only the "inputText" is.

Why am I seeing "panelGrid" as the current component in the "[get|set]AttrValue"?
13 years ago
I am trying to do something which I think should be simple, but I am probably going about it the wrong way.

Imagine I have an XML file that contains name-value pairs (in reality it could be a database or naything else I plug into the back-end).

And then I have some page that gets those values from the backing bean, maybe using them as defaults

That's fairly trivial and at some point in the future I can add another "h:inputText" to use "bar", but I would need to change the backing class and that is something I'd like to avoid. I could use EL 2.2 and have a parameter, but based on Tim's post I fear I might be breaking the whole MVC concept and I don't want to do that either! Also, I don't think it would work when the user makes changes to the values, it would keep getting the defaults from the XML file as it has no way of accessing the setter.

I was thinking of updating a hidden "h:inputText" or something to hold key/value pairs; but that struck me as very messy and still left me with the problem of reading the value back at render time.
So is there a way to do what I need? To call a single "property" and get/set values for "foo" and "bar" as appropriate (a bit like a "property bucket" or "property bag"), without having to modify the backing bean for each new control that gets added?

Thanks in advance.
13 years ago
I have a very simple web service interface...

An implemenation of it...

And simple publisher...

What I intended to look at as "wsgen" and how it creates the JAXB artefacts. So I removed the "@SOAPBinding" from the interface declaration and ran the publisher. What I was expecting to get was an exception like "runtime modeler error: Wrapper class crude.server.jaws.AddNums is not found" as the WebService was now in the Document style rather than RPC. Instead the missing classes were dynamically created and the service became available. When I tried the same thing with M. Kalin's "TimeServer" code I get the expected "not found" exception.

This drove me completely crazy until I remembered that the classpaths for the two projects (I'm using Eclipse) were different. The key jar appears to be "webservices-rt.jar" that comes with Glassfish. As soon as I add that to my project and try to run the publisher, I get the exception I expect. So obviously some default behaviour in the JDK is causing the classes to be dynamically generated and the Glassfish jar does not do this.

Does anyone know what in the JDK is causing the classes to be dynamically created and if this behaviour can be controlled?

The "signature"? Personally I'd say the Bare code has one parameter ("MyNumbers" or "AddNums") and the Wrapped two ("num1" and "num2"), .
The WSDLs are identical, which makes sense as the SOAP messages are also identical.
Interestingly, the XSDs differ. In the Bare form the "addNumsReponse" is just "int". Makes sense, this is Bare! And in the Wrapped we have an "addNumsResponse" that wraps a "return" element which is an "int". Which also makes sense (I had no annotations anywhere about the response).

I may just mail Mr. Kalin, but I rather doubt I'll get answer.

Thanks for all your help, things are a bit clearer.
13 years ago
I'm more stubborn than a mule with a bad attitude.

This is pretty much what I arrived at last night using "wsimport" and fiddling about. When using the "Bare" parameterStyle, you can only have one parameter and need to contain all the relevant data in there.
That to me seems a bit counter-intuitive. "Bare" means the multiple parameters need to be "wrapped" in another object?
But of course "Bare" refers to the structure of the SOAP messages that are used, not the code itself. Either parameters are contained in a "Wrapping" element within the SOAP Body, or they are "Bare" and the Body contains n "parameter" elements (as in example 2.8). Unfortunately WS-I 1.1 prohibits multiple parameters in the Body, so you are stuck with one. Leading to the confusing situation that "Bare" and "Wrapped" messages look identical (as I found out when I used Wireshark to grab the SOAP Messages sent to the servers above.


In the first the "wrapping" has been done at the code level, if you follow me. Only one parameter was passed ("addNums") and it was "Bare" in the body. In the second, the parameters were "bare" in the code, but "wrapped" at run-time by JAX-WS and what have you.

Does that seem like a reasonable summary of the situation?

So I come back to the SOAP message in example 2.8. As far as I can tell it cannot be used to call a web service. Or, if it can, I am at a total loss on how to code for it.

I can clearly see why Wrapped/Document/Literal is the default, it seems to lead to much easier coding (at least in Java and from what I have tried so far. I'll probably end up eating those words in a month! )

Thanks for all your time in this.
13 years ago
Thanks Ivan, but I as I am running Java 6 thought I was using Soap 1.2 which can have multiple child elements.

Uhh...wait...the WS-I has further restrictions. So although SOAP can handle more data, the WS-I doesn't allow that (not in 1.1 at least). Would that be a fair summary?

So whilst example 2.8 (with multiple child elements in the SOAP body) is valid SOAP, it is invalid for calling a WS-I method.
So, really, it has no place in a book about Java Web Services. Would that be fair say?

I ran the server shown above and used "wsimport" to create 2 sets of stub classes. One Wrapped and one forced to be Bare via a JAXWS xml file (as shown on page 53).
I then wrote some test code against those and ran it, using Wireshark to capture the messages.
The SOAP messages sent looked identical. No difference at all. Now I am truly stumped.

To be honest if I can't bet past page 45 without being totally confused and lost, there's not much hope for me in ever understanding this!
13 years ago