JBOSS 7.2.2 External Folder Linking - jboss

I have been searching around for this specific problem of mine. We have a folder that is on a shared folder on another server "\\server1\shares\web\images" and I want to link this folder into my web application in Jboss 7.2.2. I'm migrating from Jboss 4.2.2 to Jboss 7.2.2.
Here is my server.xml file from Jboss 4.2.2. You'll notice that the <Context> tag handles this link for me.
<Server>
<Service name="jboss.web">
<!-- ... -->
<Engine name="jboss.web" defaultHost="localhost">
<!-- ... -->
<Host name="myApp" autoDeploy="false" deployOnStartup="false"
deployXML="false" configClass="org.jboss.web.tomcat.security.config.JBossContextConfig">
<!-- ... -->
<Context path="/images" appBase="" docBase="\\server1\shares\web\images"
debug="99" reloadable="true" />
<!-- ... -->
</Host>
</Engine>
</Service>
My research has lead me to use modules, but I cannot figure out how to use the modules properly for this problem. Most examples shows how to provide some link to a folder on the same machine as the Jboss server is on.
So, am I suppose to use modules or is there another way of doing this?

Related

GWT error even on official tutorials: Check that your module inherits 'com.google.gwt.core.Core' either directly or indirectly

I am learning GWT and was trying to run this tutorial by Vogella and also the official GWT tutorial.
Using the Eclipse GWT plugin 3.0 on Windows 10 and JDK 11
I marked the Maven Project checkbox.
When I right-click and Run As
Turning off precompile in incremental mode.
Super Dev Mode starting up
workDir: C:\Users\My\AppData\Local\Temp\gwt-codeserver-8137229043727681777.tmp
2021-04-29 12:03:13.494:INFO::main: Logging initialized #718ms
Loading Java files in de.vogella.gwt.helloworld.De_vogella_gwt_helloworld.
[ERROR] Hint: Check that your module inherits 'com.google.gwt.core.Core' either directly or indirectly (most often by inheriting module 'com.google.gwt.user.User')
I see that it is inheriting User
<?xml version="1.0" encoding="UTF-8"?>
<!--
When updating your version of GWT, you should also update this DTD reference,
so that your app can take advantage of the latest GWT module capabilities.
-->
<!DOCTYPE module PUBLIC "-//Google Inc.//DTD Google Web Toolkit 2.8.1//EN"
"http://www.gwtproject.org/doctype/2.8.1/gwt-module.dtd">
<module rename-to='de_vogella_gwt_helloworld'>
<!-- Inherit the core Web Toolkit stuff. -->
<inherits name='com.google.gwt.user.User'/>
<!-- Inherit the default GWT style sheet. You can change -->
<!-- the theme of your GWT application by uncommenting -->
<!-- any one of the following lines. -->
<inherits name='com.google.gwt.user.theme.clean.Clean'/>
<!-- <inherits name='com.google.gwt.user.theme.standard.Standard'/> -->
<!-- <inherits name='com.google.gwt.user.theme.chrome.Chrome'/> -->
<!-- <inherits name='com.google.gwt.user.theme.dark.Dark'/> -->
<!-- Other module inherits -->
<!-- Specify the app entry point class. -->
<entry-point class='de.vogella.gwt.helloworld.client.De_vogella_gwt_helloworld'/>
<!-- Specify the paths for translatable code -->
<source path='client'/>
<source path='shared'/>
<!-- allow Super Dev Mode -->
<add-linker name="xsiframe"/>
</module>
This SO question was not relevant to my issue.
Almost certainly you are either missing gwt-user.jar from your classpath, or somehow the gwt-user.jar version doesn't match the gwt-dev.jar, which will cause problems. Every module automatically inherits com.google.gwt.core.Core (despite the error message), and as your .gwt.xml shows, you already have User added.
--
Additionally, from your linked SO post, do check the comments - there are some better, more modern tutorials listed.

Mule : How to share the same mule project between a JBoss AS and a CE runtime?

