Missing Jars when switching from Glassfish to Apache Tomcat Webserver on Glassfish using Eclipse - eclipse

I am developing an Angularjs frontend which talks to a REST backend. I am developing using Eclipse and was using a Glassfish webserver.
I had the need to create htaccess redirect for Angular routes (see here: htaccess redirect for Angular routes) but to do this I need to change my webserver from Glassfish to Apache Tomcat since the htaccess stuff doesn't exist for the Glasshfish webserver.
When I created the new apache tomcat server v8.0, upon starting the log gave multiple errors for missing JAR files. These JARs were:
avalon-framework-4.1.3.jar
batik-css-1.6-1.jar
batik-ext-1.6-1.jar
batik-gui-util-1.6-1.jar
batik-util-1.6-1.jar
commons-configuration-1.5.jar
logkit-1.0.1.jar
nekohtml-1.9.11.jar
xercesImpl-2.8.1.jar
xml-apis-1.3.03.jar
Additionally, it wants the following JAR which doesn't not seem to be around anymore:
antisamy-1.3-SNAPSHOT.jar
A lot of the JARS mentioned above are old versions of the JARS. What can I do about the missing JAR that is not around anymore?
Also, how do I know if these JARs are the most current versions I should be using? (I added all of them I could find manually in the tomcat /lib directory)
Thanks in advance - I'm quite new to all this stuff so go easy on me:)
EDIT 1: I've included the non-snapshot version of the JAR as per unwichtich's answer. However this doesn't fix the error. Why would the Apache Tomcat v8.0 require such old JAR files to work, especially a snapshot jar? Where would one look to see where these JAR's are configured? Is it possible to know which newer versions of the JARs are compatible with my setup?

antisamy-1.3-SNAPSHOT.jar
First, you should NOT depend on SNAPSHOT dependencies, they can change the programs behaviour in the same version....
Second, SNAPSHOT versions might be seen as beta steps to the final release, so you can not expect that these SNAPSHOT versions are still available online when the final version was released.
A quick googling didn't suggest any old link to antisamy-1.3-SNAPSHOT.jar, but you may try this one: https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/owaspantisamy/antisamy-bin.1.3.jar. This should be the final of 1.3 and if you are lucky it contains the same API as the SNAPSHOT version you used before. If not, you may have to update your code so that it works with the final.
There seem to be newer versions of the lib, you also may want to try them.

Related

JSTL doesn't work when running from within eclipse

I'm trying to add JSTL support to an spring boot application, but I'm getting this error message when running it from within eclipse:
The absolute uri: [http://java.sun.com/jsp/jstl/core] cannot be resolved in either web.xml or the jar files deployed with this application
If i generare an executable war and run it, JSTL works correclty.
I've tried almost all the solutions described in the other questions but none of it seems to focus on running it from eclipse.
I've created this tiny repo to demostrate it:
https://github.com/rroman-encora/brokenjstl
This is my setup:
Spring Boot 1.5.7
Eclipse Version: 2021-03 (4.19.0)
JDK 11.0.11
The project runs with source and target java 1.8
Thankyou
If another poor soul finds him self in this situation, may this be the answer:
Just copy all the *.tld files from the jstl jar inside your WEB-INF directory and this should work.
Obviously there's a "proper" way to do this, maybe it's just a setting on spring boot, maybe you need to configure the embedded tomcat/jasper TLD Scanner, but today I'm so tired to keep looking for the perfect aswer.
BTW this also keeps working if you deploy your application as an excecutable war.

Eclipse: Can not find the tag library descriptor for "http://java.sun.com/jsf/core" using JBoss

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.

Configuring Mojarra 2.1.X on Eclipse Indigo

The User Library download from Properties/Project Facets/Java Server Faces only lists Apache and Mojarra 2.0.X options. And setting up a user library manually, if I add javax.faces-2.1.11.jar, it doesn't error, puts the jar in the entry, then says \jarfiles\jaf (missing). So I see no way to use Mojarra 2.1.X.
I am unable to understand completely that what are you saying? But as much as I can I understood that "you want you use Mojarra 2.1.X" in your project. Now here is the thing You should mention the server that you are using.
If you are using glassfish 3.1.x then you have to replace your javax.faces.jar present in /glassfish/modules folder with javax.faces-2.1.11.jar as the glassfish built in jar javax.faces.jar enforce glassfish to use Mojarra 2.1.6.Now if it is Tomcat then it is up to you that you have to add all jsf compulsory jars in your lib folder :) One last thing that if you are using anyother server which has built in support for JSF and you are unable to find How to replace your jar from that server or you have issue with admin access over that server then you can also upgrade JSF by placing the newer javax.faces.jar file in webapp's own /WEB-INF/lib folder and editing the /WEB-INF/glassfish-web.xml file to add the following two new entries: <class-loader delegate="false" /><property name="useBundledJsf" value="true" />.Keep in mind that you are only enforce Web servers to use your desired jars not the application servers because many applications servers are giving built in support for JSF. So Configuring Mojarra 2.1.X on Eclipse Indigo is somehow wrong to ask.You have to ask that how should I use Mojarra 2.1.x with my XXX server because eclipse is only IDE and these things are SOMEHOW managed by IDE but only in case of Webservers.Thanks :)

