[swordfish-dev] Chat transcript 26/11/2008

[Oliver Wolf <oliver.wolf@xxxxxxxxx>]

Title: Chat transcript 26/11/2008

[START Transcript 26/11/2008]

Dietmar Wolz
Andrey, a question regarding EventImpl: why did you replace ConcurrentHashMap with HashTable?

Andrey Kopachevsky
yes, this is question I want to discuss
this is temporary sololution just to give you start refactor
the point is that if we use osgi EVENT_FILTER we need to move all Swordfish event properties to OSGI event level

Dietmar Wolz
one moment, will check

Andrey Kopachevsky
I'll give you code line number, one sec
see org.eclipse.swordfish.core.event.EventServiceImpl
postEvent() method, line 32-33
do you see what I mean?

Dietmar Wolz
what I was checking was public MapBasedDictionary(Map map) {
this.map = (map == null ? new LinkedHashMap() : map);
}
this is a Spring OSGI wrapper mapping arbitrary Maps to Dictionaries, perhaps useful in our case
Andrey, I merged your zip and updated the eclipse svn, but I want to wait for Andreas opinion before checking in any refactoring. Andreas is back now and will join the chat this afternoon. Issues to discuss are: 
a) Should we add separate config/event bundles?
b) Should we have separate api bundles?
c) Should we have separate test bundles?
d) Should we rename the api package (remove the .api and add a .internal to internal implementation packages?
This would give us a similar structure to the toast osgi sample. I would opt for a) and c), unsure about b) and d). b) and d) are related, .api makes not much sense if we split up the apis
Andreas, the actual workspace (before refactoring) is in exchange/dwolz/eclipsews.rar

Andrey Kopachevsky
@dietmar another question about case when we might need multiple filters for events

Dietmar Wolz
yes?

Andrey Kopachevsky
yep
for example we need receive followng filter _expression_
(& ( ! (severity >= 0) (severity <= 3) ) (someproperty = value1))
what strategy we need to achive: use one filter that generate whole statement, or configure some how several filters, for example one filter generate "severity" statements, second "someproperty"
osgi filter _expression_ using LDAP-like search filter syntax
http://wiki.pentaho.com/display/ServerDoc2x/LDAP+Search+Filter+Syntax

Dietmar Wolz
is it possible to combine the expressions generated from separate filters? Then I would opt for this solution

Andrey Kopachevsky
yes but it cost efforts, we need to create some kind of DSL language to combine filters in this case
do we need this?
but if from other hand if we will use only simple statements linke OR, AND, NOT for combite filters - it isn't so hard don't need DSL
I would prefer to use only one filter always, it is simplest way

Dietmar Wolz
May be we start with one filter, or we limit us to OR statements

Andrey Kopachevsky
yep

Dietmar Wolz
Andreas proposed a change
public interface ReadOnlyRegistry<T, V> { ... Map<String, V> getPropertry(T Key) ... }
which means there is an additional type parameter, but no cast is needed when using the resulting map. Andrey, what do you think?

Andreas Mattes
I suggest I go through the interfaces and do these refactorings considering the way how they are effectively used.

Andrey Kopachevsky
don't have any objections for that
probably we should use same maner in Event.getProperty()

Andreas Mattes
That's why I said I go through the interfaces - there are a couple of similar issues.

Andrey Kopachevsky
yes

Dietmar Wolz
Andreas, do you use exchange/dwolz/eclipsews.rar, which contains Andreys latest changes?

Andreas Mattes
ok, I'll use this - how will I return the changes?

Dietmar Wolz
same way, since you are not yet a committer. Andrey also has trouble checking in stuff, but in principle he has Volodymyrs account data.

Andreas Mattes
means I'll just send you an archive with the modified files - ok
looking through the chat I saw a couple of open questions with respect to how to cut the bundles (?)

Andrey Kopachevsky
actually I don't see big advantage with this change
does it means that
String property = (String)registry.getProperty(key);
will change to
String property = registry.getProperty(key, new String());
?

Andreas Mattes
no, it means that where possible you decide where you declare a value of the interface type which provides a getProperty method

Andrey Kopachevsky
o, I see
yes it make sence as long every property in registry will be same type

