Websphere ejb build - websphere-8

I am trying to run ejbdeploy.sh on my Linux server which has websphere 8.5.5.9 and my project which I want to build is in java 8 whenever I run ejbdeploy.sh on server it gives me compilation errors for my code which is in java 7 or 8 and the compilation error says that resource level bellow 1.7
Clearly it is trying to compile my code using Java 6.
Please provide me with the approach to deal with this problem and build the project either in java 7 or java 8

There is a new .sh file included in the websphere packaging. I specifically don't know from when but I replace ejbdeploy.sh with createEjbstubs.sh and the parameters for createEjbstubs.sh are different from that of ejbdeploy.sh but still they are similar so you can change your build commands to now use createEjbstubs instead of ejbdeploy and it works fine on websphere 8.5.5.9.

Related

Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. Unrecognized option: --module-path

I tried to run my application of JavaFx using MVC
C:\Users\Bryan\Documents\NetBeansProjects\Practica_Arqui\nbproject\build-impl.xml:1342: The following error occurred while executing this line:
C:\Users\Bryan\Documents\NetBeansProjects\Practica_Arqui\nbproject\build-impl.xml:969: Java returned: 1
You have tagged your question "javafx-17", but you are not using a compatible JDK. Likely you are using Java 8 (which does not have a module path).
Ensure that you have only java JDK 17 (not just JavaFX 17) installed on your machine and that your development environment is configured to use it.
Also ensure that your development environment, and every other piece of software that you use, is up-to-date, running the latest released stable versions.

System.Text.Encoding.CodePages missing in netcoreapp2.0 app

I just installed a clean install of the new .NET Core SDK on a CentOs 7 box. I had a different Linux VM I was running to test this and received the same error there.
I am building my application in VS 2017 on a Windows box and copying the project file over to the Linux box to test it. I am coming from netframework environment and trying to learn dotnetcore so I am sure this is probably just a newb issue. Here is what I am doing.
I run a dotnet restore, which works without error.
I run a dotnet build, which I receive a
Build succeeded.
0 Warning(s)
0 Error(s)
Then I run a dotnet run and receive the following error:
Error:
An assembly specified in the application dependencies manifest (apf-ws.deps.json) was not found:
package: 'System.Text.Encoding.CodePages', version: '4.3.0'
path: 'runtimes/unix/lib/netstandard1.3/System.Text.Encoding.CodePages.dll'
Nowhere in my code do I actually reference any type of Encoding explicitly. I have tried including System.Text.Encoding.CodePages in my project to see if that would add a reference and bring in the library to ignore the one it is looking for, but it doesn't help. Anyone have any ideas of what would be causing this?
I tried several things before wiping the directory out in Linux and copying the files over again. In doing so it seemed to fix the problem.

Self-contained deployment .NET Core app in Ubuntu

I wrote a test project using .NET Core and assembled the self-contained deployment for Ubuntu 16.04 as described here (see Self-contained deployment without third-party dependencies).
But when I run the app I get the following error:
An assembly specified in the application dependencies manifest (Test.deps.json) was not found:
package: 'runtime.linux-x64.Microsoft.NETCore.App', version: '2.0.0-preview2-25407-01'
path: 'runtimes/linux-x64/lib/netcoreapp2.0/Microsoft.CSharp.dll'
I am using .NET Core 2.0 Preview 2, VS2017 Preview.
I will be grateful for any help!
This is an old question, but I just ran across this when I was trying to run a .Net Core application on Linux and wanted to share the solution. If you are getting the error above, you are likely trying to execute the wrong binary. For those following along from scratch, follow these steps:
On Windows, open a command prompt in the directory of the project you want to run on Linux.
Build the project for Linux using dotnet publish -r linux-x64
I chose to target linux-x64, but you can target a specific runtime if you'd like. Runtime identifiers can be found here.
Copy the published files to the Linux workstation. Because the above command omitted the configuration flag -c, the configuration defaulted to debug. The published files will be in Debug\netcoreapp2.0\linux-x64\publish
Note: there will be binaries in Debug\netcoreapp2.0\linux-x64\ too. These are not the binaries you want to copy to your Linux workstation. If you run these binaries, you will get the error described in the OP. Copy all the files in the publish directory instead. Ignore whatever files might be in linux-x64.
On the Linux workstation, give execute permission to the binary file. My project was named ConsoleUI, so I used chmod 764 ConsoleUI
Execute the binary using ./ConsoleUI
Keep in mind that you will need to at least have the .Net Core runtime installed on your Linux workstation.

Project 'Unable to locate Dependency' on itself

I'm trying to run the latest Asp.Net 5 samples (currently 1.0.0-rc1-update1) on my Ubuntu 14.04 VM guest using VirtualBox on Windows 10. The sample code is being run via shared host directory.
I have the active and default DNX set as the CoreCLR x64.
When I have run the dnu restore command against either of the 2 web projects, the restore completes but with an error message. For example, for the HelloWeb project:
Unable to locate Dependency helloweb >= 1.0.0
If I run then command dnx web for the web projects I get the error message:
Error: Unable to load application or execute command 'Microsoft.AspNet.Server.Kestrel'. Available commands: web.
I have a related question here as I am also trying to also get the same samples running on my Windows machine. As they are basic and also unmodified, so I can't understand why they are not working. To make things worse, I actually had them running on this VM yesterday in the same manner I am trying here and as far as I'm aware, nothing has changed other than I have restarted the VM in the meantime.
Can anyone suggest why the projects are referencing themselves in this way and how I can resolve it?
The issue was being caused because the source code was being shared and the project.lock.json file had been created by the dnu restore process on Windows. I created a separate set of code samples and the code restored then ran fine.
This doesn't explain why the message was appearing but I assume the message Unable to locate Dependency helloweb >= 1.0.0 is actually a red herring and possibly refers to the fact that it can't replace the lock file.

