Ole Hornischer

Hi!
Is it possible to add schema restrictions to parameters via JAX-WS annotations?

Example:
I have a method
@WebMethod ReturnContainer<List<Street>> getStreets(@WebParam(name = "streetname")String streetname);
The parameter streetname should always be longer then 3 characters, to avoid gigantic result lists. I would like this to be a restriction in the schema like
<xs:element name="streename"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:minLength value="3"/> </xs:restriction> </xs:simpleType> </xs:element>
How can I make sure that the generated WSDL file includes such a restriction on the parameter?

Cheers
Ole

I figured it out by now. Various small things, amongst which I checked the wrong address in my browser

Hi everybody!
I am having troubles deploying my webservice (code snippets below). I tried the contract-first approach and wrote my wsdl. Then I let CXF generate sources through maven. Then I went through the config files and tried to understand how it all works together and why it doesn't. Because when I publish the project on Tomcat through eclipse the Tomcat starts normally, but has only very little output (I have a feeling the webservice is not recognized properly) and neither through http://localhost:8080/Webservice/services/Webservice?wsdl nor through the tool seapUI i get a connection to the service. How can I debug the deployment process and see where it goes wrong. Or can someone here see in my files what is crooked?
Do you need any details from the java classes? If so which ones?

Thanks for the help!
Ole

wsdl
<?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions name="MassPrintingInternalInterface" targetNamespace="http://impl.service.project/" xmlns:ns1="http://intf.service.project/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://impl.service.project/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"> <wsdl:types> <xsd:schema targetNamespace="http://impl.service.project/"> <xsd:element name="PrintMetadata"> <xsd:complexType> <xsd:sequence> <xsd:element minOccurs="0" name="dokumentId" type="xsd:string" /> <xsd:element minOccurs="0" name="plz" type="xsd:int" /> <xsd:element minOccurs="0" name="bezirk" type="xsd:int" /> <xsd:element minOccurs="0" name="druckVariante" type="tns:Druckvariante" /> <xsd:element minOccurs="0" name="blattzahl" type="xsd:int" /> <xsd:element minOccurs="0" name="bescheidId" type="xsd:string" /> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:simpleType name="Druckvariante"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="STANDARD" /> <xsd:enumeration value="INFOPOST" /> <xsd:enumeration value="MANUELL" /> <xsd:enumeration value="BESCHEID" /> <xsd:enumeration value="PZU" /> <xsd:enumeration value="LISTE" /> </xsd:restriction> </xsd:simpleType> <xsd:element name="RegistrationResult"> <xsd:simpleType> <xsd:restriction base="xsd:boolean" /> </xsd:simpleType> </xsd:element> <xsd:element name="IllegalMetadataException"> <xsd:complexType> <xsd:all> <xsd:element name="errorMessage" type="xsd:string" /> </xsd:all> </xsd:complexType> </xsd:element> </xsd:schema> </wsdl:types> <wsdl:message name="RegisterMetadataRequest"> <wsdl:part name="printMetadata" element="tns:PrintMetadata" /> </wsdl:message> <wsdl:message name="RegisterMetadataResponse"> <wsdl:part name="registrationResult" element="tns:RegistrationResult" /> </wsdl:message> <wsdl:message name="RegisterMetadataFault"> <wsdl:part name="registrationFault" element="tns:IllegalMetadataException" /> </wsdl:message> <wsdl:portType name="MassPrintingInternalInterface"> <wsdl:operation name="registerMetadata"> <wsdl:input message="tns:RegisterMetadataRequest" /> <wsdl:output message="tns:RegisterMetadataResponse" /> <wsdl:fault name="IllegalMetadataException" message="tns:RegisterMetadataFault" /> </wsdl:operation> </wsdl:portType> <wsdl:binding name="MassPrintingInternalInterfaceSoapBinding" type="tns:MassPrintingInternalInterface"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="registerMetadata"> <soap:operation soapAction="" style="document"/> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> <wsdl:fault name="IllegalMetadataException"> <soap:fault name="IllegalMetadataException" use="literal"/> </wsdl:fault> </wsdl:operation> </wsdl:binding> <wsdl:service name="MassPrintingInternalInterfaceService"> <wsdl:port name="MassPrintingInternalInterfacePort" binding="tns:MassPrintingInternalInterfaceSoapBinding"> <soap:address location="http://localhost:8080/MassPrintingInterface/services/MassPrintingInternalInterface"/> </wsdl:port> </wsdl:service> </wsdl:definitions>

