[Persistence, JBoss/CMP, Hibernate, Database] - Type Mapping Oracle 9i
by derharri
Hello,
i am using Jboss 4.0.4 with EJB2.1 and a Oracle Database.
In my database there are tables containing CLOB fields.
The EJB accessing these tables use a "special" jbosscmp-jdbc.xml in which i explicitely define the CLOB type for the relevant fields.
<cmp-field>
| <field-name>lsData</field-name>
| <column-name>LSDATA</column-name>
| <jdbc-type>CLOB</jdbc-type>
| <sql-type>CLOB</sql-type>
| </cmp-field>
That works fine but makes me have to use different jbosscmp-jdbc.xml files for different databases (e.g SQLServer).
Maybe i misunderstood something but i think normaly such type-mapping has do be done in standardjbosscmp-jdbc.xml in the conf directory of my used server implementation.
But when i define the CLOB mapping in that file it does not work.
<mapping>
| <java-type>java.lang.String</java-type>
| <jdbc-type>CLOB</jdbc-type>
| <sql-type>CLOB</sql-type>
| </mapping>
JBoss does not throw neither an exception nor error or warning.
The accessing method in the bean just returns null such as if the db field contains null. I draw the conclusion, that JBoss just has problems reading the db data of the CLOB field.
Can someone explain why my the "global" mapping does not work?
Maybe i just forgot something else?
Thanks for your help
Harri E.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038407#4038407
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038407
19 years, 2 months
[JBossWS] - Recognising a wrapped doc literal web service in Visual Stud
by benvenutto
Confusingly the User Guide in the section on wrapped doc literal states:
Wrapped is an implementation detail from the Java domain. Neither in the abstract contract (i.e. wsdl+schema) nor at the SOAP message level is a wrapped endpoint recognizable.
I can deploy the following web service:
| @WebService
| @SOAPBinding(
| style = SOAPBinding.Style.DOCUMENT,
| use = SOAPBinding.Use.LITERAL,
| parameterStyle=SOAPBinding.ParameterStyle.WRAPPED)
| public class Boing
| {
| /**
| * Should generate a wrapped document literal interface.
| *
| * @param payload
| * @return
| */
| @WebMethod
| @WebResult (name = "bouncedPayload")
| public byte[] bounce(
| @WebParam(name = "token")
| String token,
| @WebParam(name = "payload")
| byte[] payload)
| {
| return payload;
| }
|
But in Visual Studio 2005 the web reference appears as bare, wrapped is not detected! This is under JB 4.2.0 CR1.
Many thanks
Simon
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038404#4038404
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038404
19 years, 2 months
[JBoss Seam] - Re: HOWTO: override ThemeSelector (valueChangeListener, cook
by avbentem
I tested with yesterday's CVS head, and it seems to work fine.
Please note that the current LocaleSelector#setLocale(Locale) and setLocaleString(String) do not call the setter methods, which invoke isDirty. I can't find any problems with this, but don't know if the isDirty is important here.
No problems at all using the new ThemeSelector#selectTheme(String).
As for the auto-submit:
First, for the archives, taken from MyFaces wiki: note that for checkboxes and radio buttons you will want to use onclick instead of onchange as IE6 fires the onchange during 'blur' instead of the actual change of these input controls whereas onclick is fired when the value is actually changed for all browsers.
Secondly:
"gavin.king(a)jboss.com" wrote : I don't see why overloading should be a problem, but if it is, please let me know.
I guess I got confused due to (for testing purposes) using BOTH <h:commandButton> and onchange="submit()" within the very same <h:form>. So, I had two dropdowns, one with the button and another with the onchange handler:
<h:form ...>
| <span class="menuItem">
| <h:selectOneMenu value="#{themeSelector.theme}">
| <f:selectItems value="#{themeSelector.themes}"/>
| </h:selectOneMenu>
| <h:commandButton action="#{themeSelector.select}"
| value="Select Theme"/>
| </span>
| <span class="menuItem">
| <h:selectOneMenu value="#{themeSelector.theme}"
| onchange="submit();"
| valueChangeListener="#{themeSelector.select}">
| <f:selectItems value="#{themeSelector.themes}" />
| </h:selectOneMenu>
| </span>
| </h:form>
which yields:
<form id="j_id3" name="j_id3" method="post" ...>
| <span class="menuItem">
| <select name="j_id3:j_id8" size="1">
| <option value="default" selected="selected">Default</option>
| <option value="accessible">Accessible</option>
| <option value="printable">Print</option>
| </select>
| <input type="submit" name="j_id3:j_id10" value="Select Theme" />
| </span>
| <span class="menuItem">
| <select name="j_id3:j_id12" size="1" onchange="submit();">
| <option value="default" selected="selected">Default</option>
| <option value="accessible">Accessible</option>
| <option value="printable">Print</option>
| </select>
| </span>
| </form>
Seeing no Javascript above to somehow register which input the user touched last, I guess using two dropdowns (or three, ..., within the same form) to achieve the very same thing is not supposed to be supported (probably the reason why Apache Trinidad supports autoSubmit). Ok, no problem, ready.
But if it is supposed to be supported, then I can investigate further. I surely am no JSF expert though. First impression, using Firefox: JSF seems to know which method to invoke, probably because Firefox does not send the button name when using submit() to post the form. However, it sometimes seems to use the wrong value (like the value from another dropdown) to determine what the user has selected. In some quick tests I can simultaneously use both the <h:commandButton> and onchange="submit()" for ThemeSelector, but only if the onchange-version is the first. This also applies to the LocaleSelector, but then the dropdown would still show the previous language as being the selected choice, even though the page would be rendered using the new language. When defining the onchange-version as the second dropdown, then the version with the submit button no longer has any effect.
Changing the method names makes no difference. Also the value for immediate does not seem to change the behavior.
I also noticed that, when changing the theme, LocaleSelector#setLocaleString is invoked as well, even twice. But when changing the locale, ThemeSelector does not get called. If that rings any alarm bells then please let me know and I can debug some more. But I guess it's not an issue at all. Obviously, only using a single dropdown in the form solves all issues.
Thanks,
Arjan.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038396#4038396
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038396
19 years, 2 months