Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 73366 invoked by uid 500); 24 Jul 2001 17:28:40 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 73353 invoked from network); 24 Jul 2001 17:28:40 -0000 Message-ID: <3B5DB02C.A78933A0@apache.org> Date: Tue, 24 Jul 2001 13:28:12 -0400 From: Berin Loritsch X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [Fwd: bug 2737 still exists...xsp compilation package] References: <20010724170116.39534.qmail@web12805.mail.yahoo.com> <3B5DAC8E.15158B39@apache.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms7D8D6163CB3C220849D197B1" X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N --------------ms7D8D6163CB3C220849D197B1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Berin Loritsch wrote: > > > For example you have two subsite maps "test1" and > > > "test2".. > > > > > > 1. Have same pattern and same src path in xmap's of > > > both sitemaps > > > > > > 2. But the content of the xsp served is different. > > > > > > 3. I anticipate both xsp to be compiled into different > > > packages based on sitemaps and result in separate > > > content.. Here is what I am seeing: /sitemap.xmap /test1.xmap /test2.xmap /index.xsp In test1.xmap (mounted at "foo/") Same thing is in test2.xmap (mounted at "bar/") In this scenario BOTH subsitemaps are pointing to the same resource--literally. If it is altered: /sitemap.xmap /foo/test1.xmap /foo/index.xsp /bar/test1.xmap /bar/index.xsp With the same content in the sitemaps, they are pointing to different resources--logically and literally The disconect is what the guy is "logically" expecting may be different from what is actually happening. In the first example, the FQCN _should_ be: org.apache.cocoon.www.sitemap_xmap org.apache.cocoon.www.test1_xmap org.apache.cocoon.www.test2_xmap org.apache.cocoon.www.index_xsp In the second example, the FQCN _should_ be: org.apache.cocoon.www.sitemap_xmap org.apache.cocoon.www.foo.test1_xmap org.apache.cocoon.www.foo.index_xsp org.apache.cocoon.www.bar.test2_xmap org.apache.cocoon.www.bar.index_xsp If this is not happening, then we need to ensure that it does happen. In the cases where the resource is outside the context directory, the final package name should be something like this: org.apache.cocoon.www.C_.other.directory.test3.xmap if the resource was in C:\other\directory\test3.xmap --------------ms7D8D6163CB3C220849D197B1 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIHuQYJKoZIhvcNAQcCoIIHqjCCB6YCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BbMwggKCMIIB66ADAgECAgMFCRYwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTA2MTUxNjUzMjVaFw0wMjA2MTUxNjUzMjVa MEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIzAhBgkqhkiG9w0BCQEWFGJs b3JpdHNjaEBhcGFjaGUub3JnMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwxH1hC75i euMrpOenvB+9dwW+gfWfdRajqlrXgYmMSDuzgWAEMW1dPs2ID7M59eZ259We5f1k7wpLOh3+ kHVTQJpqXB8PP27RKby8sA+pZdxmpTBV7LOlmFoYKNxE/Wzgu65+07TFMTreDsjDFu5R/sli zRxfaIGQBBA/52i/lwIDAQABozEwLzAfBgNVHREEGDAWgRRibG9yaXRzY2hAYXBhY2hlLm9y ZzAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBALe83A1HaeohQl3/fjj6Rwrb3yee wQuf0ponSJSaPsuzHbcQ+qBm6JbchGdjtetdv9O+aD1hcfmBC4n0TCmU3RfZq95OQoxgQBAm +dcuJGZIe8VvegsP/F6wZjnvquFJsCC00uGZsUjssu0WMj7x68QbqM7xXMq3yTtj/8DZtm0y MIIDKTCCApKgAwIBAgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEk MCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxw ZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIz NTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8 +tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tew kd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYD VR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5J x+gNu4+5DWomKmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0G Z/VQby5YuLYLwVBXtewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3p YgNIMYIBzjCCAcoCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0 aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAu OC4zMAIDBQkWMAkGBSsOAwIaBQCggYowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDEwNzI0MTcyODEzWjAjBgkqhkiG9w0BCQQxFgQUnxzhKPrKxluT/PHI sdNwJcUilqQwKwYJKoZIhvcNAQkPMR4wHDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYJKoZIhvcNAQEBBQAEgYAnaDXiL9Ui7ZwtaPiPDx3WdZnwAE/R+ZV0fAkJ/X9wYKhIFfQB OeXEJn/A+VMJ/2feaxekWK/oK2d9mZeMbTvCGGO7XFC6QHfhTN9dNonfX+9ogeiu1E7gT1fY cG3NBqqTaH1ZLvZsDAwZnzq78jRRJjVwsmkSF2NVBm/grgs8OA== --------------ms7D8D6163CB3C220849D197B1--