beans.xml
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jaxws="http://cxf.apache.org/jaxws" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd"> <import resource="classpath:META-INF/cxf/cxf.xml" /> <import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" /> <import resource="classpath:META-INF/cxf/cxf-servlet.xml" /> <jaxws:endpoint xmlns:tns="http://impl.service.project/" id="MassPrintingInternalInterface" implementor="project.service.impl.MassPrintingInternalInterfaceImpl" address="/MassPrintingInterface/services/MassPrintingInternalInterface"> <jaxws:features> <bean class="org.apache.cxf.feature.LoggingFeature" /> </jaxws:features> </jaxws:endpoint> <jaxws:endpoint xmlns:tns="http://impl.service.project/" id="MassPrintingExternalInterfaceService" implementor="project.service.impl.MassPrintingExternalInterfaceImpl" address="/MassPrintingInterface/services/MassPrintingExternalInterface"> <jaxws:features> <bean class="org.apache.cxf.feature.LoggingFeature" /> </jaxws:features> </jaxws:endpoint> </beans>

web.xml
<?xml version="1.0" encoding="UTF-8"?> <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID" version="2.5"> <display-name>MassPrintingInterface</display-name> <welcome-file-list> <welcome-file>index.html</welcome-file> <welcome-file>index.htm</welcome-file> <welcome-file>index.jsp</welcome-file> <welcome-file>default.html</welcome-file> <welcome-file>default.htm</welcome-file> <welcome-file>default.jsp</welcome-file> </welcome-file-list> <servlet> <display-name>Apache-Axis Servlet</display-name> <servlet-name>AxisServlet</servlet-name> <servlet-class>org.apache.axis.transport.http.AxisServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>AxisServlet</servlet-name> <url-pattern>/servlet/AxisServlet</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>AxisServlet</servlet-name> <url-pattern>*.jws</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>AxisServlet</servlet-name> <url-pattern>/services/*</url-pattern> </servlet-mapping> <servlet> <display-name>Axis Admin Servlet</display-name> <servlet-name>AdminServlet</servlet-name> <servlet-class>org.apache.axis.transport.http.AdminServlet</servlet-class> <load-on-startup>100</load-on-startup> </servlet> <servlet-mapping> <servlet-name>AdminServlet</servlet-name> <url-pattern>/servlet/AdminServlet</url-pattern> </servlet-mapping> <servlet> <description>Apache CXF Endpoint</description> <display-name>cxf</display-name> <servlet-name>cxf</servlet-name> <servlet-class>org.apache.cxf.transport.servlet.CXFServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>cxf</servlet-name> <url-pattern>/services/*</url-pattern> </servlet-mapping> <session-config> <session-timeout>60</session-timeout> </session-config> <context-param> <param-name>contextConfigLocation</param-name> <param-value>WEB-INF/beans.xml</param-value> </context-param> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> </web-app>

content of the war file:
file.war
|-META-INF
|---MANIFEST
|---maven
|----- ...
|-WEB-INF
|---classes
|-----...
|---lib
|-----...
|---beans.xml
|---web.xml
|-wsdl
|---MassPrintingInternalInterface.wsdl
|---MassPrintingExternalInterface.wsdl

That was my first idea as well, but I recompiled both applications again with current sources and made sure that there is only one occurence of the class file in the classpath of both applications (which are by now merged to one exploded ear).

I did not know about Seam BI, so I will look into that, I used JNDI because I knew how to. Is there some kind of incompatibility between Seam and JNDI?

The Stacktrace is:

