[Installation, Configuration & DEPLOYMENT] - Re: cannot load classes located in WEB-INF/lib
by jbosshog98
I should add that I tried the code below with my JARs in WEB-INF/lib
and am receiving the error below. With the JARs in the EAR file I
don't have to do the updateJar, I can just use the code as is without
the two tags and it works. I'm not sure if this is a
dependency thing or what, I'm a little baffled. I just need to get
ahold of the Spring application context from within Railo, which I can
do with the JAR in the EAR/lib but not this way.
<cfadmin action="updateJar"
| type="web"
| password="testtest"
| jar="/work/jboss/jboss-4.2.3.GA/server/default/deploy/
| railo.ear/railo1.war/WEB-INF/lib/spring.jar">
|
| <cfset var utils = createObject("java",
| "org.springframework.web.context.support.WebApplicationContextUtils",
| "/work/jboss/jboss-4.2.3.GA/server/default/deploy/railo.ear/railo1.war/
| WEB-INF/lib/spring.jar") />
|
| <cfset var context = getPageContext().getServletContext() />
|
| <cfset variables.applicationContext = utils.getWebApplicationContext
| (context)>
|
| <cfadmin action="removeJar"
| type="web"
| password="testtest"
| jar="/work/jboss/jboss-4.2.3.GA/server/default/deploy/
| railo.ear/railo1.war/WEB-INF/lib/spring-web-2.0.4.jar">
When I do this I get the following error:
Root context attribute is not of type WebApplicationContext:
org.springframework.web.context.support.XmlWebApplicationContext@1ff48d8:
display name [Root WebApplicationContext]; startup date [Thu Jun 11
03:06:42 PDT 2009]; root of context hierarchy
at
org.springframework.web.context.support.WebApplicationContextUtils.getWebApplicationContext
(WebApplicationContextUtils.java:66):66
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method):-2
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source):-1
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source):-1
at java.lang.reflect.Method.invoke(Unknown Source):-1
at railo.runtime.reflection.pairs.MethodInstance.invoke
(MethodInstance.java:37):37
at railo.runtime.java.JavaObject.call(JavaObject.java:241):241
at railo.runtime.java.JavaObject.call(JavaObject.java:260):260
at railo.runtime.util.VariableUtilImpl.callFunctionWithoutNamedValues
(VariableUtilImpl.java:617):617
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236957#4236957
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236957
16 years, 10 months
[JBossWS] - About WS client security (obfuscation required ?)
by agomese
Hello all,
I'm developing a client (Swing-based) software which allows to send/receive files from a JBoss AS central repository, using the JBossWS web service implementation. The JBossWS version we use is the one that is bundled within the JBoss AS version, in order to ensure compatibility.
To allow this communication, our swing-based client software is going to be released with the required JBossWS client jars (taken from the JBossAS distribution). For now, we plan to put those JBossWS jars in a "lib" folder, placed directly under the client software's root folder. The rest of the client's code (the "proprietary" part) will be obfuscated.
My question is : in your opinion, should the JBossWS client jars be protected through the same obfuscation mecanism, in order to ensure maximum security ? And BTW, does JBoss authorize such mecanism for the jars/sources they deliver ?
I tried to found related questions on this forum and on the web, but found none. Actually, we are affraid one could override the endpoint's adress by switching the original JBossWS client jars placed in the "lib" folder, in order to obtain the sent/received files from the remote AS.
We are already securing the communication through HTTPS transport, signature and encryption. However, the client keystore providing the security configuration is not going to be part of the obfuscation process, as it has to be specific per customer (please note that the JBoss AS install is specific per customer too, and so each client specific keystore is associated to a server specific keystore). We believe one could change this client keystore, create a fake endpoint with a new server keystore, and redirect traffic to this fake endpoint by changing the JBossWS client jars. But maybe are we being a bit paranoiac ?
Our configuration :
- JDK 5
- JBoss AS 4.2.3 with JBossWS native 3.0.1
Any opinion about this point would be appreciated.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236956#4236956
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236956
16 years, 10 months