Registry Key '...' has value '1.7', but '1.6' is required. Java 1.7 is Installed and the Registry is Pointing to it

My development team recently was forced over to a remote development environment where we do not have full access to the servers. Before the change over we had a JAR that was running fine on Java 1.7 x64 along with JRE 7. When we moved over to the new server our JAR was running alright, but then one of the server admins "updated" our Java to an older version and uninstalled the one we were using. Don't ask me why, I don't know. I re-installed Java 1.7 and uninstalled 1.6 along with the JREs.
The following problem occurs at runtime, there are no build errors:
Registry key 'Software\JavaSoft\Java Runtime Environment\CurrentVersion'
has value '1.7', but '1.6' is required.
Error: could not find java.dll
Error: could not find Java SE Runtime Environment.
I've run the same JAR on my laptop with no issues. Both the server and my laptop have JDK 1.7 and JRE 7 in the respective %HOME% variables and system PATH. I've even reinstalled JRE 6 and placed it later in the system environment PATH variables with the same result.
I have also changed the registry back to look at 1.6 and it results in the following, which I looked up and it appears to be from having multiple Javas installed (leading back to my original problem):
Exception in thread "main" java.lang.UnsupportedClassVersionError: ... :
Unsupported major.minor version 51.0
I would appreciate any insight you all have as I have been looking over various forums but nothing seems to have exactly my problem. Also, this has happen on another server we are using as well. Thanks!
Update: No luck with recompiling the JAR to either 1.6 or 1.7 and matching the JDK. Also, why in the world would a newer version of Java break an older compiled version?
This happens when you somehow confused java itself. You are trying to run a java 6 VM where it found a JRE 7. It might show this problem even if you type in the command line just java or java -version in a misconfigured environment. The JAR is not the problem, except in the very unlikely case where the code in JAR is looking in the Windows Registry for that (which probably is not your case).
In my case, I had the java.exe, javaw.exe and javaws.exe from Java 6 in the Windows/System32 folder (don't know how it got to be there). The rest of the JDK and JRE where found in the PATH inside C:\Java\jdk_1.7.0\bin. Oops!
Just had the similar error when installing java 8 (jdk & jre) on a system already running Java 7.
Error: Registry key 'Software\JavaSoft\Java Runtime
Environment'\CurrentVersion' has value '1.8', but '1.7' is required.
Error: could not find java.dll Error: Could not find Java SE Runtime Environment.
My environment was set up correctly (Path & java_home correctly defined), but the problem arises from the way pre-8 Java installers worked, which is that they used to copy the three executables (java.exe, javaw.exe & javaws.exe) to the Windows system directory. These remain unless overwritten by a new pre-8 installation.
However the Java 8 installer instead creates symbolic links in a new directory, C:\ProgramData\Oracle\Java\javapath, pointing to the actual JRE 8 location.
This means that you'll actually run the old 7 exes but use the new 8 DLLs.
So, the solution is simply to delete the 3 Java exes, as above, from the windows system directory.
If you are running 32-bit Java on a 64-bit Windows, the exes would be in Windows\SysWOW64, otherwise in Windows\System32.
I've deleted java files at windows/system32 and I also have removed c:\ProgramData\Oracle\Java\javapath from the PATH variable, because there was 3 symlinks to java 1.8 files.
I had JDK 1.7 in the %JAVA_HOME% variable and java1.7/bin in the PATH.
PS1: My problem was between Java 1.7 and Java 1.8.
PS2: I can't add this as a comment to Victor's answer because I haven't enough points.
In the START menu type "regedit" to open the Registry editor
Go to "HKEY_LOCAL_MACHINE" on the left-hand side registry explorer/tree menu
Click "SOFTWARE" within the "HKEY_LOCAL_MACHINE" registries
Click "JavaSoft" within the "SOFTWARE" registries
Click "Java Runtime Environment" within the "JavaSoft" list of registries here you can see different versions of installed java
Click "Java Runtime Environment"- On right hand side you will get 4-5 rows . Please select "CurrentVersion" and right Click( select modify option) Change version to "1.7"
Now the magic has been completed
I don't know if anyone is still following this thread, but I recently had this issue when I tried to launch ActiveMQ 5.10 as a Windows service.
I didn't have a JAVA_HOME path set.
I had Java 6 and Java 7 installed, but the default version was v7. (ie if I opened a command window and types "java -version").
This is where the clue was - "java -version" returned "Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)" but I was had installed the Win32 service...
It turns out that if you use the Win32 wrapper on a 64-bit machine it somehow decides to use a different version of Java...
So my fix was to uninstall the 32-bit version of the wrapper and install the 64-bit version.
aversion on my machine; just habit I guess... But luckily I resolved the issue eventually...
For my Win7
Paradox was in being java.exe and javaw.exe in System32 folder.
Opening that folder I couldn't see them but using search in Start menu I get links to those files, removed them. Next searsh gave me links to files from JAVA_HOME
magic )
Change to directory with correct java.exe i.e. go to the required JDK version java.exe
cd C:/Program Files/Java/jdk1.7.0_25/bin
Run the java.exe from this directory, it has precedence over registry and $PATH settings.
java -jar C:/installed/selenium-server-standalone-2.53.0.jar
I solved this problem by uninstalling Java 1.8
The jar was compiled to be 1.6 compliant. That is why you get this error. Two resolutions:
1) Use Java 1.6
OR
2) Recompile the jar to be compliant for your environment 1.7
Using regedit, remove the entries corresponding to java 7. It will work.

Resources