I'm trying to implement a simple login using Spring Security (I'm a newbie in Spring Security). I've started with Spring Security reference that contains a simple "Hello world" example (link). I've prepared a web project in Eclipse (with EAR project), file structure looks like this:
SecurityConfig and SecurityWebApplicationInitializer classes are identical to those in a link above ("Hello world" example). I've also added Log4j 2 configuration file and home page (login.xhtml) that (for now) just prints "test". Later it will be used as a custom login page.
web.xml contains only a welcome-file element:
<?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"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
id="WebApp_ID" version="3.0">
<display-name>SpringSecurity</display-name>
<welcome-file-list>
<welcome-file>pages/login.xhtml</welcome-file>
</welcome-file-list>
</web-app>
EAR's deployment assembly looks like this:
When I deploy my EAR on a JBoss AS 7.1.1, there's no error, but when I access http://localhost:8080/SpringSecurity, my home page is displayed normally.
I'm guessing that the configuration above should generate a default login page. When I access my home page, that login page should appear, right? It looks like that Spring Security is not even loaded and there's no protection when accesing my home page.
I don't really understand why is this simple example not working. Any help?
I do not have JBoss on my machine currently. But I was able to deploy this example on tomcat.
The issue certainly is that the war classloader is not able to see the spring jars at runtime.
There can be two possible solutions to resolve this.
If the spring jars are only required by war module (not by any other module in the ear), then you can shift these spring jars from ear's lib directory to war's WEB-INF/lib directory.
If the spring jars are also required by the other modules than you can to explicitly set the Class-Path entry in the MANIFEST.MF file of the war and the other modules that require these jars in a portable way.
e.g.
Manifest-Version: 1.0
Class-Path: lib/spring-beans-4.3.9.RELEASE.jar lib/spring-context-4.3.9.RELEASE.jar
Add all the required jars in this way separated by sapce (' ').
Note:- I used following jars to make this example run.
spring-aop-5.0.2.RELEASE.jar
spring-beans-5.0.2.RELEASE.jar
spring-context-5.0.2.RELEASE.jar
spring-core-5.0.2.RELEASE.jar
spring-expression-5.0.2.RELEASE.jar
spring-jcl-5.0.2.RELEASE.jar
spring-security-config-5.0.0.RELEASE.jar
spring-security-core-5.0.0.RELEASE.jar
spring-security-crypto-5.0.0.RELEASE.jar
spring-security-web-5.0.0.RELEASE.jar
spring-web-5.0.2.RELEASE.jar
And with this version of spring and spring-security you may have to make a small change in your code.
User.withDefaultPasswordEncoder().username("user").password("user").roles("USER").build();
or
User.withUsername("user").password("{noop}user").roles("USER").build();
Refer - Spring Boot PasswordEncoder Error for more details about the code change required.
Related
I have a weblogic server with a cluster of two SOA servers.
I am deploying a servlet to this server with a SOAP servlet created with the JDeveloper wizard (Create Java Web Service from WSDL -> Java EE 1.5, with support for JAX-WS Annotations)
It is deployed as a standalone application.
During the development of the application I have changed the WSDL in various ways including changing the port name.
I have gone into the weblogic interface, deleted the previous instalisation and re-deployed through JDeveloper. I get the following error message:
[08:44:59 PM] weblogic.management.DeploymentException: Error encountered during prepare phase of deploying WebService module 'RJMTestBannerAdapter.war'. Two port in the callBannerService(WebserviceDescriptionBean) has the same name {http://ic.ac.uk/AIAMetaData/AIAComponents/ApplicationObjectLibrary/Banner/V1/APIJavaAdapter/BannerAPIJavaAdapterWsdl}callBanner.
It is complaining that there is two ports in the application with the same name. But there isn't.
I have inspected the .war file that JDeveloper produces
The WEB-INF/web.xml has a single entry for the service
The WEB-INF/weblogic.xml is also correct and just specifies the context-root.
I have determined that somewhere in the weblogic servers there must be something with the end point that is not being cleared away when I delete the application.
I have checked the weblogic console user interface, gone through the list of web applications and services and confirmed it is not there.
Does the weblogic server have a deployment plan file or something simular it is picking up while deploying? If so where would this deployment plan be?
I don't think it is important but here is my web.xml:
<?xml version = '1.0' encoding = 'UTF-8'?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5"
xmlns="http://java.sun.com/xml/ns/javaee">
<servlet>
<servlet-name>callBanner</servlet-name>
<servlet-class>ic.ac.uk.ic.rjmtest.banner.adapter.gen.main.Main_ptImpl12</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>callBanner</servlet-name>
<url-pattern>/callBanner</url-pattern>
</servlet-mapping>
</web-app>
Also this is the weblogic.xml that appears in the war file. (It is not in my project but JDeveloper must generate it)
<?xml version = '1.0' encoding = 'UTF-8'?>
<weblogic-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-web-app http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd" xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app">
<context-root>RJMTestBannerAdapter</context-root>
</weblogic-web-app>
I have also inspected the WSDL and there is only a single port.
I finally found the answer.
When I used JDeveloper to regenerate the classes for the service I must have changed the name somehow. This resulted in new java being built.
As I didn't delete the classes or deploy directory the old ones were still there in my war file. So I was trying to deploy two even though my .java files didn't reflect this.
Deleting the classes and deploy directories then recompiling resolved the issue.
This post might be useful for anyone else who hits this error!
I am migrating my RESTful web application from GlassFish4.1 to WildFly9.0 for the first time.
Initially, I suffered deployment issues due Jersey dependencies. To overcome that problem, I simply replaced said project dependencies with RESTEasy equivalents inside of the pom.xml file. In doing so, my application became deployable -- and according to (WildFly_base)/standalone/log, and the applications themselves -- are working as expected.
Additionally, I added a jboss-web.xml configuration file to my WEB-INF folder:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss-web PUBLIC "http://www.jboss.org/j2ee/dtd" "http://www.jboss.org/j2ee/dtd/jboss-web_5_0.dtd">
<jboss-web>
<context-root>myprojectstart</context-root>
</jboss-web>
The hello-world page can be reached # http://ipaddress:8080/myprojectstart.
... however, I cannot view my web services # http://ipaddress:8080/myprojectstart/getData, just like I could when using GlassFish-4.1.
So; what am I missing?
Note: I use #annotations like:
#ApplicationPath("/*")
#Path("/getData")
No seperate .xml business here
I don't think RestEasy supports * in ApplicationPath. If you remove that it should work fine.
In my GWT project running in glassfishv3, everything is worked properly, but when I change my servlet url patterns mapping from web.xml to #WebServlet annotation inside servlet classes, GWT rpc cand find the servlet!
note that, other usual servlets work with this annotation(WebServlet) and just GWT RPC doesnt work.
what is the reason?
RGDS
Did you set the version number of web-app in the web.xml to the correct servlet version, because this feature is available only since 3.0:
<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://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
Ok, I finally got this working but with some caveats. I was able to get it working in Tomcat within Intellij and as a deployed WAR to a Tomcat 7 container.
I was NOT able to get it working in dev-mode without using -noserver. I believe this is because the built-in Jetty server is not JSR315 compatible but have no evidence of this as I've not tried to determine what version of jetty is in the gwt-dev jar.
The trick is you need to fully qualify the path in WebServlet. So if your remote service interface has the relative path of "bar" and your module name (rename-to in gwt.xml) is "foo" then the path you need to set the path of "/foo/bar" in WebServlet and it will work.
I have a WAR file with the following structure:
The JSF managed bean BusinessObjectTypeListController is located in commons-web-1.0.jar in /WEB-INF/lib and referenced in BusinessObjectTypeListView.xhtml. When I run my web application and I call that view, I get the following error:
javax.servlet.ServletException: /view/common/businessObjectTypeListView.xhtml #34,94 listener="#{businessObjectTypeListController.selectData}": Target Unreachable, identifier 'businessObjectTypeListController' resolved to null
Why isn't the controller class found? It should be in the classpath, is it?
You need to have a JSF 2.0 compliant /META-INF/faces-config.xml file in the commons-web-1.0.jar file in order to get JSF to scan the JAR file for classes with JSF annotations like #ManagedBean and auto-register them.
<?xml version="1.0" encoding="UTF-8"?>
<faces-config
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://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd"
version="2.0">
</faces-config>
JSF does namely not scan every class of every single JAR file in the classpath, that would have been too expensive. Only JARs with the above /META-INF/faces-config.xml file will be scanned.
You should also ensure that you do not have the metadata-complete="true" attribute in the <faces-config> declaration of webapp's own /WEB-INF/faces-config.xml file, otherwise JSF will assume that this faces config is complete and therefore won't auto-scan JAR files for annotations.
If none of those conditions are (or can be) met, then you need to manually register the bean as <managed-bean> in webapp's own /WEB-INF/faces-config.xml instead of relying on annotations.
See also chapter 11.4.2 of JSF 2.0 specification (emphasis mine).
11.4.2 Application Startup Behavior
...
This algorithm provides considerable flexibility for developers that are assembling the components of a JSF-based web
application. For example, an application might include one or more custom UIComponent implementations, along with
associated Renderers, so it can declare them in an application resource named “/WEB-INF/faces-config.xml”
with no need to programmatically register them with Application instance. In addition, the application might choose
to include a component library (packaged as a JAR file) that includes a “META-INF/faces-config.xml” resource.
The existence of this resource causes components, renderers, and other JSF implementation classes that are stored in this
library JAR file to be automatically registered, with no action required by the application.
I have same problem with CDI beans in my case.
I have common.jar project where i placed the CDI beans. (without beans.xml)
and
I have webapp.war that contains common.jar in it`s lib and beans.xml.
when i call a cdi bean from jsf, i get it is not reachable exception:/
project structure is created using maven :
- maven-archetype-quickstart for common.jar
- maven-archetype-webapp for webapp.war
I am using eclipse/juno en deploy to Glassfish 3.1.x.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Resolved:
For EJB and JAR packaging you should place the beans.xml in src/main/resources/META-INF/.
For WAR packaging you should place the beans.xml in src/main/webapp/WEB-INF/.
Remember that only .java files should be put in the src/main/java and src/test/java directories. Resources like .xml files should be in src/main/resources.
from topic:
CDI: beans.xml, where do I put you?
In my opinion the class BusinessObjectTypeListController is founded properly but does not instantiated.
How you create the instance of class on a view? If you use a BeanFactory review the config xml files
I need to create a startup class in Websphere. This class is present in abc.jar. And also abc.jar requires log4j.jar at startup of server.
For above scenario, i have created the startup class with abc.jar in classpath in websphere console and I kept log4j.jar in ext folder of WAS. This works for me.
But problem is that the other profiles share same ext folder of WAS and does not able to start up due to Log4j.jar.
If I keep Log4j.jar in other place and keep that location in classpath. Startup class will not fails.Please help me.
If your application uses EJBs, then you can use a peculiar feature of WAS with the ibm-ejb-jar-ext.xml descriptor, which includes a start-at-app-start element:
<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar-ext
xmlns="http://websphere.ibm.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-ext_1_1.xsd"
version="1.1">
<session name="TestBean">
<start-at-app-start value="true"/>
</session>
</ejb-jar-ext>
I'm not very familiar with WebSphere and maybe I do not fully understand your problem - but how about deploying a webapp with a startup servlet defined in web.xml?
Here's what I mean:
create a abc.war with abc.jar and log4j.jar copied to abc.war/WEB-INF/lib
define your startup class in abc.war/WEB-INF/web.xml as follows:
<web-app id="WebApp">
<display-name>abc.war</display-name>
<servlet>
<servlet-name>ABCStartupServlet</servlet-name>
<display-name>ABCStartupServlet</display-name>
<servlet-class>abc.ABCStartupServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
...
That way you have log4j.jar and abc.jar together in one place, you can use the WebSphere classloader settings if another log4j version causes problems and your class is called during the startup of the server.