Caused by java.lang.ClassCastException with message: "com.tza.dto.RegisteredClientDTO cannot be cast to com.tza.dto.RegisteredClientDTO" com.tza.management.action.ClientLister.viewList(ClientLister.java:44) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:597) org.jboss.seam.util.Reflections.invoke(Reflections.java:22) org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:32) org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56) org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28) org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77) org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44) org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107) org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:185) org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:103) com.tza.management.action.ClientLister_$$_javassist_seam_4.viewList(ClientLister_$$_javassist_seam_4.java) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:597) org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:335) org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:348) org.jboss.el.parser.AstPropertySuffix.invoke(AstPropertySuffix.java:58) org.jboss.el.parser.AstValue.invoke(AstValue.java:96) org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276) org.jboss.seam.core.Expressions$2.invoke(Expressions.java:175) org.jboss.seam.navigation.Pages.callAction(Pages.java:692) org.jboss.seam.navigation.Pages.preRender(Pages.java:330) org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:561) org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:472) org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:148) org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:118) com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214) com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96) com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) javax.faces.webapp.FacesServlet.service(FacesServlet.java:266) org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83) org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40) org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90) org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64) org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45) org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178) org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290) org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390) org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517) org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56) org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60) org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) org.jboss.seam.web.HotDeployFilter.doFilter(HotDeployFilter.java:53) org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158) org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182) org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432) org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157) org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262) org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446) java.lang.Thread.run(Thread.java:619)

And ClientLister is:

