I have a web app using yuicompressor running on glassfish
however, when I run maven clean, I have the following error
Failed to delete C:.....\target\YUI-1.0-SNAPSHOT\WEB-INF\lib\js-1.7R2.jar -> [Help 1]
it is a bit strange, because if I deploy the app into tomcat, then no problem deleting the file
how to force glassfish divorce rhino?
Almost certainly some process is hanging on to the file.
Get handle.exe [1] and run it like so:
handle js-1
It should show the process.
Another way to check it out is to copy & paste the filename and delete it yourself manually. If YOU can't delete it, neither can maven or GlassFish.
[1] http://technet.microsoft.com/en-us/sysinternals/bb896655
Related
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
I tried to follow the war generation instructions by changing the warName in build.gradle to moqui-plus-runtime.war and running gradle addRuntime and then gradle deployTomcat. There were no errors in the war build and I checked to see that the war file got installed as ROOT. I did not make any other changes (still using MoquiDevConf and I already had other system parameters in MoquiInit.properties.)
When I startup tomcat8, I don't see any errors in the log file and it says that it is loading moqui-plus-runtime, but when I make any request in the browser, the localhost_access... log shows 404 for any request.
Can you tell me what things I might of missed or how I would go about debugging this - there is very little info in the log files other than the 404 messages.
I followed the following steps to deploy to a Tomcat instance on the same machine. This is from memory as my production machine is currently offline for the next couple of weeks.
Edit tomcatHome to point to correct location
I personally run a gradle cleanAll first to remove old WARs etc
Run gradle build
Optionally run gradle loadProduction to load the production database, alternatively you can run java -Dmoqui.conf=conf/MoquiProductionConf.xml -jar moqui-1.5.3.war -load -types=seed,seed-initial so that you can pick which data types you want to load into production etc.
Stop Tomcat from running, probably optional but the next step deletes files & folders from a deployed tomcat instance.
Run gradle addRuntimeTomcat this task adds your runtime and also copies over the completed WAR into the Tomcat webapps directory if you set the location correctly in step 1.
Start Tomcat
Check Tomcat logs for any startup errors
Hope this helps
I have a Maven project which generates a 413.06 KB jar file. I have to deploy it on Apache Archiva based managed repository. I have tried to deploy different versions, and it created required layout and structure, uploaded some files, even it uploaded that jar with 200~ KB. every time the jar file size changes but always it fails to upload 413.06 KB jar file.
Information:-
I am running standalone Archiva
I have given guest account to Global Repository Manager & "Repository Manager - MYREPO"
I have also tried a separate account in Archiva with "Repository Manager - MYREPO" rights and configured it in maven's settings.xml file to set custom timeout.
I am getting following error
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy
(default-deploy) on project SharedshelfRepository: Error deploying artifact: Transfer error:
The server did not respond within the configured timeout. -> [Help 1]
that might be maven-deploy-plugin issue, resources plugin itself needs several dependencies,try manually jar nad p
What version of Maven are you using? You might try 3.0.4 as it has a different HTTP library. I'm also not sure if there's more context for what was happening when it timed out (it seems more request oriented rather than deploy oriented, and deploy does request some metadata).
I can't see that you'd need to alter the timeout, as none of the defaults should apply to such a small file. How long does it take to fail?
I just downloaded the free trial of Bamboo continuous integration server, and created the first plan with nothing but downloading the source code from the git. I have a local git repository on the bamboo machine so the git URL is pointing to a local path.
The problem is that when I run the job, it never finishes even after waiting for an hour. This is the last lines of the activity log:
07-Apr-2011 20:03:23 Checking out revision f9dc82500914333ed4bbdae5ed038771fd658c3c.
07-Apr-2011 20:03:23 Creating local git repository in '/home/bob/bamboo-home/xml-data/build-dir/DEV-DEV-1/.git'.
From the shell I can go to the directory shown in the log and see that the source code were cloned correctly to the bamboo working directory. But the job will never finish and the log will not have any more update from here. I have to manually terminate the job. Any ideas? Do I miss something?
Just a guess, since the Bamboo instance we have at work pulls from Accurev and not Git, and I've never run into this problem myself - but it may be hung because there isn't a builder defined for that plan. You might try defining a builder (even if it's one that you know will fail) just to see if it makes it to that next step.
I had very similar problem.
It's not very original solution but I just uninstalled bamboo and installed it again.. Now it works now
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)