I couldn't find an answer to this in any other questions and I wanted to see if anyone knew. I'm using JBoss AS 7.1 on Kepler eclipse, and I was wondering if there is a way to change your standalone.xml while the server is running and have Jboss push the change. Would just cleaning the server do this?
You can't edit the raw XML files and see runtime changes. In fact there is a good chance any changes will be overwritten by the server.
The best way to make runtime changes is either via the web console or the CLI environment. I don't know if JBoss Tools has any kind of CLI type of client that can be used.
Related
is it possible to run Solr 6.4.1 on tomcat?
I read that Solr does not support tomcat anymore, is that true, if yes is there any other option without tomcat?
Yes, any version of Solr from 5 and onwards does not support Tomcat as an alternative officially.
The reasoning for this has been documented on the wiki:
Solr is intended to be a server not a Java web application, similar to mysql or the Apache web server. When Solr was first created, designing it as a web application was a convenient choice, to avoid writing a lot of tricky code to build a network layer. These days, this design decision has become a limiting factor.
When you download Solr and install it onto your machine, it should be Solr that gets started. It should not be necessary to install Solr into a third-party application (servlet container) before it will work.
At this time, Solr is still a webapp, but this is an internal implementation detail, not an immutable property. The intention is to make Solr into a completely standalone application. Startup scripts that start the included container are the first step towards that goal. Jetty might still be the technology used once Solr is a standalone application, but if that happens, it will be internally embedded.
At the moment you can still attempt to run Solr in a different container, as the current version bundles jetty and loads Solr inside jetty, but you can run into unexplainable issues where you'll always suspect the container to be the issue .. and if you have a problem, reporting bugs while running under Tomcat won't do any good.
From one of the comments on the old tomcat page on the community wiki:
If you want to go against recommendations and run 5.3 or later in Tomcat, you can likely still do so, but you will need to inform tomcat about an exploded web application (found in server/solr-webapp) instead of the .war file.
The server/solr_webapp/webapp folder is an exploded web application. Tomcat documentation should be able to tell you how to add such an application.
.. but if you're deploying Solr now, you really shouldn't. Use the bundled version of jetty (which might change to a stand alone version later) and the solr command / script.
They have stopped the support for the same.
Other option could be, you can check out the code and see if you can build the solr. I had tried it for earlier version (3.3).
I am not sure of the current version. But that could be the option for you.
I have posted instructions on how to get solr 6.2 running on Tomcat here. However, these instructions no longer work on Solr 6.3 or 6.4.
Does anyone have any idea how this can be done?
It's my understanding that WebSphere 8.5 traditional is not compatible or will not run on OSX. I am looking for solutions for developers to develop with a WebSphere 8.5 traditional server locally.
Could we setup some servers on a windows machine so they can be used remotely during development?
I downloaded the Eclipse plugin but it gives me the warning saying OS X is not compatible with WebSphere traditional and to give it a remote server address. I tried to point eclipse to a server on a windows PC but it still wants a runtime installation directory.
I found a single thread on WASDev with a similar question talking about runtime stubs with a dead link.
I tried using a liberty server but I get nothing but null pointer exceptions and JMX errors, I don't think this is a valid alternative in my corporate environment.
For developing against WebSphere traditional on OSX, you could try Docker! We've published developer edition versions of 8.5.5.9 and 9.0.0.0, see:
https://developer.ibm.com/wasdev/blog/2016/06/15/websphere-traditional-ibm-http-server-docker-hub/
https://hub.docker.com/r/ibmcom/websphere-traditional/
The Dockerfiles used to produce these images are here, should you want to try building your own instead:
https://github.com/WASdev/ci.docker.websphere-traditional
However, your question is more specific to getting the tools working.
The last I read (and I'll try to confirm/update the answer when I do find it), is that the stubs are part of the full product install for RAD (selectable via Installation Manager).
You're correct that traditional WAS doesn't run on OSX. Remote servers are an option but traditional WAS is considered by some developers to be heavy and slow to restart, so your developers might appreciate something local and more nimble. Liberty is supposed to run on OSX, and things that run on Liberty -usually- will run on traditional, so getting to the bottom of your Liberty problems might be useful. If you haven't already, posting your question on WASDev might reach someone that has a better answer than this one.
Right now i am developing an app on remote DEV server. Every time when i update the code (js,html,css etc) then test on the device locally. There is a popup to force me to update the app. But my app need to connect DEV server for testing some backend feature like login.
DEV server is a remote Websphere running WL6.1 for development purpose. Why i need it because my app connect to some web services like Auth server via internal environment (actually is VPN). And those services i cannot set up easily in local environment. That makes using localhost for development is not really possible.
My problem is feeling the development process not really handy. Every time i change the code and want to run on the devices. I need to upload the .wlapp via console. It takes time! Everyday i change the code thousands time. That's why i need a solution.
And now i am seeking for 2 possible ways:
Auto push the .wlapp to remote server when i run and build. Can ANT do that? i read the Doc and find it's a bit of complicated.
Disable Direct Update. Actually i do a tricky hack inside worklight.js to override this feature. But i think it is not a good solution. So, is there any server config can switch the that off?
And i read this thread IBM Worklight - How to disable Direct Update?
Not working.
From what you are describing, things seem to work exactly as they should.
You have your local Worklight Development Server (that's the Worklight Studio plug-in you've installed in your Eclipse).
You have a remote server - here I am presuming this is actually some application server with Worklight Server deployed on it (that is, not the plug-in, but an actual installation of the server component) as well as your deployed project's .war file.
If that's not your setup, you need to think again about your 'testing setup'.
Auto push the .wlapp file to remote server. So the dev server always
keep the latest resource. Not to force me "update" the older version
on the server.
No. You can't do this. You need to manually build your app with the correct connectivity settings for the remote server via Run As > Build Settings and Remote Target.
In addition to the native project that will now contain these connectivity settings for the actual app, you will also have a .wlapp file in the bin folder. You will need to manually deploy it each time you're changing your app's contents. That's why you do development testing in the local development server... when moving to a remote server, that's for QA/UAT/PROD purposes usually.
Just disable this annoying feature in DEV environment.
You will need to do this in both servers via their respective Worklight Console as described in the question you've linked to, so that once you deploy the .wlapp file, it will not send a Direct Update request.
Instead, you'll need to manually re-install the app each time.
I suspect you didn't do this action on the remote server?
If you did, then you need to explain your setup, as the only thing you've wrote about was its name... "dev".
No. You need to manually deploy the .wlapp to your remote server.
I am have to develop an application based on Spring AOP that adds trace Id and loggers to existing application in live production.
The new aop application needs to be packaged onto jars and is to be deployed on code in production. But the production code is running on weblogic server and I don't have option to stop the already running weblogic servers.
Can any body help or give me the clue on how to introduce this new jar to the running application on weblogic.
Thanks in advance.
It's a bit late , but i found this question while searching for the same thing.
The nostage mode can help you with this,I tried it for JSP's and it works great , not sure about the jars though
These links are useful , they might help --
http://docs.oracle.com/cd/E11035_01/wls100/deployment/deploy.html#wp1024366
How do I refresh jsp's on weblogic
What is the impact on existing code to migrate from WebSphere MQ V6 to V7?
Can we make simply the change?
Like all good questions, the answer here is "it depends."
First of all, don't go to v7.0, go to V7.1 at least, better yet to V7.5.
Using client or bindings mode connections? You can upgrade the QMgr without touching a client-based app in most cases. Any version of WMQ client can talk to any version of WMQ server, however its best not to leave apps on an unsupported version of WMQ client. Of course, the app running on the old client won't get the new function such as automatic reconnect or performance improvements, even though the QMgr is at V7.5.
Using SSL? The SSLPEER element order changed and the commands to manage certificates changed. Good news, cert management is now performed with runmq*km commands living in the {mq install}/bin directory so you don't need to hunt down the GSKit directory and figure out whether to use gsk6*, gsk7* or gsk8* commands.
If you go from 32 to 64 bit, you may need to recompile programs or exits.
Correct settings for PATH, CLASSPATH and LIBPATH change across versions.
There's much more and it's well covered in the Infoceenter. Each Infocenter has a section on migration. Within that section, there's subsections by version and within those there are subsections by platform. Pick the target version of WMQ (that's V7.5, right? Say yes!) and and drill down. Start here:
Migration from V6.0 to V7.5
Migration from V6.0 to V7.1
Migration from V6.0 to V7.0