Andreas Mattes
for exact use I still have to update myself on the usage of these interfaces
no - the value type in the concrete case may be declared on the common supertype
in this case - of cousre - a cast cannot be avoided

Dietmar Wolz
The cutting bundles options are
a) Should we add separate config/event bundles?
b) Should we have separate api bundles?
c) Should we have separate test bundles?
d) Should we rename the api package (remove the .api and add a .internal to internal implementation packages?
This would give us a similar structure to the toast osgi sample. I would opt for a) and c), unsure about b) and d). b) and d) are related, .api makes not much sense if we split up the apis
any opinions?

Andreas Mattes
b may make sense for Configuration and event API - they apparently have no dependency on the rest of the API and may be used independently

Andrey Kopachevsky
yes, but corresponing OSGI interfaces like EventAdmin and ConfigurationManager exposed in one bundle, but different packages, it is quite usefull
so I would live api stuff in one place

Dietmar Wolz
but what about the implementation packages?

Andrey Kopachevsky
separate implementation in different packages - good idea

Dietmar Wolz
and tests?

Andrey Kopachevsky
unit or integration?
I'm asking because integration core.test project is not osgi bundle

Dietmar Wolz
I opt for unit tests in the implementation projects and different integration tests in separate bundles

Andrey Kopachevsky
> unit tests in the implementation projects - agree

Andreas Mattes
I can imagine test bundles which serve as construction set for use in unit and integration tests

Dietmar Wolz
you mean factoring out common stuff?
we are using already an osgi integration test framework - from spring DM

Andreas Mattes
custom enhancements, mocks, etc.

Andrey Kopachevsky
I don't thinkg that it make sense to make separate integration test bundle for each project

Andreas Mattes
that's not my idea either, it's mainly few integration test bundles + some bundles which common helpful utilities

Dietmar Wolz
which are the arguments for a single integration test bundle?

Andrey Kopachevsky
see org.eclipse.swordfish.core.test for the moment we have only 1 test case class for each implementation
so if we want to separate Event Testing it will be one-class project

Dietmar Wolz
We could start doing the things where we agree first: separate implementation bundles for config/events. Andreas, I volunteered to do this, so either you post when you are ready with your stuff - or you could try to do the separation and I will test it later, Andreas, what do you prefer

Andreas Mattes
I think integration tests correspond to usage scenarios, and with this in mind integration tests should be cut into bundles (one per usage scenario in mind)

Dietmar Wolz
I agree to Andreas opinion, and I heared from Oliver a similar opinion, but we could do the implementation bundles first

Andrey Kopachevsky
just keep in mind that our integration test project org.eclipse.swordfish.core.test is not osgi bundle
@dietmar separate implementation bundles for config/events - ok

Andreas Mattes
@dietmar: ok so I will go now through generics in the interfaces now so that you can start tomorrow morning

Dietmar Wolz
Andrey, I am not so shure about your statement, as far as I know the Spring DM test framework builds an osgi bundle on the fly during the integration test

Guillaume Nodet
beware of classloader issues when using spring-dm tests support
the classloader will be really different than the one in real osgi environment
it can lead to problems when using xml parsing, jaxb, or such other specifications

Andrey Kopachevsky
@dietmar yes, you right, I just point that Spring DM test framework project is not bundle itself

Dietmar Wolz
Hi Guillaume, this was exactly the reason I checked the smix4 code using the spring DM test framework

Guillaume Nodet
ah, ok, i missed that point
yeah, that's what we've done to have an environment which is much more similar to the real one
sorry for the noise then

Dietmar Wolz
Guilliome, I liked the idea to let maven build version info which then are used by the tests, we "borrowed" this stuff 

Guillaume Nodet
cool

sm.cannes
very good !

[END]

Want to join the chat? 
http://www.skype.com/go/joinpublicchat?skypename=ranyart99&topic=Swordfish%20Developers&blob=Gu7tZh64gTuo551Icz6_iwhXVeXxQ0K4yEzI5XFwGdWIQ_-miteLtgSBILodJ8koN6Uwy9PiotEU5ewRYFqEJeUtl1Yhfc1ipuVwOFz0SWN9HwMZAeikprh0R_8

-- 

Oliver Wolf
SOPERA GmbH