The objective I have is to develop a bus with Mule, to run it into a JBoss.
My IDE is eclipse kepler, I have the Anypoint Studio plugin installed, a JBoss 7.1.1, a 3.5 CE runtime, Maven etc etc.
I took a look a this page : Deploy War into Mule Standalone server but I don't see haw it could help.
Context :
- Jboss is an imposed choice. I know it exists an EE version of the runtime, specially for the HA ability (that I need), but it's not an option for my client.
As it's "easier" to test my flows on the standalone (CE) runtime, I wanted to find a way to develop one Mule project to execute it on a CE runtime during the developing phase, and on a JBoss AS during the integration phase.
To do that, I tried to define :
- a jar maven project which contains all the flow
- a "mule" maven project, with the previous jar as the dependency
- a war maven project which athe previous jar and all the module/transport mule jars as dependencies
When I build the mule zip, my jar is included inside, but when it's executed none of ny flew is registered. So it doesn't work.
When I execute the war on JBoss, everything looks fine for the "first" flow (the input one), but I have a crash when the second one is called using a VM connector (other issue, I'll make another request)
Is there a way to do something working with this approach?
I tried to define 2 pom for the same mule project (one pom which generate a war, and a standalone-pom which generate the mule zip), but this is not very "easy to use" for my team, as the eclipse integration of this kind of project is not very friendly.
The last thing I can try is to keep the mule project pom with a mule packaging, and add a maven assembly to build the jar I could include in my war, but I'd prefer a nicer solution...
Thanks for all of your ideas!
Ah, the test flew I'm trying to integrate.
I have 3 flew :
- The first one stands for the HTTP request (to call my CE runtime)
- The second one stands for the Servlet request (to call my JBoss)
- The third one is called by both my CE runtime and my JBoss input flow, throw the VM connector. I'm thinking replace the VM connector by a Flow Call, as the VM inbound-endpoint is not registered when it's embedded into my war (but it works when executed in a CE runtime...)
main file :
<flow name="muleFlow1" doc:name="muleFlow1">
<http:inbound-endpoint exchange-pattern="request-response"
host="localhost" port="8081" doc:name="HTTP" />
<echo-component doc:name="Echo" />
<vm:outbound-endpoint path="receiver"
exchange-pattern="request-response" responseTimeout="10000" doc:name="VM" />
</flow>
<flow name="muleFlow2" doc:name="muleFlow2">
<servlet:inbound-endpoint path="servlet"
responseTimeout="10000" doc:name="Servlet" />
<echo-component doc:name="Echo" />
<vm:outbound-endpoint path="receiver"
exchange-pattern="request-response" responseTimeout="10000" doc:name="VM" />
</flow>
second file :
<flow name="otroFlow1" doc:name="otroFlow1">
<vm:inbound-endpoint path="receiver"
exchange-pattern="request-response" responseTimeout="10000" doc:name="VM" />
<set-payload value="it works" doc:name="Set Payload" />
<echo-component doc:name="Echo" />
</flow>
Thanks !
I didn't find anything else, so I opted for an assembly descriptor...
<assembly
xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
http://maven.apache.org/xsd/assembly-1.1.2.xsd">
<id>mule</id>
<formats>
<format>zip</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<fileSets>
<fileSet>
<directory>${project.build.directory}/classes</directory>
<outputDirectory>/</outputDirectory>
<includes>
<include>*.xml</include>
</includes>
</fileSet>
<fileSet>
<directory>${project.build.directory}</directory>
<outputDirectory>/</outputDirectory>
<includes>
<include>classes/**/*.class</include>
</includes>
</fileSet>
</fileSets>
<dependencySets>
<dependencySet>
<outputDirectory>/lib</outputDirectory>
<useProjectArtifact>false</useProjectArtifact>
<useTransitiveDependencies>true</useTransitiveDependencies>
<excludes>
<exclude>org.mule:mule-core</exclude>
<exclude>commons-cli:commons-cli</exclude>
<exclude>log4j:log4j</exclude>
<exclude>org.mule.mvel:mule-mvel2</exclude>
<exclude>org.mule.common:mule-common</exclude>
<exclude>org.mule.modules:mule-module-client</exclude>
<exclude>org.mule.modules:mule-module-spring-config</exclude>
<exclude>org.mule.modules:mule-module-annotations</exclude>
<exclude>org.mule.modules:mule-module-xml</exclude>
<exclude>org.mule.modules:mule-module-cxf</exclude>
<exclude>org.mule.modules:mule-module-spring-security</exclude>
<exclude>org.mule.transports:mule-transport-http</exclude>
<exclude>org.mule.transports:mule-transport-ssl</exclude>
<exclude>org.mule.transports:mule-transport-tcp</exclude>
<exclude>commons-codec:commons-codec</exclude>
<exclude>org.mule.modules:mule-module-spring-extras</exclude>
<exclude>org.mule.modules:mule-module-builders</exclude>
<exclude>org.mule.modules:mule-module-management</exclude>
<exclude>org.mule.modules:mule-module-scripting</exclude>
<exclude>org.mule.modules:mule-module-sxc</exclude>
<exclude>org.mule.tests:mule-tests-functional</exclude>
<exclude>org.mule:mule-core</exclude>
<exclude>org.mule.transports:mule-transport-file</exclude>
<exclude>org.mule.transports:mule-transport-jdbc</exclude>
<exclude>org.mule.transports:mule-transport-jms</exclude>
<exclude>org.mule.transports:mule-transport-servlet</exclude>
<exclude>org.mule.transports:mule-transport-vm</exclude>
</excludes>
</dependencySet>
</dependencySets>
</assembly>
My mule project is now a jar, which generate a jar file (for my webapp) and a zip file (for my runtime CE)
One important thing :
To realize the spring imports of each flow, we need to specify when mule is deployed in a web app, but the runtime expects to work. It can be done by creating a maven profile and enabling the resources filtering to determine when add "classpath:"...

failed to run wicket examples on tomcat7

I downloaded wicket examples 1.6.0 and built successfully in netbeans7.2. but got errors when I tried to deploy on tomcat 7:
Cannot deploy the module. The context.xml file seems to be broken. Check whether it is well-formed and valid.
The module has not been deployed.
See the server log for details.
at
org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:210)
at
org.netbeans.modules.maven.j2ee.ExecutionChecker.performDeploy(ExecutionChecker.java:178)
at
org.netbeans.modules.maven.j2ee.ExecutionChecker.executionResult(ExecutionChecker.java:130)
at
org.netbeans.modules.maven.execute.MavenCommandLineExecutor.run(MavenCommandLineExecutor.java:212)
at
org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:153)
heres the contents in context.xml:
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<!-- <Loader className="org.atmosphere.util.AtmosphereClassloader"/> -->
<Loader delegate="true"/>
</Context>
I prefer to run wicket in eclipse as it negates the requirement to mess around with an external tomcat instance.
If you are comfortable with eclipse and maven i would download wicket 1.6 example archetype via maven, import into eclipse and then in the test directory you can run the run.java class to get an internal jetty server host wicket for you.
this should get you started quickly without having to wrestle with tomcat configurations too.
Not really an answer but an alternative route to the same end point
Add parameter path to context tag, same path that app will be served:
<?xml version="1.0" encoding="UTF-8"?>
<Context path="/application-path-name/">
<!-- <Loader className="org.atmosphere.util.AtmosphereClassloader"/> -->
<Loader delegate="true"/>
</Context>
Answer obtained from this question.

