Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 11091 invoked from network); 31 Mar 2004 12:28:34 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 31 Mar 2004 12:28:34 -0000 Received: (qmail 59738 invoked by uid 500); 31 Mar 2004 12:28:27 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 59678 invoked by uid 500); 31 Mar 2004 12:28:26 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 59649 invoked from network); 31 Mar 2004 12:28:26 -0000 Received: from unknown (HELO l3dns1.vnu.co.uk) (62.140.213.135) by daedalus.apache.org with SMTP; 31 Mar 2004 12:28:26 -0000 Received: from [10.11.155.41] (155-41.static.int.vnu.co.uk [10.11.155.41]) by l3dns1.vnu.co.uk (Postfix) with ESMTP id 20AEF29C80 for ; Wed, 31 Mar 2004 13:28:26 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <019601c41710$7b20f6d0$0801a8c0@lagrange> References: <019601c41710$7b20f6d0$0801a8c0@lagrange> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-10--650310285; protocol="application/pkcs7-signature" Message-Id: From: Pier Fumagalli Subject: Re: [Kernel2.2] Comments Date: Wed, 31 Mar 2004 13:28:24 +0100 To: dev@cocoon.apache.org X-Mailer: Apple Mail (2.613) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N --Apple-Mail-10--650310285 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 31 Mar 2004, at 12:08, Leo Sutic wrote: > Nice work! Thanks > Some quick observations: > > 1. @author VNU Business > Publications > Is this OK with Apache and VNU? Defintely OK with VNU (if someone visits our site because of a click on the JavaDOC, and then come back, we got one more customer... If you guys don't want to see it in there, you can remove it no problems... It is in my default Java class template. > 2. Wire.java > /** > *

Check wether the wire between this {@link Wirings} instance > and the > * original component is still active.

> * > *

When this method returns true all methods called on > this > * instance will be forwarded to the original component instance > associated > * with this wire.

> > You cannot guarantee that. The instance may be redeployed between > the call > to wired() and the next call. > > No point in having a method whose return value means nothing. This method will return true until the block instance will not be destroyed or replaced by the Deployer, and when this method returns false, whoever got this wire should release it and acquire a new one (which will be got from the new block instance). Rember? The idea is never to completely remove blocks until forced to, so the Wire instance will still work even if wired() returns false. The wire will only be deactivated by either a call to release() or dispose() or by a forceful destruction by the deployer. > 3. Component.java: > /** > *

Contextualize this {@link Component} component instance with > the > * {@link Wire} through which its caller is accessing it.

> * > * @param wire the {@link Wire} instance associated with this > instance. > */ > public void contextualize(Wire wire); > > Does this mean that each component instance only has one wire? I.e. > only one client? You may end up with a lot of components if you > have > > component A depends on B, C, D, which depends on E, F, G, H... > > Wouldn't it be better to keep this as a ThreadLocal variable that > can > be accessed by the component? Then you can have multiple clients, > but only one client per calling thread (which seems like a > reasonable > tradeoff). Yes, each component instance has only one contextualized wire, because that instance is its own wire as it is returned to the caller. The JavaDOC goes in quite a lot of details on why this is done, and provide some examples. > 4. Wirings.java > > Talks about ((Wiring)myObject).release(); > Should be ((Wire)myObject).release(); > > #include Fixed. > 5. Configuration.java > > public class Configuration extends ArrayList > > I'd use composition instead... ??? extends AbstractList ??? > 6. Parameters.java > > Get rid of this one. Why can't components accept a hierarchy of > configuration nodes as configuration data? No... Parameters are typed and the framework checks the type of each parameter. One of the parameters CAN be a configuration on the other hand if in its descriptor the block requires: Other typse might be: ... The framework will check that parameters required by the block are available (specified before deployment) and of the correct type... So Configuration is MUCH more restricted than Parameters. > 7. Configurable.java > > Should accept Configuration instead of Parameters. Being able to > send in a tree-structure of config info instead of a flat list is > useful. From the "Configurable" javadoc: Note that a Parameters parameter can contain an entire Configuration tree, nullifying the requirement of a configuration method using a Configuration > 8. Block.java > > Love it. It's the core. > 9. Identifier.java > > * >

protocol://location/path/major.minor(.revision)?

> > Does this mean that all Blocks are automatically mapped into a URL > space? All blocks have a unique identifier. And this list agreed that each block identifier will assume the requirements specified in the Identifier interface. Pier --Apple-Mail-10--650310285 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwttIjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMTA3MDE0MjIwWhcNMDUwMTA2MDE0MjIwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRwaWVyQGJldGF2ZXJzaW9u Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMC/E+M4UqeEBnSTj0AIMX9oMWSo 9Te7VUPPvINPSKKLEElGaottQeJaYRSlfGIjUyXkzTlbw0MFAPaqfU97t+5xeNkighKu7ZcVIPfz AARv5+wp+gON5uSNV2GzP0rPwAbUDIG2zaSonJlN7whVG5fO9G1u0oYaWolpgKUAc3T5P5Gv737L G1iSxrnl9DQlVDIuZWrcgWYX/MFFlf7prXXm6lS08lYhGi0NrIf5SploZzMG+uHHzVDgV8WCTQr1 hXB825VLhnWw4GPFx5qLVgElctVz88S/+t8O/+1kRf3ky8SsewfyCTuDAk4XHzfb7M5bECiZ1yni dhW+sD1y/TsCAwEAAaMxMC8wHwYDVR0RBBgwFoEUcGllckBiZXRhdmVyc2lvbi5vcmcwDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAjeSEnk3U1P46rHiBGJP7StkQg/DVkw4ModEYCEwxm 8QYxQPGMciXn2goZ5ahK6Uu8Rfa+ZPSxV96VFsOlc3oFF02VYsrRy+xJukuSMY0z/0UvHnTZmVfm CJpxMoVMYQO3fC2XdmCNASu8FbvOgaS71fQf3b0wgebLeLROR7u5XjCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDC20iMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMzMTEyMjgyNVowIwYJKoZIhvcNAQkEMRYEFJ+I yjut44zDPoICi6ycaurKnlZ4MHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLbSIwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDC20iMA0GCSqGSIb3DQEBAQUABIIBAB5c JRPRqXw8mYUrpvW7olXmZpDR+zVOy0QcCMggOHWmxKKCu7sWEpjk1puJOLaYF9QIPPM54XgvtsQk FGIlxsMOhWCqVTRYKxir19oefMo2HqhUSuk01BduLiMT+Iy40/+nSJuDruoCHECnaT71LqmeLCq4 AQaP6mEuSHGUEw6fWCqhNnKgfsWqrPCiWUtPdbme7c1KC6vyCA39MNJoa1pHWX4XCn+Rwg+Xgn4q n+FcfOOGrkIfh2oAGLGr+OeAlRDUlWZLw5xFguBklIobtXo5xd2dYgcjuHDmiRMwUI9KVaQrvr9O l70xlPyep5NfE5L4TO4EaScy8QP2hw5FBakAAAAAAAA= --Apple-Mail-10--650310285--