There needs to be a standard way to assess all the available flyweights. So basically each design pattern needs its own config (coz you may not want to assert on ALL available instances).
The above would inject bytecode into all available constructors to register them to the instance registry.
Your idea of <core:factory method="getInstance"/> is a very good one too and can easily be dropped in this way.
Im getting the feeling JO is beginning to look like a dependency-injection framework!!!
Ok, for flyweight, we can config an equals comparator similarly (though it shouldnt be necessary as Object.equals() is pretty standard). I am thinking it would be valuable to be able to use an <object-state> assertion from within the design pattern too?
Or maybe that's something to worry about when defining new design patterns testers...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1. "Inject bytecode into all available constructors" - this seems alittle accessive probably need them to declare all classes they want to make the assertions or make individual pattern state declarations for each class. The issue is how do you define all available constructors?
2. Definately need to be able to define the equals comparator via some attribute of each class configuration.
3. Object-state assertions within an design pattern element has value probably but definately something to add after we get some patterns actually hammered out :P
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm going to start another forum for fine grained xml structure discussion. So we can dicuss the symantics of the pattern testing here and then the syntax else where. I know they will be inner dependent but we just have to get a starting point for the xml structure.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
yea well if we dont inject into all available constructors there's no way to guarantee that all instances are tracked. Anyway there is a support method (called something like supportInstanceRegistration()) which automatically does this work for us. We can reflectively determine all the constructors for a class (except superclasses) which is what this support method does anyway.
We could make this optionally explicit, but I always find less verbosity out of the box is better.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i was thinking about only injecting code into the constructors into the classes which were designated as flyweights. Maybe i miss interperted you i thinking you wanted to inject code into every class available on the class path?
Also if the supportInstanceRegistration() method in AspectJ rt api's???
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
oh no I only meant instrumenting the flyweight candidates, everything on the classpath would be a nightmare!
RuntimeInstanceRegistry.supportInstanceRegistration() is a method I added that uses InstrumentUtils to instrument constructors with a static call to the JO ObjectsBackplane passing themselves in. The registry stores objects into a set based on their identityHashCode (so a class that overrides hashCode() and has two equal instances will still be treated as having 2 separate instances). This might be something we want to make optional based on the pattern's configuration?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Looks like supportInstanceRegistation maybe be good enough. Basically it inserts before the other code the construtor (correct me if i'm wrong) and for asserting pattern integrity for this case we need to wait for after everything has been set in the constructor. Also we need to avoid doing some logic during constructor to constructor calls so we will need to have a call back to the actual Flyweight pattern object. This will also allow us to avoid flyweight pattern integrity calls to sprawl into the RuntimeRegistry. We should probably try to keep the patterns in the catalog as self contained as possible when concerning methods that will be called during an objects lifetime.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There needs to be a standard way to assess all the available flyweights. So basically each design pattern needs its own config (coz you may not want to assert on ALL available instances).
<object-profile metaphor="testFlyweight">
<core:flyweight>
<core:all-instances/>
</core:flyweight>
The above would inject bytecode into all available constructors to register them to the instance registry.
Your idea of <core:factory method="getInstance"/> is a very good one too and can easily be dropped in this way.
Im getting the feeling JO is beginning to look like a dependency-injection framework!!!
Ok, for flyweight, we can config an equals comparator similarly (though it shouldnt be necessary as Object.equals() is pretty standard). I am thinking it would be valuable to be able to use an <object-state> assertion from within the design pattern too?
Or maybe that's something to worry about when defining new design patterns testers...
Couple of points here to talk about...
1. "Inject bytecode into all available constructors" - this seems alittle accessive probably need them to declare all classes they want to make the assertions or make individual pattern state declarations for each class. The issue is how do you define all available constructors?
2. Definately need to be able to define the equals comparator via some attribute of each class configuration.
3. Object-state assertions within an design pattern element has value probably but definately something to add after we get some patterns actually hammered out :P
I'm going to start another forum for fine grained xml structure discussion. So we can dicuss the symantics of the pattern testing here and then the syntax else where. I know they will be inner dependent but we just have to get a starting point for the xml structure.
yea well if we dont inject into all available constructors there's no way to guarantee that all instances are tracked. Anyway there is a support method (called something like supportInstanceRegistration()) which automatically does this work for us. We can reflectively determine all the constructors for a class (except superclasses) which is what this support method does anyway.
We could make this optionally explicit, but I always find less verbosity out of the box is better.
i was thinking about only injecting code into the constructors into the classes which were designated as flyweights. Maybe i miss interperted you i thinking you wanted to inject code into every class available on the class path?
Also if the supportInstanceRegistration() method in AspectJ rt api's???
oh no I only meant instrumenting the flyweight candidates, everything on the classpath would be a nightmare!
RuntimeInstanceRegistry.supportInstanceRegistration() is a method I added that uses InstrumentUtils to instrument constructors with a static call to the JO ObjectsBackplane passing themselves in. The registry stores objects into a set based on their identityHashCode (so a class that overrides hashCode() and has two equal instances will still be treated as having 2 separate instances). This might be something we want to make optional based on the pattern's configuration?
Excellent i'm on the same page as you now.
Yes we could make the method which is used to check the instance registry configurable to be another method easily.
Looks like supportInstanceRegistation maybe be good enough. Basically it inserts before the other code the construtor (correct me if i'm wrong) and for asserting pattern integrity for this case we need to wait for after everything has been set in the constructor. Also we need to avoid doing some logic during constructor to constructor calls so we will need to have a call back to the actual Flyweight pattern object. This will also allow us to avoid flyweight pattern integrity calls to sprawl into the RuntimeRegistry. We should probably try to keep the patterns in the catalog as self contained as possible when concerning methods that will be called during an objects lifetime.