jar cannot be undeployed / deleted

[Former Member]

Hei !

As I am progressing through my sample application (EJB 3.0, Hibernate, JSF), I added also SLF4J with LOG4J to see some logs from Hibernate and to use my own.

I dont know yet, whether my NEW issue is is related to SLF4J/LOG4J or it is something general :

As I am redeploying my application .ear the ejb part of it stays locked on server and that way I cannot complete redeployment.

No matter what I do, it stays there (looked in deployment folder).

C:\usr\sap\CE1\J00\j2ee\cluster\apps\sap.com\EAR_PROJECT\orpersistence\jars

When I undeploy my application, whole project is gone but this file !

Only way to get rid of it is stoping/starting NW AS, which I find very wrong

Next time I deploy my .ear, it will deploy normally, but the same jar gets locked again !

I have seen very few words about similar issues, saying - no idea how to fix it !

Is there any lucky who has seen a solution to such problem ?

Caused by: com.sap.engine.services.orpersistence.container.deploy.ActionException: [ERROR CODE DPL.DS.5030] Clusterwide exception: java.io.IOException: Cannot delete file: C:\usr\sap\CE1\J00\j2ee\cluster\apps\sap.com\EAR_PROJECT\orpersistence\jars\XXX.jar
	at com.sap.engine.services.orpersistence.model.builders.FileUtils.deleteDirectory(FileUtils.java:188)
	at com.sap.engine.services.orpersistence.model.builders.FileUtils.deleteDirectory(FileUtils.java:184)
	at com.sap.engine.services.orpersistence.container.util.FileUtils.deleteDirectory(FileUtils.java:137)
	at com.sap.engine.services.orpersistence.container.deploy.impl.ConfigurationsExtractor.execute(ConfigurationsExtractor.java:59)
	at com.sap.engine.services.orpersistence.container.deploy.ContainerAdapter.downloadApplicationFiles(ContainerAdapter.java:332)
	at com.sap.engine.services.deploy.server.editor.impl.second.DIReaderImpl2.bootstrapApp(DIReaderImpl2.java:627)
	at com.sap.engine.services.deploy.server.application.ApplicationTransaction.bootstrapApplication(ApplicationTransaction.java:787)
	at com.sap.engine.services.deploy.server.application.StartInitiallyTransaction.bootstrapApplication(StartInitiallyTransaction.java:231)
	at com.sap.engine.services.deploy.server.application.StartInitiallyTransaction.prepare(StartInitiallyTransaction.java:134)
	at com.sap.engine.services.deploy.server.application.ApplicationTransaction.makeAllPhasesOnOneServer(ApplicationTransaction.java:420)
	at com.sap.engine.services.deploy.server.application.StartTransaction.doStartInitiallyGlobal(StartTransaction.java:449)
	at com.sap.engine.services.deploy.server.application.StartTransaction.doStartInitially(StartTransaction.java:437)
	at com.sap.engine.services.deploy.server.application.StartTransaction.prepare(StartTransaction.java:178)
	at com.sap.engine.services.deploy.server.application.ApplicationTransaction.makeAllPhasesOnOneServer(ApplicationTransaction.java:420)
	at com.sap.engine.services.deploy.server.application.ApplicationTransaction.makeAllPhases(ApplicationTransaction.java:445)
	at com.sap.engine.services.deploy.server.application.ParallelAdapter.super_MakeAllPhases(ParallelAdapter.java:337)
	at com.sap.engine.services.deploy.server.application.StartTransaction.makeAllPhasesImpl(StartTransaction.java:550)
	at com.sap.engine.services.deploy.server.application.ParallelAdapter.runInTheSameThread(ParallelAdapter.java:251)
	at com.sap.engine.services.deploy.server.application.ParallelAdapter.makeAllPhasesAndWait(ParallelAdapter.java:392)
	at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3389)
	at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3375)
	at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3278)
	at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3251)
	at com.sap.engine.services.dc.lcm.impl.J2EELCMProcessor.doStart(J2EELCMProcessor.java:99)
	at com.sap.engine.services.dc.lcm.impl.LifeCycleManagerImpl.start(LifeCycleManagerImpl.java:62)
...

[Former Member]

Logging jars obviously has to be delivered with Hibernate libraries, otherwise they are not visible.

Question remains - why SLF4J is locking my application jar ?

Even when referenced project with hard-ref libraries (hibernate, logging, etc) is fully undeployed and main application is undeployed, this jar remains alone and "locked by another application".

As I understand jars are locked, when some application classloader has loaded classes from it ?

Or is there other reasons to lock jar files ?

[Former Member]

I have some news here !

The jar gets locked because of log4j.properties file in it !

If I remove it from there, jar will be freed up very well.

I decided to try bit different approach, I moved this file from main applications ejbs&stuff.jar to a supplementary jar, which I created for Hibernate Transaction Manager Lookup class (read for example here http://seamframework.org/Documentation/RunningSeamBookingExampleWithSAPNetweaverCompositionEnvironme....

I am supplying this jar (class) together with my hard-ref libraries in separate ear project (as suposed), together with hibernate, logging and other related jars.

So far I see my logs in file as expected and my main project is totaly deployable/undeployable.

Unfortunatelly the HiberManagerLookup.jar together with log4j.properties file in it becomes locked

As a result I have moved my problem a litle bit aside, but not fixed it.

As well I am finding provision of log4j properties in hard-ref project totaly wrong, it is main project resource, not a shareable thing.

Only good thing about it - until fixed, I can work more comfortably on main project, hard-ref project does not get changet a lot, except logging properties themselfe become fixed.

Problem still remains

Edited by: Aziris on Jan 21, 2011 10:57 AM

[Former Member]

I just tried out one more thing

- I removed slf4j-api(1.5.8), slf4j-log4j(1.5.8) and log4j jars(1.2.14) from application

As a result:

-I get ClassNotFound, but thats no surprise

-the problematic jar is no more problem - its freed up and undeployed as it should be

Next I put jars back and what you know - particular jar gets blocked again !

So, as I know at least direction where to look, I have to consider what could be wrong !?

I suspect the problem to be in fact, that I am delivering those 3 logging jars not with my main application ear, but instead with another ear, which delivers hard-referencable hibernate libraries.

Could that be wrong ?

I heard somewhere, that NW AS has its own built-in logging mechanism (no idea what that could be), there for I decided to deliver these libraries :

1. on safer level, to be sure, that these get loaded

2. how about Hibernate classes using Logger - I am not sure a which moment they will look for implementation, will my jars from main EAR/lib be available at that moment ?

I am going to try it any way - at the moment this is anyway a guess/try game form me...