Community
Participate
Working Groups
When I was porting some application to Virgo I encountered this assert org.eclipse.virgo.nano.serviceability.Assert$FatalAssertionException: input packageImports must not contain duplicate items at org.eclipse.virgo.nano.serviceability.Assert.isNull(Assert.java:103) at org.eclipse.virgo.kernel.userregion.internal.importexpansion.AbstractTrackedPackageImports.convertImportedPackageListToMap(AbstractTrackedPackageImports.java:323) at org.eclipse.virgo.kernel.userregion.internal.importexpansion.BundleTrackedPackageImports.getInitialImportedPackages(BundleTrackedPackageImports.java:58) at org.eclipse.virgo.kernel.userregion.internal.importexpansion.BundleTrackedPackageImports.<init>(BundleTrackedPackageImports.java:43) at org.eclipse.virgo.kernel.userregion.internal.importexpansion.StandardTrackedPackageImportsFactory.create(StandardTrackedPackageImportsFactory.java:37) As I understood, some bundle was containing a duplicate import package but the assert message didn't provide any useful information which a concrete bundle disturbed Virgo to launch my application. I spent a very lot of time checking every bundle in the user repository, then checking every included jar in every bundle in the repository. Totally, I have rechecked about 230 bundles. Finally, I have found included log4j.jar is containing the duplicate package import. After all these torments I dare to express that you applied the assert very very inappropriately 1) An assert can't provide any useful information about where is an data source of an error 2) Most existent legacy 3rd party bundles contains critical errors and inaccuracies in bundle manifest headers and my situation might occur frequently 3) MANIFEST.MF is a human related format that can be edited manually that is why this format is error-prone one and errors into it is a normal development situation and is not the assert exception of the server On the basis of the aforesaid I want to draw conclusions 1) MANIFEST should be parsed with a detailed report about all encountered errors and their locations 2) Virgo should try to fix any negligible errors and inaccuracies automatically without some critical halts 3) The duplicate import is not an assert or exception or error at all. It is just careless redundant information that should maximum cause a warning in logs and nothing else.
Thanks for raising this. I agree that Virgo should issue a warning event log message and ignore imports which are exact duplicates. If there a package is imported multiple times with different directives/attributes, then the fix up is less obvious. We should probably issue an error event log message in this case and either fail the deployment in question or include detailed information about the duplication and what is being omitted in the error log.