@Name("clientLister") public class ClientLister { @DataModel //List<RegisteredClientDTO> registeredClients; List<String> registeredClients; private ManagementService bean; public String viewList() { try { this.connect(false); this.registeredClients = new ArrayList<String>(); List<RegisteredClientDTO> result = bean.getRegisteredClients(); for (int i = 0; i < result.size(); i++) { this.registeredClients.add(result.get(i).getIP()); } return "/client_list.xhtml"; } catch (NamingException e) { throw new ConnectionException(e); } } private void connect(boolean reconnect) throws NamingException { if (this.bean == null || reconnect) { InitialContext ctx = new InitialContext(); Object ref = ctx.lookup("ManagementService"); Object obj = javax.rmi.PortableRemoteObject.narrow(ref, ManagementService.class); this.bean = (ManagementService) obj; } } }

Hey everyone!
I have a weird problem. I get ClassCastExceptions of the following kind while using EJB stateless session beans from my seam project:

Caused by javax.el.ELException with message: "java.lang.ClassCastException: com.tza.dto.RegisteredClientDTO cannot be cast to com.tza.dto.RegisteredClientDTO"

The history: I have an application, that used to be deployed as an ear file in my app server and served to a set of java clients. All worked fine. Now I wanted to add a web component to the application providing visualisation for some data retrieved from the sever ear. So at first I created a seam war file accessing stateless session beans on the server ear to retrieve the data. But that wouldn't work. I got said ClassCastExceptions.
I then packaged the old application and the new web app into one big ear file. The data was still accessed via SSBs and I have the same problem.

Somewhere I read that this can be caused by duplicate class files in the classpath, so i cleaned up the cp and now do not have any doubles left - same problem.

The example exception I get after trying to access objects from a List<RegisteredClientDTO> I retrieved via an EJB from the server app to my web app.

Any ideas what could cause this behaviour?

--Ole

Hello everybody!
I recently started working with JBoss Seam and am amazed by the potential of this framework. However there is one issue I could not tackle so far. It is page navigation. I already read through quite some tutorials and examples and am convinced that my settings are correct, however when I run my website i do not get redirected.

(Code follows)
If I enter a search term on my home.xhtml and click the search button Seam does call the search function, however after it successfully finished (and found the correct amount of list items) I end up on the home.xhtml again, as if nothing happened, insted of being redirected to search_result.xhtml. This is only one example, redirects on other pages, like registration, do not work either.

Can anyone see what I am doing wrong?
Any help is greatly appreciated.
Cheers,
Ole

home.page.xml
<?xml version="1.0" encoding="UTF-8"?> <page xmlns="http://jboss.com/products/seam/pages" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://jboss.com/products/seam/pages http://jboss.com/products/seam/pages-2.2.xsd"> <navigation from-action="#{itemFinder.search}"> <rule> <redirect view-id="/search_result.xhtml"/> </rule> </navigation> </page>

ItemFinderBean.java
@Stateful @Name("itemFinder") public class ItemFinderBean implements ItemFinder { static final String EJBQL = "select item from Item item "; @PersistenceContext EntityManager em; @In @Out(required = false) String criteria; @DataModelSelection @Out(required=false) Item item; @DataModel private List<Item> results; public void search() { StringBuilder searchPattern = new StringBuilder(); searchPattern.append("%"); if (criteria != null && criteria.trim().length() != 0) { searchPattern.append(criteria.toLowerCase().replace('*', '%')).append('%'); } results = em.createQuery(EJBQL + "WHERE lower(item.title) LIKE :search " + "OR lower(item.description) LIKE :search") .setParameter("search", searchPattern.toString()).getResultList(); } public void showItem() { if (item == null) throw new ItemNotFoundException(); } @Remove @Destroy public void destroy(){} }

Snippet from home.xhtml
<h:form> <table> <tr> <td><h1>Suche</h1></td><td><h:inputText value="#{criteria}" /></td> <td><h:commandButton type="submit" value="Finden!" action="#{itemFinder.search}" /></td> </tr> <tr><td></td><td><a >Erweiterte Suche</a></td></tr> </table> </h:form>

Sorry for resurrecting a zombie.

I pretty much was just wondering about how Java does calculate the time.
The server is on a completely wrong timezone, so it is technically a problem for the admin, but I was surprised about the unexpected difference in "Europe/Berlin" and "Europe/Paris" on our JBoss server.

I did google a bit more, and did read about the tzmapping file and how different JVMs map the system tz to Java tz.
And HPUX JVM is significantly different to Windows JVM as I could see.

Anyhow, in the end it does not matter, as I mentioned above, it was plain curiosity.

--Ole

Hi everyone!
I just encountered an odd phenomenon yesterday and am wondering now, whether it is a timezone related effect.

Our clients server was set to timezone Europe/Berlin and was always off by about 90-100 sec (can't recall exactly how much, location is Krefeld in Germany). Once we switched the server to run on timezone Europe/Paris the times were correct (to a few seconds). I always thought Java also handles timezones by the hours and not by the longitude. So are those seconds difference due to the different timezones (although Paris and Berlin should be on the same time) or is the effect caused by sth else and just happens to be fixed with the timezone for Paris?

Regards,
Ole

Ulf Dittmer wrote:... but I don't think you can disable the dialog asking the user to approve unknown certificates.

In the Windows Control Panel in the Java Menu one can (Tab "Advanced" --> "Security") disable the user to give rights to signed contents or to give rights to non trusted contents (hard to translate from German). I figured that would be the option to disable the user to accept new certificates.

Pat Farrell wrote: Can the users run another browser?

Can they install another JRE?

I suppose it should be possible for the admins to restrict those options (simply install only one browser and disable the user to install any applications)

--Ole

Hey!
Does noone know the answer? A "it's not possible" would also help.
-- Ole

Hey everybody!
Does anyone know whether it is possible to restrict Java (1.6) to use only its own certificate storage?

My problem is the following:
Our client wants to restrict the use of webstart in his company. In order to do so, he would like to define a certain set of trusted certificates inthe Java certificate storage and then disable the user to trust new certificates. Like this the user can only use the webstart applications the customer approved, all others are only possible to be used in a sandbox.

But as far as I know Java (1.5+) also reads the system certificate storage, which is a problem, since that contains a lot more certificates (at my customers).

Is is possible to achieve this goal?

Cheers,
Ole

commons logging works great, configuration was very easy, once i renamed my properties file to the default log4j.properties.

Hi!
I used the TZALogger class to encapsulate the log4j and let it be configured in a central place.
But I now learned about the common-logging library, which apparently does exactly this. So I will try to switch to that and hope my problems will be solved.
(I worked a bit more on that issue on friday and the configuration showed very strange behaviour: When configuring, the target log files where created, but logs in the same class would just not log. Logging from another class (with the same configuration) worked just fine. So I am guessing the error was deeper and am hoping that switching to common-logging will solve the issue(s))
--Thelonius

I create it via log4j. the properties file is located in the signed jar and being loaded from there. That apparently works, because the application does create the log files. It simply does not write to them.

Properties props = new Properties(); InputStream str = null; try { str = SignedJarFileLoader.openTextFileStream(this.getClass(), ConfigFactory.getPrefix()+"logging.properties"); props.load(str); PropertyConfigurator.configure(props); Logger.getLogger(TZALogger.class).debug("log4j Logger works."); } catch (IOException e) { // TODO Handle exception properly e.printStackTrace(); }