I'm running the maven repository manager Nexus on Tomcat. When I setup my pom file, my repository URLs all look something like http://myhost/nexus/repo-name. I'd like to get the word "nexus" out of the URL. We're currently transitioning from an older repository manager and now we need to update all of the URLs. However, if we had a generic repository URL like http://myhost/maven-repo/repo-name, then the URL would be independent of the repository manager.
How can I set something like this up on Tomcat? Would I need to setup host name aliases? Or is there an easier way to do this?
Thanks,
Jeff
I would use a frontal Apache server (only httpd, not Tomcat) to do that, configured as a reverse proxy.
Apache url rewriting and reverse proxy are easy to configure. With this Apache frontal proxy, you are independant from Nexus, but also from the Tomcat server.
With the same Apache URL, you can move to Archiva on a Glassfish server (for example) transparently for the projects.
Deploy your application in the root folder of Tomcat.
I hope you don't put repository locations into your pom's? You should use settings.xml file instead.
Related
I have sonatype nexus (configured as npm group of hosted repo and proxy repo) installed behind reverse proxy.
After last update to OSS 3.41.1-01 we have problems installing via npm install. For some reason url of the actual files (.tgz) are served with wrong url (its using internal ip and not selected domain). In actual json returned from repo tarball options has internal url instead of domain (Image of json from the repo).
As of now i can't found any reference to this kind of problem.
I know of only one hack solution with using rewriting url from upstream which I don't want be doing.
The tarball location is set by the incoming host headers. It it not clear how your reverse proxy is being used but you should be able to confirm that the Host header value is being set in the proxy configuration.
Sonatype provide apache and nginx examples for a few different use cases here. https://help.sonatype.com/repomanager3/planning-your-implementation/run-behind-a-reverse-proxy
We are using java based web application. I have deployed application in glass-fish server.
After deployed the application url look like https://www.domain.net/applicationname/home.jsp but i don't want to enter the full url.
I need something like https://www.domain.net it will go to the application home page.
Can please example any one.
The most common way to do this is to use Apache or Nginx as a load balancer or proxy in front of GlassFish. If you want to connect directly to GlassFish, you will need to set the context root of your application to /.
The most "portable" way to do this is in the web.xml, but you can do it at deploy time instead:
https://alexismp.wordpress.com/2007/08/30/glassfish-tip-have-your-application-be-the-root-application/
I am trying to integrate the liferay tomcat with apache web server.I successfully integrate the liferay with web server.
Condition:
Life ray deployed on ip say : 10.10.10.70
Apache web server on ip say: 10.10.10.80
I provided all the requirement virtual host requirement in httpd.conf file..and provided the web.server.host in portal-ext.properties file.
Problem: When i run liferay portal i can open it on ip: 10.10.10.70
but when i click on any page link (let say /home)that is present in my portal it moved the request to
10.10.10.80:8080/home instead of 10.10.10.70:8080/home
I want to know how to handle this condition.
Because i dont have any page resource on web server doc folder only contain static css..
You might be a bit more precise what "all the required virtual host settings" are, e.g. what did you configure?
Note that by explicitly configuring hostnames/IP-addresses, you're explicitly overriding the autodetected settings from the request - no matter how you get to your portal, Liferay will generate URLs based on the explicitly configured hostname/port.
What's the point in having an Apache in front and then trying to reach tomcat through the non-apache IP/Port? Typically you might have static resources, rewrites, caches on Apache, so that you'll get different results when you alternatively access tomcat through both URLs.
If you configure Apache to "properly" handle the requests before tomcat sees them, you'll typically not need to configure Liferay at all, because Apache will make the actual hostname that it's requested under available to Tomcat. I'm typically using mod_jk for this and it beautifully handles all the configuration with almost no need to explicitly configure tomcat/liferay. If you don't like this, keep in mind that you're explicitly configuring Liferay for the virtual host setup - naturally this explicitly configured name is what Liferay uses. It would be weird if the explicit value would not be used, right?
I have a GWT application, which I deploy as a WAR file to a Jetty 8 server.
I want it to be accessible via
http://<myserver>/
instead of
http://<myserver>:8080/MyApp/MyApp.html
I understand I can configure Jetty to run on port 80 instead of 8080 or have an apache instance running on port 80 and forwarding requests to Jetty running on 8080 (don't see a benefit of the latter, though).
but how can I deploy the GWT app to be accessible at the server ROOT?
so far I see I can create myapp.xml in Jetty/contexts folder and put
<Set name="contextPath">/</Set>
there. I can also rename MyApp.html to index.html. but I'm not sure this is the "recommended" approach
I think you pretty much answered your own question:
The application server (e.g. Jetty) is responsible for the context path, so you must set it somehow in the application server. This is different for each server, e.g. in Tomcat one possibility to achieve this is renaming the war file to ROOT.war. (I don't know all the possible ways how to do this in Jetty off-hand.)
Note: The file that is served when going directly to the context URL can be determined in your web.xml, using
<welcome-file-list>
<welcome-file>MyApp.html</welcome-file>
</welcome-file-list>
So you don't have to rename it to index.html.
ok, accepting my own answer:
create myapp.xml in Jetty/contexts folder
thank you, Chris!
I think this was supposed to be a simple task, but I've been unable to accomplish it.
I've set an archiva repository as this:
2 Internal Maven1 repos (old projects)
1 Internal Maven2 repo
7 Remote repos (central, java.net, jboss.org, etc.)
For each internal repo I've created a proxy connection with each remote repo.
I've added a new mirror to my settings.xml file as explained in the archiva documentation:
<mirror>
<id>archiva.default</id>
<url>http://repo.mycompany.com:8080/archiva/repository/internal/</url>
<mirrorOf>*</mirrorOf>
</mirror>
When I try building a simple project with one dependency from some of the remote repositories, no artifacts are downloaded. Why?!?
Thanks for any help.
Archiva doesn't assign repositories any special roles. You make requests to specific managed repository from Maven (so from your settings, internal), and it will serve what is in there, or proxy it from remote repositories that have been connected by a proxy connector. By default, that is just Central - adding a new remote repository has no effect until it is connected to a managed repository by a proxy connector.
What you probably want to do is add a proxy connector on the internal repo to the remote repositories in question. Consider setting the whitelist too so that it is more effecient.
You may also want to set up a repository group that spans all the managed repositories (both maven 1 and maven 2) for use from a single URL.
I had exactly the same problem with Archiva 2, for me the solution was to give the "Global Repository Observer" role to the Guest user.