Cannot find OpenPortal Portlet Container 2.x when creating a new server runtime environment in eclipse

I just started learning portlet and got stuck in the first place. I have installed JavaEE 6 SDK, Eclipse Helios and GlassFish Server 3.0.1. I also successfully configured OpenPortal Portlet Container (OPC) for GlassFish by running command:
java -jar portlet-container-configurator.jar
The problem come up when I wanted to create a new server runtime environment of OPC, there was no "OpenPortal Portlet Container 2.x" node like the tutorial said. I googled and found that I needed to install Eclipse Portal Pack but the link was dead.
Any suggestion, please?
Best Regard.
If you want to develop portlets, I strongly recommend downloading Apache Pluto instead of using the open portlet container; you can download a version of Tomcat bundled with Pluto from their site: http://portals.apache.org/pluto
Actually, Pluto has a few quirks that you need to get past (for example, it wants you to run an 'assembly' step to add some entries to your web.xml) but once you do it is probably the best way. You could also try Liferay or JBoss' GateIn for development, but if you are ultimately targeting a vendor supplied platform like WebSphere, you might find that these actually have features that aren't as portable, whereas Pluto is really just a simple implementation of the portlet spec.
I have found the .jar file on Internet. Thanks for watching.

Unable to publish web app: SpringSource Tool Suite problem?

I have an existing, fully functional Spring web application based on Spring 2.5.6 - developed using SpringSource Tool Suite 2.1.0.SR1.
Because I'd like to use REST I decided to upgrade to Spring 3.0.0.M4. After editing the dependencies in pom.xml and changing my code to reflect the API changes in Spring 3.0 I tried to publish my web app to a local server (SpringSource tc - a Tomcat derivate).
The result is an almost empty web app folder and therefore a non-functional app. The app's folder only contains WEB-INF/lib with all libraries required by the Maven dependencies.
After realising that something's broken, I created a new Spring MVC project (based on the default 2.5.6) and published it to the same server. No problems. I tried to adapt my project's files (.settings/*, .project, .classpath, .springBeans), but this didn't change anything.
I'm pretty lost right now. My guess is that STS doesn't handle 3.0 apps correctly. Any suggestions?
PS: I don't want to revert to 2.5 if it's not absolutely necessary. I don't need STS and tc so I don't have a problem using other tools, but it worked fine so far.
I run into this all the time using Eclipse Galileo and m2eclipse 0.9.8 and Tomcat with WTP. I think it is m2eclipse that is the culprit. The problem seems worse after switching from Ganymede. The work around is to run mvn to create the war and then copy the war contents from "target" to WTP's "wtpwebapps" directory. You can conveniently find this horribly long path by double clicking the server in the Servers view, and choosing "Open Launch Configuration" from there click on Arguments(?) tab I think and copy the catalina.home java property that is defined as an argument there.
The problem vanished with newer versions of STS. Additionally my development environment changed a bit since I posted this question, so I can't really tell what caused the problem.
For me, it looked like a weird hiccup inside STS.
Spring Tool Suite 2.1.0 claims partial support for Spring 3.0, though not for the REST features. According to the release, future releases will add full support. From the release statement:
Features
Support for milestones of Spring 3.0 including XML editing and validation, support for #Configuration and #Bean annotations
Future
Complete Spring 3.0 support including tools for developing RESTful web applications
Try deploying your app to embedded jetty. 'mvn jetty:run' with help you confirm if that there's nothing wrong with your build (that all the right manifests and deps are in place)