Deployment failure upon certain conditions

[laurent_chavanis]

Hello,

Here is the context of my strange deployment behavior:

IDE 630 SP18

<u>ClientAPI (Java)</u>

SoftwareType : Library

provider.xml : Name : com.sap.sodis.client.ctsadapter

Reference Lib : webservices_lib

Reference Service : tc/wd/webdynpro

<u>ManagerUI (WebDynpro) :</u>

Need to call the ClientAPI so I have set

Properties --> WebDynpro references --> Library ref:

com.sap.sodis.client.ctsadapter

ClientAPI build : ok

ClientAPI deployment :ok

ManagerUI build : ok

ManagerUI deployment ko with the following error :

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

<i>[015]Deployment finished with warning

Settings

SDM host : NCED60124460A

SDM port : 50018

URL to deploy : file:/C:/DOCUME_{1/i023350/LOCALS}1/Temp/temp44636sap.com_tctmw_organizerui.ear

Result

=> deployed with warning : file:/C:/DOCUME_{1/i023350/LOCALS}1/Temp/temp44636sap.com_tctmw_organizerui.ear

Finished with warnings: development component 'tc/tmw/organizer/ui'/'sap.com'/'LOKAL'/'0.2006.10.11.10.53.48':

Caught exception during application startup from SAP J2EE Engine's deploy service:

java.rmi.RemoteException: Error occurred while starting application sap.com/tc/tmw/organizer/ui and wait. Reason: Clusterwide exception: server ID 3079350:com.sap.engine.services.deploy.container.DeploymentException: Clusterwide exception: Failed to prepare application ''sap.com/tc_tmworganizer_{ui'' for startup. Reason=Clusterwide exception: Failed to start dependent library ''com.sap.sodis.client.ctsadapter'' of application ''sap.com/tc}tmw_organizerui''. Status of dependent component: <b>STATUS_DEPLOYED</b>. Hint: Is the component deployed correctly on the engine?

at com.sap.engine.services.webdynpro.WebDynproContainer.prepareStart(WebDynproContainer.java:1421)

at com.sap.engine.services.deploy.server.application.StartTransaction.prepareCommon(StartTransaction.java:231)

at com.sap.engine.services.deploy.server.application.StartTransaction.prepare(StartTransaction.java:179)

.....</i><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

The strange thing is that when I remove the Service Reference tc/wd/webdynpro from the ClientAPI, the deployment of the ManagerUI works fine... Any idea ?

Thanks for your help and best regards,

Laurent

[Former Member · Accepted solution]

Laurent,

Any WD application has implicit reference to service tc/wd/webdynpro.

What you are doing is creating tree of references:

ManagerUI
  -> ClientAPI
       -> tc/wd/webdynpro
  -> tc/wd/webdynpro

Now, your WD application is executed in WD container. If WD container has been already started (i.e. ManagerUI is not the first application you are loading) then everything is ok and trivial. Isn't it?

Now, if you are starting ManagerUI it has to start WD container (including tc/wd/webdynpro service) and your library. Your library also initiates tc/wd/webdynpro service loading. At this moment this service probably is some semi-valid intermediate state (sorry for such term). Hence the error you see.

As far as I remember, referencing service from library is not recommended at all. Or even forbiden.

Valery Silaev

SaM Solutions

http://www.sam-solutions.net

[laurent_chavanis · Accepted solution]

Hello Valery,

Thanks for this explanation. However I wonder why it fails at deployment time and not at runtime.

Then I would like to have an advise on how to solve this problem. Shall I change the Library to a Service ? Is it easy to do it ?

Cheers,

Laurent

[Former Member · Accepted solution]

Laurent,

The question is why your library need reference to WD service? Could you remove dependency on WD classes (if any) from library?

Valery Silaev

SaM Solutions

http://www.sam-solutions.net

[laurent_chavanis · Accepted solution]

Hi,

In fact I want my Library to be able to open a WebDynpro application. The usecase is that any WebDynpro application that references this Library has an API to open a given WebDynpro application via openManagerUI(wdComponent), without taking care of the the name of the application.

Best regards,

Laurent

[Former Member · Accepted solution]

Laurent,

Actually, I'd create this in different way.

1. Create one DC (type WebDynpro) with WD utility classes, expose this utility classes via public part.

2. Use public part from other DCs (type WebDynpro)

3. Relief library from UI-specific code.

Valery Silaev

SaM Solutions

http://www.sam-solutions.net

[laurent_chavanis · Accepted solution]

Valery,

The Client Library was originaly created as a Deployable Proxy Project that exposes APIs to access an ABAP Backend via WebServices. As WD Application are using those Proxy APIs, it now also has to be enhanced with this WD feature to open a given WD Application.

Best regards,

Laurent

[laurent_chavanis · Accepted solution]

Hi,

I fact the 2 needed jars are:

webdynproservices.jar and

webdynproprogmodel.jar

I wonder if it is possible to change the Packaging to build it as a Service instead of a Library. Or is it possible to ship the jars directly in the Library to avoid the WebDynpro ref.

Cheers,

Laurent

[Former Member · Accepted solution]

Laurent,

Well, I've already explained working solution.

1. If you include JAR files in lib, you get ClassCastExceptions later -- same class will be loaded by different class loaders. Actually, this is a straigh path to class loaders mess.

2. Service is different from library. It has lifecycle, it can be started / stopped. It must implement certain methods to let WebAS control it this way. So you get more complex code with non-guaranted result.

Valery Silaev

SaM Solutions

http://www.sam-solutions.net