I have foo.ear that can be deployed or updated to WAS 7 without problems. foo.ear have some ext resources and group settings that i need merge when deploy to WAS and through console all works perfctly but take lage amount of time to go through all process. So I prefer automatic deploy from Intellij IDEA (2018) but when IDEA do deployment it drop all current bindings (ext resources and group settings) and i not found any option to mearge or at last save current bindings of app. So my question is could this be done from IDEA or at last from some script(e.g. maven)?
I believe that the thing is you're looking for is -bindear option.
You can manually provide build post/pre processing steps with IDEA
https://www.jetbrains.com/help/idea/pre-processing-tab.html
So you can try to invoke this with the ant task where you exec ejbDeploy command from that ant task with that option.
More about the task you can found in the documentation:
https://www.ibm.com/support/knowledgecenter/SSRTLW_9.1.0/com.ibm.ejbdeploy.doc/topics/regenc.html
Related
I work on a Kotlin-based cloud microservice. From time to time I need to run it in the IntelliJ debugger, but we often accidentally break the "local debug flow". There is no pipeline that checks if the IntelliJ run-configuration and the somewhat complex set of cloud-simulating proxies and mock-servers are in sync with the code base.
I would like to write a script that helps me check if the local debug flow works. The script should do the following:
build the project
start up the "mock cloud"
start the service locally using an IntelliJ run-configuration
run a Postman-collection against the locally running service
I need help with step 3 (and possibly step 1): How can I start the IntelliJ run-configuration via command line? I am using IntelliJ IDEA 2021.2 and MacOS 12.3.1.
There is no built-in way to start a Run Configuration from the command line. Instead, you should execute java/kotlin binary with classpath etc.
For example, for "Application" configuration it is needed to run the command like that:
Introduction
I've looked around and haven't seen anyone else having my issue.
Basically, I am wanting to run a start.bat file to start up my server before I start up my debugging session. I currently have my debugging inside of an IntelliJ Configuration and it works well. The problem is that in the options for my configuration I can't seem to add an "External Tools" task to the Before Launch section. I was able to add a maven task here previously. However, when I follow the following steps, the "start.bat" is not added.
First I go into Settings->Tools->External Tools to add my Spigot-Server tool which basically calls the start.bat file inside of a test-server directory.
Snippet of External Tools
Second, I go into my "Debug Spigot" configuration and at the bottom, I see a "Before Launch" Section.
Snippet of Spigot Debug options
I click on the + inside of that section to add a new task, and I click on "External Tools"
Snippet of adding External Tools Task
And then I make sure my Spigot-Server task is selected.
Snippet of select external tool
And then once I hit okay, the window closes but I don't see a new task added to the before launch section. It looks the same it did before I clicked on anything. I also don't see any status message at the bottom of IntelliJ
I basically expect the task "Spigot-Server" to show under the Before Launch section. This would basically start up the server and once the server was completely started, it would then launch the debugging configuration.
I think it may be an issue with IntelliJ's UI. I searched IntelliJ's issue tracker But couldn't find any that matched.
I'm wanting to know if there are any work arounds to get this setup in IntelliJ>
I was able to achieve my goal by doing some workarounds that I discovered with the help of CrazyCoder. I found this stackoverflow question that told me about the batch plugin.
I was able to create a Batch run configuration for a wrapper batch file that gets around the limitation CrazyCoder mentioned. He said that even if I did get my setup where my server runs before my debugging is launched, my debugging would never launch. This is because the terminal process needs to exit before the next task starts.
To get around this this is the wrapper batch file I created.
#echo OFF
START "Spigot-Server" /D C:\Users\rocke\Documents\Programming\Minecraft\Spigot\capture-the-carrot\test-server "start.bat"
ping -n 3 127.0.0.1 >nul
It basically uses the "START" command to run the task asynchronously and then waits 2 seconds. This is because all I need to do is wait for the start.bat command to run the very first part so that it establishes remote debugging. And then the wrapper ends after 2 seconds (the 3 represents the number of seconds I want to wait +1). And this allows the Debugging process to start while also ensuring that the server has setup remote debugging!
I'll just share screenshots of my configuration if anyone wants to do the same.
Maven Build Configuration
Spigot Server Start Configuration
Remote Debugging Configuration
The way this is setup is once I run the Remote Debugging Configuration, it has a "Before Launch" Task of Spigot Server. Spigot Server also has a "Before Launch" Task of Maven Build Project.
So my Maven Build Project runs, then my Spigot Server wrapper runs and after 2 seconds terminates, and then my Debugging Configuration runs!
If you have any questions regarding remote debugging with spigot, use this resource: https://www.spigotmc.org/wiki/intellij-debug-your-plugin/
New to working with MuleSoft, and I am getting an error "There are some error in the current classpath" when adding in a Transform Message into the Message Flow. I have just finished setting up Anypoint Studio, so this might be a configuration step I have missed somewhere.
DW Script Error
Payload (default)
I also faced the same issue and i follow below mentioned steps,
Go to the project Right Click > Mule > Update Project Dependencies
Note:- Before performing above steps make sure, you are connected with internet.
Hope it will work for you.
I had the same issue this morning and after a lot of playing around have finally managed to get it working. What did the trick in the end was to go to Project -> Properties -> Java Build Path, click on the Mule Server 3.7.2 EE entry, hit Edit, reselect the same version of the server runtime, click Finish, click Ok. This in itself didn't seem to make any difference, but then I restarted Anypoint Studio and everything was now working correctly.
I have done some digging, and found the following difference in the projects .classpath file:
before:
<classpathentry kind="con" path="MULE_RUNTIME"/>
after:
<classpathentry kind="con" path="MULE_RUNTIME/org.mule.tooling.server.3.7.2.ee"/>
Hopefully this works for you too.
Right click the project --> go to the properties --> select the required java version and any domain projects --> remove any un-referenced java version/domain from Java build path.
Check once if MAVEN_HOME is added as environment variable and %MAVEN_HOME%\bin is added to path variable in environment variables.
Also try deleting the .mule file created in the workspace and then try restarting Anypoint Studio. After that in command prompt traverse till your project folder and run mvn clean install command.
I am using the latest (2014-01-03) Golang plugin for IntelliJ - for the first time.
Usually, my terminal workflow is to do go build && ./executable -args=1
So I am attempting to create a launch configuration to do the same thing, I took these actions:
Create a "Go Application" configuration
Fill in GOPATH/GOROOT environment variable
Fill in CLI arguments
Because there has to be a file to run, so I chose the one with func main()
Then there is a problem. When I run the configuration, the Golang plugin does not build the project, but instead builds the single script file with main method, then attempt to run it - obviously it does not work.
How to create a configuration equivelent of go build && ./executable -args=1?
Try to use the latest version from the official plugin manager.
If that doesn't work, please help us identify the issue by submitting a report here
Also, we are working hard to update the plugin with better type checks, debugging, go appengine support, improved formatter and much more but any help in improving the plugin is greatly appreciated.
Hope it helps.
However, I prefer to use goclipse which support auto-build, auto code completion and debug.
I have a few EJBs compiled with Weblogic's EJBC complient with Weblogic 9.2.1.
Our customer uses Weblogic 9.2.3.
During server start Weblogic gives the following message:
<BEA-010087> <The EJB deployment named: YYY.jar is being recompiled within the WebLogic Server. Please consult the server logs if there are any errors. It is also possible to run weblogic.appc as a stand-alone tool to generate the required classes. The generated source files will be placed in .....>
Consequently, server start takes 1.5 hours instead of 20 min. The next server start takes exactly the same time, meaning Weblogic does not cache the products of the recompilation. Needless to say, we cannot recompile all our EJBs to 9.2.3 just for this specific customer, so we need an on-site solution.
My questions are:
1. Is there any way of telling Weblogic to leave those EJB jars as they are and avoid the re-compilation during server start?
2. Can I tell Weblogic to cache the recompiled EJBs to avoid prolonged restarts?
Our current workaround was to write a script that does this recompilation manually before the EAR's creation and deployment (by simply running java weblogic.appc <jar-name>), but we would rather avoid this solution being used in production.
I FIXED this problem by spending a great deal of time researching
and decompiling some classes.I encountered this when migrating from weblogic8 to 10
by this time you might have understood the pain in dealing with oracle weblogic tech support.
unfortunately they did not have a server configuration setting to disable this
You need to do 2 things
Step 1.You if you open the EJB jar files you can see
ejb-jar.xml=3435671213
com.mycompany.myejbs.ejb.DummyEJBService=2691629828
weblogic-ejb-jar.xml=3309609440
WLS_RELEASE_BUILD_VERSION_24=10.0.0.0
you see these hascodes for each of your ejb names.Make these hadcodes zero.
pack the jar file and deploy it on server.
com.mycompany.myejbs.ejb.DummyEJBService=0
weblogic-ejb-jar.xml=0
This is just a Marker file that weblogic.appc keeps in each ejb jar to trigger the recompilation
during server boot up.i automated this process of making these hadcodes to zero.
This hashcodes remain the same for each ejb even if you execute appc for more than once
if you add a new EJB class or delete a class those entries are added to this marker file
Note 1:
how to get this file?
if you open domains/yourdomain/servers/yourServerName/cache/EJBCompilerCache/XXXXXXXXX
you will see this file for each ejb.weblogic makes the hashcodes to zero after it recompiles
Note 2:
When you generate EJB using appc.generate them to a exploded directory using -output C:\myejb
instead of C:\myejb.jar.This way you can play around with the marker file
Step2.
Also you need a PATCH from weblogic.When you install the patch you see some message like this
"PATH CRXXXXXX installed successfully.Eliminate EJB recomilation for appc".
i dont remember the patch number but you can request weblogic for that.
You need to use both steps to fix the problem.The patch fixes only part of the problem
Goodluck!!
cheers
raj
the Marker file in EJBs is WL_GENERATED
Just to update the solution we went with - eventually we opted to recompile the EJBs once at the Customer's site instead of messing with the EJBs' internal markers (we don't want Oracle saying they cannot support problems derived from this scenario).
We created two KSH scripts - the first iterates over all the EJB jars, copies them to a temp dir and then re-compiles them in parallel by running several instances of the 2nd script which does only one thing: java -Drecompiler=yes -cp $CLASSPATH weblogic.appc $1 (With error handling of course :))
This solution reduced compilation time from 70min to 15min. After this we re-create the EAR file and redeploy it with the new EJBs. We do this once per several UAT environment creations, so we save quite a lot of time here (55min X num of envs per drop X num of drops)