Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
BedrockMission!

Learn more

View all

Sign in to view all badges

SOLVED

AEM 5.6: Snaphshot bundles rejected by publish instance

Magicr
Level 3
Level 3

At the moment in my company does still exists some AEM 5.6 enviroments. One enviroment is used as a test system. The configured run mode of this is "publish.test.xxx". The problem with this one, it refuses to install bundles if those build as snapshot.

We've got an hint that we can change the log level for "autoinstaller" to TRACE so we can check what is going wrong.

Can some help me out what and how we have to configure it?

 

Thanks in advanced

1 Accepted Solution
vanegi
Correct answer by
Employee
Employee

Hello @Magicr,

Do you see any messages in the log related to the OsgiInstaller thread? Are you not able to see the changes particularly for a class or nothing is getting change. Kindly download the jar and see if you are able to the changes there in a decompiler. Worth would be to deleting the bundle from crxde and deploy again. If it's only for a specific class adding immediate = true might help.

 

In addition, please check if the same bundle with different version also present. If you replace a bundle "mybundle-1.2.3.jar" with a newer bundle, but the same version number (in the Osgi metadata), this new bundle will never be started, but it will be ignored.

You have to increase the version number of the bundle to make it work. In a development mode you can also use SNAPSHOT versions; and for these the situation is different. Installing a fresh mybundle-1.2.3-SNAPSHOT.jar will replace an already existing mybundle-1.2.3-SNAPSHOT.jar

 

After installing the latest version of the bundle, Go to [1] and check if the bundle is still mapped to the older jar file.

 

If yes, there might be something wrong with the OSGI installer. You can follow the steps below:

 

- Stop the AEM instance

- Go to <AEM_Installation_Directory>crx-quickstart directory

- Rename the launchpad to launchpad_bkp

- Start the instance and this should create a new launchpad folder. Wait for the instance to startup

- Stop the instance and delete the newly created launchpad folder

- Restore launchpad_bkp to launchpad

- Start the instance

 

[1] http://<host>:<port>/system/console/osgi-installer

 

Thanks!!

View solution in original post

8 Replies
ArpitVarshney
Community Advisor
Community Advisor

Hi @Magicr 

 

I'm not clear with the issue. Can you please confirm: 

 

  • You mentioned the issue in one test system. Is it working with the other 5.6 systems?
  • Is it happening only in publish instance or both author and publish?

Please share the relevant logs during that timeframe after changing the level as trace.

 

Regards,

Arpit Varshney

 

 

Magicr
Level 3
Level 3

It is not working only this one publish instance. The corresponding author enviroment does not show the same behaviour. Other AEM 5.6 instances either.

ArpitVarshney
Community Advisor
Community Advisor

Hi @Magicr 

It is not a version-specific issue. It is specific to your publish environment. Could you please check if you are replicating the package then is it not blocked in the replication queue? 

Also, verify whether this publish is stable before you install the package Verify http://localhost:4502system/console/bundles if all bundles are active or not and revert your recent changes(any content package or code changes) if any which are not present in another environment to confirm your issue.

 

Regards,

Arpit Varshney

Magicr
Level 3
Level 3
I know that it is not a version-specific issue. All bundles are active and bundles build without "snapshot" won't refused. So the same code with "snapshot" in package name will be refused, without this word it will be accepted (see my question). I want just know which file I have to edit and how so I can investigate this issue deeper.
vanegi
Correct answer by
Employee
Employee

Hello @Magicr,

Do you see any messages in the log related to the OsgiInstaller thread? Are you not able to see the changes particularly for a class or nothing is getting change. Kindly download the jar and see if you are able to the changes there in a decompiler. Worth would be to deleting the bundle from crxde and deploy again. If it's only for a specific class adding immediate = true might help.

 

In addition, please check if the same bundle with different version also present. If you replace a bundle "mybundle-1.2.3.jar" with a newer bundle, but the same version number (in the Osgi metadata), this new bundle will never be started, but it will be ignored.

You have to increase the version number of the bundle to make it work. In a development mode you can also use SNAPSHOT versions; and for these the situation is different. Installing a fresh mybundle-1.2.3-SNAPSHOT.jar will replace an already existing mybundle-1.2.3-SNAPSHOT.jar

 

After installing the latest version of the bundle, Go to [1] and check if the bundle is still mapped to the older jar file.

 

If yes, there might be something wrong with the OSGI installer. You can follow the steps below:

 

- Stop the AEM instance

- Go to <AEM_Installation_Directory>crx-quickstart directory

- Rename the launchpad to launchpad_bkp

- Start the instance and this should create a new launchpad folder. Wait for the instance to startup

- Stop the instance and delete the newly created launchpad folder

- Restore launchpad_bkp to launchpad

- Start the instance

 

[1] http://<host>:<port>/system/console/osgi-installer

 

Thanks!!

View solution in original post

Magicr
Level 3
Level 3
Thanks for answer. I will give the buttom way a try. An additional question: Which log file is assigned to the osgi-installer?
vanegi
Employee
Employee
Please check if you have any logging related to the osgi-installer in AEM error.log itself. If there are no such entries, you can enable a DEBUG level log on org.apache.sling.installer.core.impl.OsgiInstallerImpl api.
Magicr
Level 3
Level 3
I have tried the suggested way with bottom way and after that we could not repuduce the above behaivor any more (for the moment). Though, we will keep an eye on it. For the moment I marked your answer as accepted. Thanks for your help.