I have a JBoss Seam project that a coworker created about a year ago. I'm taking over it now and it needs some work done. So I'm trying to setup the project in Eclipse Indigo. Here is the list of things I have installed so far:
JBoss 4.2.2 GA
JBoss Seam 2.2.0 GA
Glassfish v2.1
JBoss Seam Tools Plugin for Eclipse Indigo
For some reason I am not able to build the project to get an ear for JBoss. The errors I have are one in glassfish-builld.xml which says "Target clean does not exist in this project." And then I have errors in a bunch of generic.jsp file (I have no idea what their purpose is). The error for those is that a library for JBoss Seam called org.jboss.seam.wiki.util.WikiUtil cannot be found.
Can someone point me in the right direction to get this setup and running on JBoss?
Also org.jboss.seam.wiki.util.WikiUtil is a class that is a part of... Seam example project that is added to JBoss Seam distribution in examples/wiki directory. So if you really need it you will be able to find it there. But honestly I don't see any reason to put any dependency to Seam examples in project. Consider just deleting / commening out the code that refers to this class becasue it is probably some quick and dirty test code.
Do you want to run it on Glassfish or Jboss?
Did you import an entire eclipse project or create a new one?
I would first check the referenced libraries to see if there's anything missing(Libraries under Java Build Path for Helios, not sure if that differs from Indigo). Add a -verbose tag to the build and check out the output.
Related
I was trying to start learning about Apache Wicket (as it looked like an easy to use UI for Java) and as I like to work with Eclipse and Maven. I also like to work with Tomcat, however, Wicket seems to prefer Jetty at least in its tutorials. I do not know nothing about Jetty, however should not take ages to learn.
I tried the Wicket Quick Start and successfully imported the generated Maven project to Eclipse workspace.
But errors appear: e.g.
import org.eclipse.jetty.server.HttpConfiguration;
It seems Eclipse cannot find the jetty server classes. How to add these to the Eclipse project?
Does the creater of the Wicket Quick Start assumed that Jetty is already installed on the machine?
I installed it. However: what is the recommended way to make what jar file available to a maven project to have jetty server classes available? I would assume via the pom.xml but I doubt that is the case here - the given pom.xml would contain it.
Or is there some special plugin for Eclipse (Photon)?Run-Jetty-Run?. I wasn't brave enough to try that.
I would love to get the Wicket Quick Start running.
I also tried Eclipse + Tomcat + Apache Wicket Maven Setup with Hello World Example but it seems that it is outdated. I was not able to install qwickie to Eclipse as described.
I am using Eclipse Proton with Java 10.0.2 on Debian Stretch.
If you are using https://wicket.apache.org/start/quickstart.html then you can start the application these ways:
mvn jetty:run - this will use jetty-maven-plugin
Open in Eclipse src/test/java/com/example/Start.java and run it as a normal Java class with a main(String[]) method. This will use Jetty Maven dependencies to start an embedded Jetty server.
Wicket's Quickstart prefers Jetty because Jetty developers made it easy to use it in non production way, i.e. in development mode, for faster dev cycles. No need to build a .war file and deploy it.
On the other side Tomcat devs (disclaimer: I am a member of both Wicket and Tomcat teams) never spent time in this direction. Tomcat's Maven plugin has been abandoned long time ago. The best integration for starting embedded Tomcat is provided by Spring Boot project (I recommend it if you use Spring!).
So, just remove the Jetty related dependencies and plugin in pom.xml and the Start.java in src/test/java/.... Then you can continue developing with Eclipse and Tomcat the way you like to do it.
I'm attempting to upgrade our environment to Eclipse Luna w/ JBoss Tools from our current Indigo instance. Most things are sorted well enough, but I'm running into a wall when deploying our application to a JBoss server within Eclipse.
As far as I can see, the lib/ directory of the .ear file generated contains none of the transitive dependencies from maven that we would normally expect to see, and as a result the application does not deploy or run correctly on the server. For clarity, we use the 'use workspace metadata' deployment option on the JBoss server within Eclipse.
By contrast, if I right click on the relevant project within Eclipse and say Export... .ear file, the resulting .ear contains all the .jars that I'd expect inside the lib/ folder (there's over 50 of these things, so it's pretty easy to spot the difference). Subsequently dropping the .ear into the deploy directory of JBoss and starting a server manually has the application working fine.
Has anyone ever encountered this sort of issue within JBoss Tools / Luna, and if so what steps were taken to try and remediate it?
Cheers for any help.
Dave.
EDIT: For what it's worth, this is a JBoss Enterprise Application Platform 5.x server instance, and we're using JBoss EAP 5.2
I know this question was asked a lot of times, since I searched for hours for a solution, but it was never answered (or at least not for my situation).
I am using Wildfly 8.0 (ex JBoss), so I understand that I do not need to add jstl jars nor JSF jars since the implementation is already shipped with JBoss.
Now even when telling eclipse to use the Wildfly runtime libraries, I get the above error. I checked and the jboss-jstl-api_1.2_spec-1.0.4.Final.jar is part of the library
How can I get through this? I tried putting downloading jstl jars (from https://jstl.java.net/) and putting them in the lib directory but it is not working.
Copying the jars into "lib" works perfectly when I use Tomcat which doesn't have its jstl implementation. But not with Wildfly (maybe because eclipse ignores the jars I put in the lib directory since Wildfly has its own jars? But then why do I get the error in the first place? I am confused).
Thanks to anyone who could help me with this.
Edit: I forgot to precise that even with these errors on all my JSPs, the project builds and works perfectly on the server.
These errors are eclipse specific, it does not recognize the taglibs and displays annoying error messages at taglib declarations and warnings when using these (unknown to eclipse) tags. Plus, I can't use code completion.
Edit: I bypassed the problem, for the moment, by adding standalone myfaces and jstl libraries to the build path. I would like though that eclipse uses the jars available on server side. (For JPA for example I did not need to add the hibernate library to the build path, I simply told eclipse that the JPA implementation si available on server runtime and it worked fine with code completion and everything).
Alright, to not have to add any additional libraries (that are not needed by the server) here's what I had to do in addition to adding the Wildfly runtime library to the project:
Go to Project/Properties/Project Facets/Java Server Faces and chose Library Provided by Target Runtime in the library type (instead of a User Library).
I'm truly disappointed JSF support in eclipse. I'm encountering such caveats all the time.
I'm using JBoss 7.1.1 and even adding JBoss as the Target Runtime of the project didn't help.
The only solution that worked for me, was to define new JSF library inside Eclipse: Window Preferences -> Java -> Build Path -> User Libraries -> click New (pointing to the jsf-impl.jar and jsf-api.jar). And then adding such library to the build path of the project.
It solved all annoying eclipse errors can not find tag library. So it is pretty similar to the #Riccatti first solution.
Btw: answer which I found on the eclipse forum says that this error is usually caused by not existing JSF tag libraries (that are present in jsf-impl.jar) on the classpath.
I am trying to create a new Portlet project (basically a portlet for Liferay) in Eclipse (Helios with Liferay SDK installed). I use JBoss AS 6.10.final and Liferay 6.05.
The problem is that everytime I try to create new portlet, it asks me for Runtime Enviroment. I want this enviroment to be JBoss AS, but Eclipse only suggests different Tomcat distributions. I dont have Tomcat bundle installed and I am not going to since it will run on JBoss AS.
Liferay is already installed on JBoss and running (when I start the JBoss AS, I can access the liferay portal page - it has all jars and wars on correct places in AS).
I havent found any tutorial how to make this work. Could someone perhaps provide some step by step guide or direct me to any existing one? Thank you!
PS: I hope that my question is not too confusing, if so, I will try to edit it and make myself clearer...
I have finally figured it out:
I changed the build.username.properties file
app.server.portal.dir=c:\\Programs\\jboss-6.1.0.Final-ESB-4.12\\server\\default\\deploy\\liferay-portal-6.0.5.war
app.server.lib.global.dir=c:\\Programs\\jboss-6.1.0.Final-ESB-4.12\\common\\lib
app.server.deploy.dir=c:\\Programs\\jboss-6.1.0.Final-ESB-4.12\\server\\default\\deploy
app.server.type=jboss
app.server.dir=c:\\Programs\\jboss-6.1.0.Final-ESB-4.12
so it points to the directory with liferay war files. Then I had to check in Eclipse that I do not want this file to be overwritten again and it works just fine. I can deploy all projects to JBoss using Liferay SDK!
I have an EAR installed in Websphere 6.1. Development is done in Eclipse, but using a simple Java project and updating the *.java and *.class files directly to the server. I want to start using JPA, but the #Stateless annotation gives the error "cannot be resolved to a type". What am I missing?
Thank you for your time,
Iulia
You need either to be on WebSphere 7.0, or to have installed the EJB3 Feature pack for WebSphere 6.1. You pattern of use of EAR files and plain java projects sounds a little diferent from what I've done. Suggest you start by following Roland Barcia's tutorial, et that going before you experiment with other patterns.
This tutorial may be helpful, it relates to WebSphere 6.1 + feature pack.