Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <5FC45A62-B083-4433-99AF-8265D2FEB90F@wimpi.net>
From: Dieter Wimberger <dieter@wimpi.net>
To: dev@felix.apache.org
In-Reply-To: <87eb8aee0806280040w775220e5kad711d64d514b032@mail.gmail.com>
Content-Type: multipart/signed; boundary=Apple-Mail-4-410904106; micalg=sha1;
 protocol="application/pkcs7-signature"
Mime-Version: 1.0 (Apple Message framework v926)
Subject: Re: General questions about starting and stopping bundles
Date: Tue, 1 Jul 2008 14:41:45 -0500
References: <3D07940C-36D8-4E9E-B96C-C709B6223D49@wimpi.net>
 <87eb8aee0806280040w775220e5kad711d64d514b032@mail.gmail.com>

--Apple-Mail-4-410904106
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Alin:

> The specs does not mandate this but I see it as a best practice when
> the start method does not return in a "timely manner". Having this
> thread also means that you must take care to stop the thread during
> BundleActivator.stop as it can be that stop is called before your
> starting thread ends.
>

You are making a good point here, except that I think that "stopping"  
is maybe not a good choice.
Actually it's not recommendable to stop threads at all, it is a thread  
primitive that has been deprecated a while ago:
http://java.sun.com/j2se/1.3/docs/guide/misc/threadPrimitiveDeprecation.html

However, it may make sense to handle this case, and maybe to join the  
start thread before proceeding with a stop.

As a side note, I always found it semantically strange to have  
"starting" and "stopping" as states (4.3.2 Bundle States), rather than  
"transitions".


>>
>> Stopping:
>> Knopflerfish seems to assume that when a bundle is stopped, the  
>> framework
>> should be taking care about unregistering services.
>> (See "Automatic cleanup of services")
>>
>> Is this generally valid or container dependent?
>
> This is mandated by the core specs (section 4.3.6 on specs 4.0.1).
>
>> Also, does this also apply to Listener instances (like for example a
>> ServiceListener) and service references that are being used?
>> I.e. is there a need to call BundleContext.removeService/ 
>> FrameworkListener()
>> or m_BundleContext.ungetService() for cleanup?
>
> In principle you should "undo" what you did during start, so release
> resources, stop started threads, ...

Good point, with the same exception as above (stopping threads may not  
be a good idea).


> There is no need to unregister services registered during startup or
> framework listeners because they will be cleaned up by the framework
> after the stop method returns. Also, any services used by the bundle
> being stopped will be released automatically by the framework.
> But recall that other bundles that still have references to your
> service will still be able to call your service so you may wanna play
> defense and handle this case even if I consider this a programming
> error from the point of view of the bundle that still uses the service
> even if the service has been unregistered. When I wanna do that I
> usually implement the service using a state service and by the moment
> the bundle is stopped or the service s unregistered I change the
> internal state of the service to stopped, state where I throw an
> meaningful exception. But is a lot of work in plus that does not bring
> real value to your service, it only helps the developer of the bundle
> that is still using the invalid service to think about the fact that
> he should not use anymore the service after it has been unregistered.
>

I usually try to design the use of other services in a way that allows  
"come and go". i.e. using a mediated reference instead of obtaining  
one and holding it; and kind of doing request/response transactions.

However, I have come to the conclusion that if state needs to be  
maintained between calls to a service, then it is actually much more  
complex to handle (and design for) the "come and go" situation.

Regards,
Dieter


--Apple-Mail-4-410904106
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGRDCCAv0w
ggJmoAMCAQICECcbNonIuyoFmlfrD6CU/vIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDExNTE5MjcwN1oXDTA5MDExNDE5Mjcw
N1owQjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEfMB0GCSqGSIb3DQEJARYQZGll
dGVyQHdpbXBpLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKXikeSvGCZqXLtR
Q+GQDBa7XsiJ5M0iYY0y72InsqSMjf7WTea9hyVvtmI4SSih2IwbbxLKbOWpUoT402ykFqyefp45
IRGYHtVVcWfQaTrlgYI3Lg26vV7x4tu6OeOFCsyNRZWST+UAhFKBTWBEyBVER7sQqYoXsJxMXiy7
NblQt+Tdk191j+GunLyk6uONUk0y9CKH4jZWSAnH7U+9/hypcz/brafGZDirOGxgLpa+UunFIWug
eEQr5wUl9nRvwaOq+h7jH7CMRgSR9SEFdUTme1SecvJw6zjddZbycE5BsQ1PlUDu7reJ7a/rbDoV
Pvus2NXKif16Ay1cZ9S8dcMCAwEAAaNQME4wDgYDVR0PAQH/BAQDAgP4MBEGCWCGSAGG+EIBAQQE
AwIFIDAbBgNVHREEFDASgRBkaWV0ZXJAd2ltcGkubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN
AQEFBQADgYEAl/ltcLtdG2CqwoAG4531Xu0oPzjRQNmQfwK9Ow5WmxjiSlTzZO3jFz5/3IgeDo7/
LP0rdik27gY9fApo3oZrF3XaqKtGO8Iw7QHXBvBKIN/Tj1f9zelNTCcUllA0m2CxAYedHPfTSyX2
XIP7Xpj82jCYIAkQfXv+T2c8tX+Xo+owggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHR
MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24x
GjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp
Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkq
hkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcN
MTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg
KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0Ew
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb
8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9
A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYD
VR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20v
VGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx
GjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2j
ZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4l
UJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9d
X2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp
bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg
Q0ECECcbNonIuyoFmlfrD6CU/vIwCQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwNzAxMTk0MTQ1WjAjBgkqhkiG9w0BCQQxFgQU0ykN7rbm
BjpceAyxrfMhXJKCdR4wgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG
cmVlbWFpbCBJc3N1aW5nIENBAhAnGzaJyLsqBZpX6w+glP7yMIGHBgsqhkiG9w0BCRACCzF4oHYw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq
BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAnGzaJyLsqBZpX6w+g
lP7yMA0GCSqGSIb3DQEBAQUABIIBAESIDK85W7aR/9ZcyhCmycr7dBcJojmpvPHY5bgmK+PCiFtX
a9P0z5dS3KQd8Ra03+hfQYl7biZA2Va14hJclQOH1bAnO+qOPKm/rxMzcsdEvRchGwrRVVVSsiEd
lC/Tc8VL5f4x+tLDgMuMgf8IRkyzHrr1FxLsMv97S67uAMXbWpbongn1QdLWDBvZjkVYeYg6LKJj
O1xDLGnByf0aVziN9pzOlHhgwhvd20UDUHGtk7Dq3i3XotjabuKvXhM/qze2jZuAPRpcd0dfcSi6
5uGZHm2oaFvCOnyoQCXGdhc/TdQZTObSK9CbFYT0dOiTayZ7jkFQy0Lc0TqbpzhcodkAAAAAAAA=

--Apple-Mail-4-410904106--