Never having use Wicket before I installed Apache Wicket 8.0.0-M8 on Windows 10. I also installed apache-tomcat-9.0.7.
I replaced the following Tomcat conf folder files with those provided by wicket:
context.xml, server.xml
I used Eclipse Neon's Maven option to create a project called myproject. Eclipse generated the following web.xml file which I relocated to:
<TOMCAT_HOME>\webapps\myproject\WEB-INF
That web.xml file looks like this:
<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/web-app_4_0.xsd" version="4.0">
<display-name>myproject</display-name>
<!--
There are three means to configure Wickets configuration mode and they
are tested in the order given.
1) A system property: -Dwicket.configuration
2) servlet specific <init-param>
3) context specific <context-param>
The value might be either "development" (reloading when templates change) or
"deployment". If no configuration is found, "development" is the default. -->
<filter>
<filter-name>wicket.myproject</filter-name>
<filter-class>org.apache.wicket.protocol.http.WicketFilter</filter-class>
<init-param>
<param-name>applicationClassName</param-name>
<param-value>com.quantech.myproject.WicketApplication</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>wicket.myproject</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
</web-app>
Eclipse found the following problems with this file:
Referenced file contains errors (http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/web-app_3_1.xsd). web.xml /myproject/src/main/webapp/WEB-INF line 1 XML Problem
TargetNamespace.1: Expecting namespace 'http://java.sun.com/xml/ns/javaee', but the target namespace of the schema document is 'http://xmlns.jcp.org/xml/ns/javaee'.
When I load web.xml into XMLSpy I get the message:
This file is not valid. Root element 'web-app' is not defined in DTD/Schema.
Anyone have a clue what is wrong here?
thanks,
Terry
I replaced the following Tomcat conf folder files with those provided by wicket:
context.xml, server.xml
Wicket doesn't provide such files!
Eclipse generated the following web.xml file
Eclipse found the following problems with this file:
Bad Eclipse!
Just ignore these errors/warnings. Tomcat won't complain.
To make Eclipse happy you will have tweak its configuration. I can't help you with that though. I use different IDE.
Related
I created library using helidon-messaging, helidon-messaging-kafka. Also I created an example Java SE app using that library and all works fine. But when I try to use that library in Java EE (Weblogic) legacy application I have got an exception while that application starts:
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Config with qualifiers #Default
at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] #Inject io.helidon.messaging.connectors.kafka.KafkaConnector(Config)
at io.helidon.messaging.connectors.kafka.KafkaConnector.<init>(KafkaConnector.java:0)
Is it possible some how to switch off CDI stuff there?
Did you try to exclude the connector package from bean scanning?
Something like this should help:
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd"
version="2.0"
bean-discovery-mode="annotated">
<scan>
<exclude name="io.helidon.messaging.connectors.kafka.**" />
</scan>
</beans>
More info can be found here
I'm using Wildfly 11 with Java 8. Previously I was building a WAR file, which required the dom4j JAR file. Rather than including it in the WAR's WEB-INF/lib directory, I linked to the Wildfly modules JAR by adding an entry in the WEB-INF/jboss-deployment-structure.xml. Now I want to package this WAR as part of an EAR. So I created a jboss-deploymebnt-structure.xml file at teh root of the EAR, with these lines
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<sub-deployment name="myapp.war">
<dependencies>
...
<module name="org.dom4j" />
Now when I deploy the EAR, the WAR is failing to deploy with errors like
service jboss.undertow.deployment.default-server.default-host./myapp: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./orgsclient: java.lang.RuntimeException: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class path resource [META-INF/spring/infrastructure.xml]: Invocation of init method failed; nested exception is java.lang.NoClassDefFoundError: org/dom4j/io/STAXEventReader
What else do I need to do to tell the EAR file that the WAR is using the Wildly module dom4j as opposed to one I'm packaging with the EAR itself?
Check if your jboss-deploymebnt-structure.xml is correctly placed in META-INF subfolder (beside with application.xml) of your built ear package. If you're using maven ear plugin you should put the xml file in:
ear/src/main/application/META-INF/jboss-deploymebnt-structure.xml
Please note the application folder is default resource folder for ear plugin.
If you still have a problem with NoClassDefFound, try to redeclare the dependency as 'ear global' and set it as exported
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="org.dom4j" slot="main" export="true"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
If you still have a problem then declare the module as a global module in wildlfy config (under the ee subsystem). Then you can get rid off the the jboss deployment descriptor at all.
<subsystem xmlns="urn:jboss:domain:ee:4.0">
<global-modules>
<module name="org.dom4j">
</global-modules>
...
Have been trying to apply a transformation to one of my config files in Visual Studio 2010
The target file starts like this:
forms.config
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:x="http://www.sitecore.net/xmlconfig/">
<sitecore>
<formsDataProvider type="Sitecore.Forms.Data.DataProviders.WFMDataProvider,Sitecore.Forms.Core">
<param desc="connection string">connection string goes here</param>
</formsDataProvider>
...
The transformation file is as follows:
forms.Staging.config
<?xml version="1.0" encoding="utf-8" ?>
<!-- For more information on using transformations
see the web.config examples at http://go.microsoft.com/fwlink/?LinkId=214134. -->
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:x="http://www.sitecore.net/xmlconfig/" xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<sitecore>
<formsDataProvider type="Sitecore.Forms.Data.DataProviders.WFMDataProvider,Sitecore.Forms.Core">
<param desc="connection string" xdt:Transform="Replace" xdt:Locator="Match(desc)">connection string for staging goes here</param>
</formsDataProvider>
</sitecore>
</configuration>
When the staging build runs on Octopus this is what's in the log:
DEBUG [XML Transformation] The expected namespace http://schemas.microsoft.com/XML-Document-Transform was not found in the transform file.
Have tried to remove the other xmlns attributes to no avail.
Said namespace is clearly on the transform file as an attribute in the configuration node. We have numerous other such files and transformations are applied fine. The Build Action for all transform files is set to Content.
Not sure if we can make Octopus log such messages as errors instead of Debug though.
Has anyone else had a similar problem?
Thanks in advance.
It looks like it might be trying to apply your forms.config as a transformation file instead of a target.
What do you have specified in the deployment step's Additional Transforms? Did you accidentally include forms.config itself?
I am trying to import an OSGI blueprint XML file in to another OSGi blueprint XML file.
e.g.:
blueprint1.xml:
<?xml version="1.0" encoding="UTF-8"?>
<blueprint ....>
<bean id="myBean1" class="com.company.Class1"/>
<bean id="myBean2" class="com.company.Class2"/>
</blueprint>
</xml>
blueprint2.xml:
<?xml version="1.0" encoding="UTF-8"?>
<blueprint ....>
<!-- DOES NOT WORK -->
<import resource="blueprint1.xml" />
</blueprint>
The <import> works for spring but not for blueprint.
Does anybody know a way of doing this in OSGi blueprint XML files?
Apparently, Spring like imports are not currently possible in blueprint.
However, if the files are in the same OSGi bundle then they are in the same context and can be used from other blueprint files.
Also, see here: http://fusesource.com/forums/message.jspa?messageID=15091#15091
If you're using Gemini Blueprint (formerly Spring DM) you can simply tell it to load both files, and basically treat them as if they were one big file:
In the absence of the Spring-Context header the extender expects every
".xml" file in the META-INF/spring folder to be a valid Spring
configuration file [...].
It also treats any xml files in /OSGI-INF in the same way.
I was wondering what would be the best practice to deploy a maven packaged WAR file to tomcat.
Using maven release plugin I get a versioned war file for my project
eg: myservice-1.0.0.war
I would like to deploy it to tomcat so that I can access it as follows
eg: http://localhost:8080/myservice
By default tomcat explodes the war file as a directory with a name myservice-1.0.0 under CATALINA_HOME/webapps. But I want to to explode the war as a directory with a name myservice for the reasons mentioned above.
I know I can simply rename myservice-1.0.0.war >> myservice.war and then deploy it in Tomcat.
I wanted to find out what others do?
I would do it by mentioning myservice as artifactId and final name and using maven cargo plugin to deploy to tomcat.
http://cargo.codehaus.org/Maven2+Plugin+Tips
You can package file /META-INF/context.xml with content like this:
<?xml version="1.0"?>
<!DOCTYPE Context>
<Context path="myapp">
</Context>
See documentation at http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
I ran into the same problem. What worked for me was inserting this properties element into the cargo deployable configuration:
<deployable>
<groupId>org.something</groupId>
<artifactId>something-idm-esb</artifactId>
<properties>
<context>something-idm-esb</context>
</properties>
<type>war</type>
</deployable>
Without this properties element, the app would be deployed to localhost:8080/something-idm-esb-0.9.14.2 which is not what the app needs at runtime. With the properties section, the app is deployed to localhost:8080/something-idm-esb/
Instead of renaming the war file you could do this:
Just add following in your tomcat-dir/conf/server.xml in between <Host>..<\Host> tags.
for : myservice-1.0.0.war file
<Context path="/myservice" docBase="/myservice-1.0.0" debug="0" reloadable="true"></Context>
Reference