I am using Hawtio for an internal web application. It talks to my RESTful Tomcat server in the back-end. But currently Hawtio uses Bootstrap2.3.2 version which is no longer supported by Bootstrap foundation.
Is there any way to change Hawtio settings or reconfigure it to use the latest bootstrap version.
This question was asked on the hawtio issue tracker and answered by Stan Lewis: https://github.com/hawtio/hawtio/issues/2060
yeah, in hawtio v2 we're running against an up to date Bootstrap and have
added Patternfly.
To be honest, updating Bootstrap was non-trivial, requiring changes in
every HTML partial, I wouldn't want to do it for v1.
Related
We have recently upgraded Camel version in our application from 2.20.2 to 3.11.2. Hawtio web console used to show some Camel related details with Camel 2.20.2 which are missing after the upgrade to 3.11.2. After doing some analysis, I found that Hawtio is trying to access some MBeans which Camel used to expose before, but not now after the upgrade.
MBean not available
I just want to check if Hawtio is compatible with Camel 3.x or not, or is there anything else that I'm missing.
Currently we are using:
Camel 3.11.2 with Spring DSL
Hawtio 2.13.0
You are probably missing one dependency.
Here is the full list of mines - ok probably too much as components are included in this list, but you will also find some basic one (like "camel-base-engine-3.9.0.jar").
camel-api-3.9.0.jar
camel-base-3.9.0.jar
camel-base-engine-3.9.0.jar
camel-bean-3.9.0.jar
camel-bindy-3.9.0.jar
camel-catalog-3.9.0.jar
camel-cdi-3.9.0.jar
camel-core-3.9.0.jar
camel-core-catalog-3.9.0.jar
camel-core-engine-3.9.0.jar
camel-core-languages-3.9.0.jar
camel-core-model-3.9.0.jar
camel-core-processor-3.9.0.jar
camel-core-reifier-3.9.0.jar
camel-core-xml-3.9.0.jar
camel-csv-3.9.0.jar
camel-direct-3.9.0.jar
camel-directvm-3.9.0.jar
camel-file-3.9.0.jar
camel-ftp-3.9.0.jar
camel-health-3.9.0.jar
camel-http-3.9.0.jar
camel-http-base-3.9.0.jar
camel-http-common-3.9.0.jar
camel-jackson-3.9.0.jar
camel-jaxb-3.9.0.jar
camel-json-validator-3.9.0.jar
camel-jsonpath-3.9.0.jar
camel-jta-3.9.0.jar
camel-log-3.9.0.jar
camel-main-3.9.0.jar
camel-management-3.9.0.jar
camel-management-api-3.9.0.jar
camel-microprofile-config-3.9.0.jar
camel-microprofile-health-3.9.0.jar
camel-microprofile-metrics-3.9.0.jar
camel-mock-3.9.0.jar
camel-seda-3.9.0.jar
camel-sjms-3.9.0.jar
camel-sjms2-3.9.0.jar
camel-support-3.9.0.jar
camel-timer-3.9.0.jar
camel-util-3.9.0.jar
camel-xml-jaxb-3.9.0.jar
camel-xml-jaxp-3.9.0.jar
camel-xpath-3.9.0.jar
I have configured and running a weblogic12C server (12.2.1.4.0) on my computer, and I am working with eclipe, where I have a spring boot application with java 1.8.
I need to configure ecplipse to deploy and debug on my local weblogic server.
The problem is that when trying to create the server in Eclipse and indicate what the server will be, its domain and the WAR to deploy, the wizzard says "The server does not support version 4.0 of the J2EE Web module specification."
The strange thing is that my client has a 12C weblogic server (12.2.1.3.0) and I can deploy there without problems via console (ip: 7001 / console).
Any ideas? Will it be a problem with the domain configuration?
Grateful for the answers !!
Some images speak more than a thousand words:
Configuration server weblogic wizzard
Selecting the domain
Indicating that it is a local domain
When trying to move the resource, the wizard tells me that it is not compatible
Checking the domain settings, I don't see anything wrong
According to this document
https://docs.oracle.com/en/middleware/fusion-middleware/weblogic-server/12.2.1.4/wbapp/basics.html#GUID-62B6050D-6DD3-4028-B863-4CD0B5692E7F
WebLogic Server fully supports HTTP servlets as defined in the Servlet 3.1 specification at http://jcp.org/en/jsr/detail?id=340. HTTP servlets form an integral part of the Java EE standard.
It looks like your Eclipse installation is trying to use Java EE version 4, which is not supported by Oracle Weblogic 12.2.1.*
Furthermore, I have found the below post, which I think could be useful to fix your issue.
Project facet Dynamic Web Module 4.0 is not supported by this server
That post explains the issue with Servlet-API version 4.0 and how to configure your IDE to use the version supported by Oracle Weblogic 12.2.1.*
I'd like to deploy the OSS version of artifactory in my existing Tomcat environment. My first try was to simply throw in the two wars that come with the bundled Tomcat. I had to copy over the derby jar, too, so that part seemed to work. I then got blocked by an issue with authentication tokens.
The manual I found is pretty outdated and talks about V2.x only. What I found here was this:
Deployment of my application in existing tomcat
Now - how official is this statement? I didn't find anything on their website saying that it's not supported anymore.
I'd need now
either a helpful resource (for me)
or a link to an official statement (for my management)
Thanks!
Well, I guess this qualifies as an official statement (at https://www.jfrog.com/confluence/display/RTF/Release+Notes#ReleaseNotes-Artifactory4.0)
Tomcat 8 as the Container
JFrog Artifactory 4.0 only supports Tomcat 8 as its container for both RPM and standalone versions. If you are currently using a different container (e.g. Websphere, Weblogic or JBoss), please refer to Upgrading When Using External Servlet Containers for instructions on how to migrate to Tomcat 8.
Could anyone advise as to the pros and cons of using Pivotal tc Server as opposed to just vanilla Tomcat for a Spring-MVC Java web application? Could find very little about Pivotal other than on their website and the fact it's packaged as part of the Spring Tool Suite. This lack of info is making me a bit wary about being dependent on it...
Background: Am preparing the development environment for a Spring-MVC project and currently evaluating whether to use the packaged Spring Tool Suite (STS) or just start with the latest Eclipse (possibly combined with the Eclipse STS plugin). Came across Pivotal tc Server as one of the optional components in this plugin.
Pivotal tc Server contains all of vanilla Tomcat, and has a few optional extensions designed to make it easier to deploy and maintain. Broken out into three groups, the diff looks like this:
Configuration extensions (No altered code, just config changes we implement)
Multi-Instance using shared binaries
Trivial to change Tomcat versions while preserving app and configuration
Variable Substitution in config files
Async Logging
Mild Security Tuning (ports, mgmt apps, JMX)
Code Extensions
Patch version releases – fix flaws in current release [e.g. tomcat-7.0.32.B.RELEASE]
Extended JMX interface
Additional Metrics
Application Deployment
Diagnostics Valve - good troubleshooting info when there's a slowdown
Config Templates – including custom-created
Change log level on the fly
Advanced Session replication (Gemfire)
Oracle DB Connection Proxy
Add-Ons
Windows Service Wrapper
RPM / Apt-Get / Debian installers (linux)
Startup scripts (linux)
Chef Recipes
Puppet Scripts
Password Encryption
Spring Insight for performance tuning
FYI on the tag thing, there's still the old "springsource-tc-server" tag. SpringSource is now Pivotal. (Can/should we update the tag or add a new one?)
Hope this helps.
SpringSource tc Server is an enterprise version of Apache Tomcat, the widely used Web application server. SpringSource tc Server is hardened for enterprise use and is coupled with key operational capabilities, advanced diagnostics, and is backed by mission-critical support.
SpringSource tc Server is designed to be a drop in replacement for Apache Tomcat, ensuring a seamless upgrade path for existing custom-built and commercial software applications already certified for Tomcat. Maintaining this level of compatibility enables our customers to add the business-critical functionality they need to more effectively run and manage their applications with the least amount of effort.
find more information at http://static.springsource.com/projects/tc-server/6.0/getstart/cgsdiffs.html
This doesn't answer your question about the pros and cons, but I found this site really helpful in getting tc server up and running in STS. http://sosiouxme.wordpress.com/2012/04/06/the-missing-guide-to-creating-and-modifying-tc-server-instances-for-sts/
To me it seems a high price for just getting a servlet container.
Specifically, it (the tc server) seems to try to mimmic a production quality application server (servlet engine) with the added features.
For development it seems overkill. You could just as well use Tomcat stand-alone or Glassfish or Jetty.
I would choose the tc server if my target was some cloud implementation of Cloud Foundary that was ultimately my target production deployment environment.
Finally, I just noticed that the tc server is a commercial offering. So, the licensing implications should the features become integral to your delivery, might have a cost that your project would not bear:
https://www.cdw.com/shop/products/SpringSource-tc-Server-Spring-Edition-license/2156278.aspx
We're using Jboss, but we are really only using its JMS stuff. So, is there a way that I can trim down what's loaded when Jboss starts?
You can go for a servlet container (Tomcat) + a JMS provider (ex. ActiveMQ), without using an application server at all.
From 6 years ago, here's a blog entry about configuring JBoss with "just the right stuff."
I haven't used JBoss in a few years, but in v4.0, you could just drop the desired jar files into the deployment directory, and JBoss would load... only those jars.
The correct way to do this, is making a separate profile on your JBoss server that contains only the things needed to use JMS. JBoss v5 comes standard with several profiles: minimal, default, standard, all and web. Each of those starts other services. If you do not specify any profile, you're using the "default" profile.
You can create your own profile starting from a copy of the minimal profile and adding services as needed for JMS support.
The JBoss documentation contains a bit of information on what the files in those profile directories are used for. See Jboss server configurations.
You didn't specify which version of JBoss that you are using. Keep in mind that there are some changes in the configuration between JBoss v4 and JBoss v5/6. The referenced documentation in the answer from Cheeso points to JBoss v4.