I have a 2 war projects deployed as a library on a weblogic server (version 1 and version 2) and an EAR project deployed on the same server that uses the library.
When I deploy the library version 2 stays on prepared state and the version 1 remains in active state. Does somebody know how can I do to make active the 2nd version of my war?
thanks!
Under deployments, did you try selecting the library of interest and explicitly clicking on Activate? If you do not see the library there, you may have to modify the view of your console to include libraries in your deployment page.
If there are conflicts with the other library, you'll get the full stack trace within the stand log files. You also have the option of stopping the currently 'active' library before enabling the newer one to avoid conflicts.
Related
I'm using Mule Server 3.8 EE which brings commons-lang 2.4 with it. A third-party library in my project needs commons-lang 2.6, because it uses a method that was introduced in this version.
So when I just start my application, I get a java.lang.NoSuchMethodError
Is there a way to update the dependency in the runtime? What I tried so far:
including commons-lang 2.6 in my app -> no effect, the one from the runtime is picked up first
replacing the jar directly in the runtime -> errors in studio, that the 2.4 jar is missing
so maybe i am late BUT -- this is your answer. Add the libraries that are newer in the jar distribution to the Build Path. Under Java Build Path screen you should see the libraries listed. I needed to use Apache http-client 4.5.6 and that's very interesting because it brings with it a lot of other dependencies, so your question was VERY relevant. The solution is to rely on JAVA (and not mule -- oops Anypoint or whatever) conventions and make sure the JVM loads my class files first. Then, it won't load the old ones from mule's jar. And so I went to the tab Order and Export, and moved Mule to the bottom. This simple, trivial change makes it work. I think if we would work with command line and vim, we would all know this. But all the IDE gui and everything else makes us forget the simplest things. Please use it in good health. :)
We're using Worklight 6.1.0.0 / WebSphere 8.0.0.2 (ND/aix).
This seemed pretty close to my question too, but for version 6.0.
I've successfully done uninstall/install to our worklight console war package. However, there is some extra work on re-deploying adapters and such. I was looking for a way to just update the console. Among the ant tasks there is a target 'minimal-update', which sounds like what I'm looking for (is it?). However when all other pieces fell into place, I have an error for mapping the datasources:
ADMA0007E: A validation error occurred in task Mapping resource references to resources. The Java Naming and Directory Interface (JNDI) name is not specified for resource reference jdbc/WorklightDS in module Worklight with EJB name .
Contents of the 'minimal-update' task is pretty much the same as for 'install'.
I tried that as update from websphere admin console (but i should use the ant task - right?), that gave me a wizard screen to map jdbc/WorklightDS from package to jdbc/WorklightDS on server. This left me wondering how could I tell this using the ant task.
The ant target minimal-update of the sample configuration files documented at http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/topic/com.ibm.worklight.deploy.doc/devref/c_ant_tasks_sample_config_files.html is meant to update a WAR file already deployed (and not uninstalled). In particular, on WAS, it assumes that the JNDI datasources are in place.
If you have uninstalled the WAR file, you should use the target install instead, provided that your databases were created for Worklight 6.1.
If they were created for a previous version of worklight you must upgrade their schema as well running the target 'databases' (and if it's a production installation, you might want to read all the steps in detail at http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/topic/com.ibm.worklight.upgrade.doc/devenv/c_upgrade_to_srvr610_in_production_env.html )
I have a Worklight 6.0 project that uses the new Dojo 1.9 libs, I created an external dojo project, like the documentation suggested, then, in the main project properties, under "Dojo toolkit", it references this dojo19 project.
The project works on the local server, then I did "Run As" | "Build for Remote Server...", and entered the correct domain:port and context path, clicked Build, the *.wlapp files were updated. (I've also updated the settings for publicWorkLightHostname / publicWorkLightPort / publicWorkLightProtocol in the "Environment Entries for Web Modules" in the installed war to match the remote server names/port/protocol.)
But, after deploying both war and -all.wlapp file, accessing the app I get JS errors when it tries to refer to the dojo19 library:
The page at
https://<myIP>:9443/<myproject>/apps/services/www/ /mobilewebapp/default/IODMobile.html
ran insecure content from http://localhost:64441/dojo19/<myproject>/IODMobile/mobilewebapp/dojo/nls/core-web-layer_en-us.js.
The dojo19 is the project name in my Worklight developer workspace that I referred to above.
Why is it trying localhost? Seems there's a missing step here in deploying the dojo library project into Worklight.
Where are you trying to preview the application when you get the error message?
See the changes in Dojo in Worklight 6.0
If launching the application in emulator/simulator/device, see Billy Rowe's answer in this question
Partial copy/paste:
Step 1: Verify your application works in the Mobile Browser Simulator
with Provide Library Resources checked. If the Console log is showing
resources being served from the server, then these have to be copied
to your application before deploying to AVD or a device
Step 2: After you think you have all Dojo/resources within your
project, uncheck Provide Library Resources and test it again in MBS.
If it fails in MBS, then something is missing in your application that
is in the library/server. You can check Provide Library Resources and
retest to see if it shows you what that is. Not all resources are
shown, e.g. if there's a missing CSS file.
Also I would suggest to do all of this in the Development environment (that is, in Eclipse) before starting to deploy the .war file and .wlapp file etc... (which, BTW, I hope you're doing based on the new instructions for Worklight 6.0)
In the information center, it will show you how to uncheck the Provide Library Resources in the Console Log.
I think what you're running into is:
1) Something is being served from the Dojo Library/Server
2) A bug in 6.0 that used "localhost" instead of the IP of the host (your machine running eclipse). This is fixed in the 6.0 iFix. With this fix, you can run your app external to Studio and still use the Dojo Library/Server. Without this fix, you must have everything you need within your app.
Can you install the iFix and let us know if that fixed the problem?
I've just installed Worklight 6.0 on Mac OS X Mountain Lion 10.8.4.
I'm trying to build a very simple HelloWorklight app to test the installed environment and I'm getting errors building and deploying it.
I'm getting these errors in Eclipse console:
[2013-07-13 02:11:21] Starting build process: application
'HelloWorklightApp', all environments
[2013-07-13 02:11:21] Application 'HelloWorklightApp' with
all environments build finished.
[2013-07-13 02:11:21] Deploying application
'HelloWorklightApp' with all environments to Worklight Server...
[2013-07-13 02:11:21] Failed to deploy the application to
Worklight server: Worklight module
HelloWorklightProject was not
successfully started. Full details of the error are available from the
Worklight Development Server console.
The Worklight Development Server console in my browser shows:
Application Error
SRVE0777E: Exception thrown by application class
'com.worklight.core.auth.impl.AuthenticationFilter.doFilter:110'
javax.servlet.ServletException: Worklight Project not initialized
at com.worklight.core.auth.impl.AuthenticationFilter.doFilter(AuthenticationFilter.java:110)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:194)
at [internal classes]
I'm truly stuck. On the other hand I'm sure it must be something simple to fix it.
Has anyone got an idea how?
I had a similar problem (at least WDS console error looks the same).
A little bit history:
My problems started, when I updated Worklight to version 6 (with version 5 I had no problems). Some compilation erros were fixed by adding Websphere Library to a project. But my custom authentication still wasn't working.
How I fixed it:
open new workspace in Eclipse
import Worklight project
clean project
restart Eclipse
downgrade compiler compliance level (in Eclipse: Window > Preferences > Compiler and set "Compiler compliance level" to lower version)
rebuild project and try to run it
At this point it started to work. I've spend lots of time to find out that compiler stuff, but still I'm not sure which part requires that.
So we had this issue with 2 macs and it took us a solid day and a half to figure it all out.
We went through a lot of reconfiguring, re-downloading eclipse and worklight.
Make sure your config files from the update are correct. (worklight.prop and authConfig)
This is the big one. Install JDK 1.7 and reference the new JRE 7. When we
were running on Oracle JRE 6, we had a ton of errors and even a Java
Heap memory issue.
Once you install it, it may to be tricky to find the actually path to the JRE.
First, go to Eclipse > Pref > Installed JRE's > Add
Then, add a new standard vm. Click Directory on the next pane and browse to the install path of JRE.
We found it in [name of your HD] > Library > Java > JavaVirtualMachines > jdk1.7.0_25.jdk > Contents > Home > jre
It should load everything it needs and you can click the check box of the new JRE. For good measure, I changed the compiler to 1.7 as well.
The jdk folder may have a slightly diff name depending on what update you have. Hopefully this helps.
I got the same error after deploy an new app deployment.
What I've done on Server is:
delete all application
delete all extra configuration between new server instance and my current instance. In my case it was: applicationMonitor and shared librairy
clean
restart
After that I managed to deploy my application normally
window -> show view -> servers -> server configuration -> HTTP EndPoint -> host
By default the host will be *. Try to change the host as your local machine ip address. for example host = . After changing the host, close the server.xml and then try to rebuild the project.
I want to upgrade Glassfish without internet connection. But I have already downloaded the latest version.
I have done the following steps,
For eg. galssfish-3.0 is the older version and glassfish-3.1 is the newer version.
Step: 1
I just copied the glassfish-3.0/glassfish/domains/domain1 and pasted in glassfish-3.1/glassfish/domains
Step: 2
In glassfish-3.1/bin ./asadmin i just give the command asadmin> start-domain --upgrade
then i checked the version asadmin> version the ouput was
Version = GlassFish Server Open Source Edition 3.1.1 (build 12)
Command version executed successfully.
Is this correct or I need to follow some other ways to achieve this? If wrong Please guide me the right way.
Can anyone help me?
Thanks in advance,
Gnik
Regarding the Oracle GlassFish Server 3.1 Upgrade Guide you did it right.
There are some hints in this guide for the migration of deployed applications:
Application archives (EAR files) and component archives (JAR, WAR, and
RAR files) that are deployed in the source server do not require any
modification to run on Oracle GlassFish Server 3.1. Components that
may have incompatibilities are deployed on GlassFish Server 3.1 with
the compatibility property set to v2 and will run without change on
GlassFish Server 3.1. You may, however, want to consider modifying the
applications to conform to Java EE 6 requirements.
...
Applications and components that are deployed in the source server are
deployed on the target server during the upgrade. Applications that do
not deploy successfully on the target server must be deployed manually
on the target server by the user.
If a domain contains information about a deployed application and the
installed application components do not agree with the configuration
information, the configuration is migrated unchanged, without any
attempt to reconfigure the incorrect configurations.
You should read through the guide carefully and check your deployed applications for any errors / exceptions during server startup or manual redeployment.
Some time ago I made an update as described in the update guide from 3.0 to 3.1.1 and cannot remember any bigger problems.