Community
Participate
Working Groups
Build Identifier: I20101208-1300 My Source container derives from CompositeSourceContainer and I need aaccess to this member. Addding a setter for this meember is OK with me too. Reproducible: Always Steps to Reproduce: NA
The class has been designed to be create once and not change afterward, so I'd be reluctant to change that assumption since there is a lot of multi-threaded access done for source lookup. Although obviously the containers member initialization is not synchronized properly. Could you just write your own to sub-class with proper synchronization?
(In reply to comment #1) > The class has been designed to be create once and not change afterward, so I'd > be reluctant to change that assumption since there is a lot of multi-threaded > access done for source lookup. Although obviously the containers member > initialization is not synchronized properly. Could you just write your own to > sub-class with proper synchronization? Are you saying that I should treat my container deriving from CompositeSourceContainer as kind of immutable object, once createSourceContainers() is called? In that case I need to remove my container from its director/container, create a new one, move over all children, make sure dispose() is not call on them. Sound complicated for the simple set to null task I have. Can instead we just have removeAllChildContaniers() that will NOT call dispose() on the children? It will have the same synchronization as dispose().
(In reply to comment #2) > Are you saying that I should treat my container deriving from > CompositeSourceContainer as kind of immutable object, once > createSourceContainers() is called? In short, yes. I didn't design it this way, but it does appear to be so. > In that case I need to remove my container from its director/container, create > a new one, move over all children, make sure dispose() is not call on them. > Sound complicated for the simple set to null task I have. > > Can instead we just have removeAllChildContaniers() that will NOT call > dispose() on the children? > It will have the same synchronization as dispose(). I'm reluctant to change this basic aspect of the class's design because it is a public API and I wouldn't want anyone to be able to start calling the remove method on the standard containers that we have (project, default, etc.). Maybe I'm being paranoid :-) Do you have to subclass this class for your use case (it's < 100 loc)?
> Do you have to subclass this class for your use case (it's < 100 loc)? OK. I give up. I'll copy the class locally... or use reflection for now. You can reject the bug.
(In reply to comment #4) > > Do you have to subclass this class for your use case (it's < 100 loc)? > > OK. I give up. I'll copy the class locally... or use reflection for now. > You can reject the bug. I don't mean to be difficult. I'd be more open to creating a new (MutableCompositeSourceContainer) along side the existing one if we have a use case for it in open source.