JBoss (liferay) no context.xml so where to put JNDI resource

I've got the order to switch from Liferay on tomcat, to Liferay on JBoss.
One issue I'm having is that unlike in tomcat, I can't seem to find a context.xml in liferay-portal-6.0.5\jboss-5.1.0\server\default\conf
Will it work if I just copy the context.xml from my tomcat installation to my jboss installation? (I don't know if JBoss scans that folder).
Or is there an alternative location where I can put my resource?
<Resource name="jdbc/x" auth="Container"
type="javax.sql.DataSource" driverClassName="oracle.jdbc.OracleDriver"
url="y"
username="z" password="A" maxActive="20" maxIdle="10"
maxWait="-1"/>
Add a file named "*- ds.xml" in the deploy directory server with the following contents:
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<local-tx-datasource>
<jndi-name>jdbc/myds</jndi-name>
<connection-url>jdbc:oracle:thin:#127.0.0.1:1521:sid</connection-url>
<user-name></user-name>
<password></password>
<new-connection-sql>SELECT * FROM DUAL</new-connection-sql>
<check-valid-connection-sql>SELECT * FROM DUAL</check-valid-connection-sql>
<driver-class>oracle.jdbc.OracleDriver</driver-class>
</local-tx-datasource>
</datasources>

Java Webstart with Tibco Native Libs

I am trying to deploy an application that uses the native implementation of Tibrv through the TibrvJ library using Java Webstart.
I have packaged up all of the Windows dlls from inside c:\tibco\tibrv\bin into a Jar file and have added these to the nativelib element in the JNLP file.
I was hoping that webstart would take the dll files from thetibco-7.5.1-nativelibs.jar file and allow them to be loaded via System.loadLibrary which is called from Tibrv.open(). However it doesn't seem to want to work properly.
My JNLP file looks like this:
<?xml version="1.0" encoding="utf-8"?><!DOCTYPE jnlp PUBLIC "-//Sun Microsystems, Inc//DTD JNLP Descriptor 6.0//EN" "http://java.sun.com/dtd/JNLP-6.0.dtd">
<jnlp spec="6.0+"
codebase="http://somewhere:8080/my-gui/application"
href="launch.jnlp">
<information>
<title>My GUI</title>
<vendor>Technology</vendor>
<description>Dashboard</description>
<description kind="short">Dashboard</description>
<icon href="icon/Stocks-128x128.png" />
<offline-allowed />
<shortcut online="true">
<desktop />
<menu submenu="Dashboard" />
</shortcut>
</information>
<security>
<all-permissions />
</security>
<update check="always" policy="prompt-update" />
<resources>
<j2se version="1.6+" href="http://java.sun.com/products/autodl/j2se"
java-vm-args="-Xmx120M -ea />
<property name="log4j.configuration" value="live/log4j.xml" />
<property name="swing.aatext" value="true" />
<jar href="tibrvj-7.5.1.jar" />
<jar href="dashboard-gui.jar" main="true" />
</resources>
<resources>
<nativelib href="nativelib/tibco-7.5.1-nativelibs.jar" />
</resources>
<application-desc main-class="com.somewhere.Main">
<argument>classpath:/live/client.xml</argument>
<argument>/live/live.properties</argument>
</application-desc>
</jnlp>
The application launches but as soon as a call is made to open tib then it falls apart with an error along the lines of:
[Root exception is TibrvException[error=22,message=Version mismatch: libtibrv version 7.4 does not match version of tibrvj shared library 7.5]]
TibrvException[error=901,message=Library not found: tibrvj]]
The users have a variety of Tib installations already on their PCs from Tib 7.2 through to 7.5. The Webstart Application only works correctly on a machine with 7.5 installed which matches the Jar file inside the package. So it doesn't appear to do anything with the nativelib jar.
I would like to avoid having to deploy 3 versions of the web start application for the different versions of Tib that the users have installed.
Has anyone else managed to get this combination of TibrvJ and Webstart working?
I've managed to get it working. The trouble is that the call to System.loadLibrary when using Webstart doesn't load in the dependencies of the specified library even if they have been packaged up into a nativelib jar.
See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6191612 for more info.
To get around this problem it is necessary to explicity load all of the dependencies in the correct order. It is also necessary to put each dll library into its own jar file.
So to use native TibrvJ you need to make the following calls before any calls to Tibrv.Open.
System.loadLibrary("msvcr71");
System.loadLibrary("tibrv");
System.loadLibrary("tibrvcm");
System.loadLibrary("tibrvft");
System.loadLibrary("tibrvcmq");
System.loadLibrary("tibrvj");
Happy Days!
I think you have encountered a problem with Webstart.
Some years ago, I had a Webstart application using Java 3D that didn't work on Macs. Eventually I found that all Macs some with an old version of Java 3D installed, and that already installed version was used over the newer version that I had included in the in my JNLP file. Your problem sounds almost exactly like this, so it could very well be the same problem.