Expand my Community achievements bar.

Learn about Edge Delivery Services in upcoming GEM session
SOLVED

Re-writing the MANIFEST.MF in META-INF

Avatar

Level 2

Hi

Given that we have MANY instances of AEM auth / pub in our environment across  a LAB/ DEV/ QA/  UAT / PROD environment I have to manage many war file to deploy.  (Our firm adheres to the .war deploy that remain packed not exploded.).

to save space in managing many 500 meg wars in our source etc I am looking at break the war file into project (some in source some not.. like 'resources') and having the MANIFEST.MF re-written to refer to the jar/zip/classes remotely on another server.

The technology in our firm supports this no problem but I"m curious if AEM will given that the manifest / jar is signed and such.

So my question, can I re-write the manifest so it builds the class paths in a format the containers in my firm will support and still allow AEM to startup as normal? Or is there some 'hook' that checks the signage / SHA of the jars and will abort if not what's expected.

Thanks.

(Just for the record I am trying to get approval to explode the war and making everything in our env point to 'resources' as a symlink and our instances just push out a web.xml with the appropriate settings for each environment... not there yet.)

-

John

1 Accepted Solution

Avatar

Correct answer by
Level 10

You can rewrite & surely get a approval. You need to break signing also in MANIFEST.MF

To avoid breaking instead you should be able to define a servlet parameter / context parameter etc.... prior or during initial deployment in the web.xml parameter. Our documentation is pending on this. The internal reference number is DOC-3459

View solution in original post

1 Reply

Avatar

Correct answer by
Level 10

You can rewrite & surely get a approval. You need to break signing also in MANIFEST.MF

To avoid breaking instead you should be able to define a servlet parameter / context parameter etc.... prior or during initial deployment in the web.xml parameter. Our documentation is pending on this. The internal reference number is DOC-3459