wire context: added lookup by type

[tom.baeyens]

checkout the new lookup by type:

see test/java/org.jbpm.wire.TypeLookupTest

i still need to propagate this method to the environment. so that we'll be able to do e.g.

environment.find(PersistenceService.class).save(process);

no cast nor names must be given in the xml for objects that can be identified by their type.

[porcherg]

checkout the new lookup by type

I have a few comments about this feature:
- only ObjectDescriptor implements the method 'getType' so context.get('List.class') does not work on a ListDescriptor. Maybe we can implement this method for each Descriptor (and remove the default implementation from AbstractDescriptor) ?

- all descriptors can be returned by a look up, not only top level ones. If we define a list, anonymous elements of the list are returned by a get. For me, an element of a list is not a part of the environment, but a part of the list (and only the list can be fetched directly from the environment) . Maybe we can only list named descriptors and top level descriptors ?

regards,
Guillaume

[tom.baeyens]

I have a few comments about this feature:
- only ObjectDescriptor implements the method 'getType' so context.get('List.class') does not work on a ListDescriptor. Maybe we can implement this method for each Descriptor (and remove the default implementation from AbstractDescriptor) ?

we could do it for most descriptor types, indeed. but the question is: is that useful ? this was my reasoning: for wiring objects like PersistenceService, Transaction and so on, you could assume that there is only one of those. So it makes sense to ask for the Persistence service in the context.

But would it make sense to say to the environment "give me the list" ?

So i only did it for descriptors, for which the type could uniquely identify the object in the environment.

Another thing is that you can't really make it complete. There are some objects that you will not be able to get the impl type from. E.g. factory methods. I'm not religious about it.

Do you think there is a use case for it?

- all descriptors can be returned by a look up, not only top level ones.

i don't really get what you mean here. the behaviour that you describe after that statement as the desired behaviour is what i think i've implemented. so i don't yet see the difference.

[porcherg]

- all descriptors can be returned by a look up, not only top level ones.

i don't really get what you mean here. the behaviour that you describe after that statement as the desired behaviour is what i think i've implemented. so i don't yet see the difference.

I'll try to illustrate that on an example.
In this test:

public void testTypeLookupListElement() {
 WireContext wireContext = createWireContext(
 "<objects>" +
 " <list name='test'>" +
 " <object class='"+Text.class.getName()+"'/>" +
 " </list>" +
 "</objects>"
 );

 assertNull(wireContext.get(Text.class));
 assertNotNull(wireContext.get("test"));
 assertNull(wireContext.get(Text.class));
 }

The first get returns a Text object and the test fails. For me, the Text object is not in the context, so this test should succeed.

Guillaume

[tom.baeyens]

For me, an element of a list is not a part of the environment, but a part of the list (and only the list can be fetched directly from the environment).

that's not much of an argumentation for me.

intuitively i would think the opposite. but i'm not religious about it. you can change it as you want now. but with your current argumentation, if i ever come accross a use case where i need the other strategy, i'll change it.

[pierre.vigneras]

As for me, we have 2 options : either we represent the XML file which is a tree :
in this case, a List should be represented as a List, and their components should be accessed through the list. As think, this is the most natural way.

The other option is to flatten the XML file in such a way that each object tag are just inserted into a flat list. In this case, A list is no more accessible, only their components through the global list. This is not natural but it works fine. It seems, as far as I understand that this last option is the one that is implemented. The least should be that it is well documented in order to avoid confusions.

Regards.