Re: [castor-dev] Question about TransactionManagerRegistry.Loader inner class
Hi Ralf, sorry, but I don't see a reason as why those classes should not be made public. What we have at the moment hass been designed some 10 years ago, and does not meet any of the requirements software developers got used to during working with Hibernate (and JPA recently) for years. I for myself have spent hours and hours (and students have spent about 1500+ hours plus) to extend Castor in multiple ways, be it the JDO extensions for the XML code generator or the support for JPA annoations so that JPA-annotated classes could be persisted with Castor JDO. When working with those students, and when talking to numerous people about usage fo Castor or not, I have come across the same fedback again and again. Why are there static methods to use to instantiate a JDOManager instance ? Why is there no factory or builder similar to SessionFactory/Session in Hibernate and whatever is there with all the other specs ? Why can't you set things as properties on e.g. a JDOManagerFactory and ease our lives tremendously. To be honest, it should be there, as we should not force users to pick one of the clumsy loadConfiguration() methods (where none of them is an ideal pick). We should not force users to having to define a JDO configuration file when they are used to setting DataSources themselves or through Spring, etc. On other words, while I would love to implement the JPA spec in one or two months, I cannot see it happening (easily). But should this knowledge prevent me from improving Castor JDO and its current offering again and again. I think it should not. I do not want to force users of Castor JDO through Spring to having to define a JDBC driver in a JDO configuration file, when all they want is to maintain their DataSource definitions in one place, i.e. a Spring context, or a JNDI context. Right now, we force them to duplicate those settings, creating quite some risk for them I am more than eager to reduce those artificial requirements from Castor, and to make it more usable and integrateable. If there will be a JPA spec compliance one day, even better. But as this will be a facade around existing Castor, I don't see a need to not evolve Castor. Regards Werner Ralf Joachim wrote: > Hi Werner, > > if you do not have the time to care a bit on the JPA interfaces, please > do not announce this new classes for public use as one working at JPA > compliance may need to deprecate them. > > Regards > Ralf > > Werner Guttmann schrieb: >> Ralf, >> >> I am *not* working on anything related to JPA. I am only trying to add a >> new factories/builders to Castor JDO so that instantiation of JDOmanager >> instances is sufficiently eased. >> >> And if you want me to continue with integrating e.g. support for JPA >> annotations with Castor JDO (where a group of students has spent some >> 700 hours), you rather not ask me to wait for JPA API stuff .. ;-). >> >> Regards >> Werner >> >> Ralf Joachim wrote: >> >>> Hi Werner, >>> >>> this basically seams to go into the same direction that I have in mind. >>> But your interface seam not to take care on JPA specification which is a >>> prerequisit for changes at bootstrapping code of Castor in my opinion. I >>> would really appreciate if you could take care on JPA bootstrapping and >>> interfaces. At least I don't want to introduce something that >>> contradicts to the requirements of JPA specification. >>> >>> As far as I understand JPA specification, configuration gets passed to >>> PersistenceProvider with a PersistenceUnitInfo instance to create a >>> EntityManagerFactory if you configure things programatically. When >>> configuring with jdo-conf.xml or persistence.xml we could translate this >>> into PersistenceUnitInfo also. EntityManagerFactory for JPA plays about >>> the same role that JDOManager has for Castor. >>> >>> What I had in mind was to refactor current codebase to internaly use a >>> class that implements PersistenceUnitInfo to hold configuration >>> information first. If that is reached we could add support for >>> persistence.xml and implement PersistenceProvider. >>> >>> The problem when starting at that area is that PersistenceProvider need >>> to return JDOManager instances which does not yet implement >>> EntityManagerFactory interface and therefore does not comply to JPA. >>> Having said that I do not see a problem with this if we use that >>> internally (e.g. for spring-orm) but we should not make this public >>> until full compliance to JPA is reached. >>> >>> Regards >>> Ralf >>> >>> >>> Werner Guttmann schrieb: >>> Hi Ralf, Ralf Joachim wrote: > Hi Werner, > > Werner Guttmann schrieb: > > >> Hi Ralf, >> >> Ralf Joachim wrote: >> >> >> >>> Hi Werner, >>> >>> TMR.Loader holds TMF and properties to allow lazy initialization of TM. >>> Another posibility to implement this would be to maintain TMF, >>> properties
Re: [castor-dev] Question about TransactionManagerRegistry.Loader inner class
Hi Werner, if you do not have the time to care a bit on the JPA interfaces, please do not announce this new classes for public use as one working at JPA compliance may need to deprecate them. Regards Ralf Werner Guttmann schrieb: > Ralf, > > I am *not* working on anything related to JPA. I am only trying to add a > new factories/builders to Castor JDO so that instantiation of JDOmanager > instances is sufficiently eased. > > And if you want me to continue with integrating e.g. support for JPA > annotations with Castor JDO (where a group of students has spent some > 700 hours), you rather not ask me to wait for JPA API stuff .. ;-). > > Regards > Werner > > Ralf Joachim wrote: > >> Hi Werner, >> >> this basically seams to go into the same direction that I have in mind. >> But your interface seam not to take care on JPA specification which is a >> prerequisit for changes at bootstrapping code of Castor in my opinion. I >> would really appreciate if you could take care on JPA bootstrapping and >> interfaces. At least I don't want to introduce something that >> contradicts to the requirements of JPA specification. >> >> As far as I understand JPA specification, configuration gets passed to >> PersistenceProvider with a PersistenceUnitInfo instance to create a >> EntityManagerFactory if you configure things programatically. When >> configuring with jdo-conf.xml or persistence.xml we could translate this >> into PersistenceUnitInfo also. EntityManagerFactory for JPA plays about >> the same role that JDOManager has for Castor. >> >> What I had in mind was to refactor current codebase to internaly use a >> class that implements PersistenceUnitInfo to hold configuration >> information first. If that is reached we could add support for >> persistence.xml and implement PersistenceProvider. >> >> The problem when starting at that area is that PersistenceProvider need >> to return JDOManager instances which does not yet implement >> EntityManagerFactory interface and therefore does not comply to JPA. >> Having said that I do not see a problem with this if we use that >> internally (e.g. for spring-orm) but we should not make this public >> until full compliance to JPA is reached. >> >> Regards >> Ralf >> >> >> Werner Guttmann schrieb: >> >>> Hi Ralf, >>> >>> Ralf Joachim wrote: >>> >>> Hi Werner, Werner Guttmann schrieb: > Hi Ralf, > > Ralf Joachim wrote: > > > >> Hi Werner, >> >> TMR.Loader holds TMF and properties to allow lazy initialization of TM. >> Another posibility to implement this would be to maintain TMF, >> properties and initialized TM in different maps in TMR. It may also be >> possible that another class (e.g. DatabaseRegistry, DatabaseContext) >> could handle the lazy initialization. >> >> The only reason why someone would need that (lazy init of TM) could be >> that he loads multiple jdo-conf ... >> >> >> > So in that case, the JDO configurations would carry a name attribute, > right, to distinguish them from each other ? > > > Yes. > > > >> with different TM but uses only one in >> his application. With the lazy initialization of the TM's he prevents >> failures from the other TM that could not be instantiated or looked up. >> >> >> > Assuming that this would be on the same classloader (e.g. the class > loader from a web application), would this really make sense ? I always > thought that our users would like to be informed about any > misconfigurations as soon as possible, i.e. at startup time, similar to > mapping problems. > > > I remember a request for lazy initialization of database instances. Not sure if this also requested lazy initialization of TM but I think we have introduced it in this context. About 2 weeks ago I have had a peek in this area of code myself when looking at an open issue to refactor DatabaseRegistry. Targets of this refactoring should be to make code easier to understand and make Castor bootstrapping compliant to JPA. An first outcome of this was the refactoring of ConnectionFactories. To get JPA compliant we will also need to support persistence.xml files as an alternative to jdo-conf. If you compare this 2 configurations you will recognize that persistence.xml allows to specify a transaction manager for each database instance. My impression is that this will also make bootstrapping code much simpler and may also influence the lazy initialization of TM. Do you have any problems with TM handling or what caused you to look at this area of code again? I you don't mind to share. >>
Re: [castor-dev] Question about TransactionManagerRegistry.Loader inner class
Ralf, I am *not* working on anything related to JPA. I am only trying to add a new factories/builders to Castor JDO so that instantiation of JDOmanager instances is sufficiently eased. And if you want me to continue with integrating e.g. support for JPA annotations with Castor JDO (where a group of students has spent some 700 hours), you rather not ask me to wait for JPA API stuff .. ;-). Regards Werner Ralf Joachim wrote: > Hi Werner, > > this basically seams to go into the same direction that I have in mind. > But your interface seam not to take care on JPA specification which is a > prerequisit for changes at bootstrapping code of Castor in my opinion. I > would really appreciate if you could take care on JPA bootstrapping and > interfaces. At least I don't want to introduce something that > contradicts to the requirements of JPA specification. > > As far as I understand JPA specification, configuration gets passed to > PersistenceProvider with a PersistenceUnitInfo instance to create a > EntityManagerFactory if you configure things programatically. When > configuring with jdo-conf.xml or persistence.xml we could translate this > into PersistenceUnitInfo also. EntityManagerFactory for JPA plays about > the same role that JDOManager has for Castor. > > What I had in mind was to refactor current codebase to internaly use a > class that implements PersistenceUnitInfo to hold configuration > information first. If that is reached we could add support for > persistence.xml and implement PersistenceProvider. > > The problem when starting at that area is that PersistenceProvider need > to return JDOManager instances which does not yet implement > EntityManagerFactory interface and therefore does not comply to JPA. > Having said that I do not see a problem with this if we use that > internally (e.g. for spring-orm) but we should not make this public > until full compliance to JPA is reached. > > Regards > Ralf > > > Werner Guttmann schrieb: >> Hi Ralf, >> >> Ralf Joachim wrote: >> >>> Hi Werner, >>> >>> Werner Guttmann schrieb: >>> Hi Ralf, Ralf Joachim wrote: > Hi Werner, > > TMR.Loader holds TMF and properties to allow lazy initialization of TM. > Another posibility to implement this would be to maintain TMF, > properties and initialized TM in different maps in TMR. It may also be > possible that another class (e.g. DatabaseRegistry, DatabaseContext) > could handle the lazy initialization. > > The only reason why someone would need that (lazy init of TM) could be > that he loads multiple jdo-conf ... > > So in that case, the JDO configurations would carry a name attribute, right, to distinguish them from each other ? >>> Yes. >>> > with different TM but uses only one in > his application. With the lazy initialization of the TM's he prevents > failures from the other TM that could not be instantiated or looked up. > > Assuming that this would be on the same classloader (e.g. the class loader from a web application), would this really make sense ? I always thought that our users would like to be informed about any misconfigurations as soon as possible, i.e. at startup time, similar to mapping problems. >>> I remember a request for lazy initialization of database instances. Not >>> sure if this also requested lazy initialization of TM but I think we >>> have introduced it in this context. >>> >>> About 2 weeks ago I have had a peek in this area of code myself when >>> looking at an open issue to refactor DatabaseRegistry. Targets of this >>> refactoring should be to make code easier to understand and make Castor >>> bootstrapping compliant to JPA. An first outcome of this was the >>> refactoring of ConnectionFactories. To get JPA compliant we will also >>> need to support persistence.xml files as an alternative to jdo-conf. If >>> you compare this 2 configurations you will recognize that >>> persistence.xml allows to specify a transaction manager for each >>> database instance. My impression is that this will also make >>> bootstrapping code much simpler and may also influence the lazy >>> initialization of TM. >>> >>> Do you have any problems with TM handling or what caused you to look at >>> this area of code again? I you don't mind to share. >>> >> I am currently working on introducing two new classes, named >> JDOManagerfactoryByFile and JDOMansgerFactory. Both classes will >> basically allow you to configure the required properties to instantiate >> *one* (and one only) JDOManager instance. >> >> As you can see by looking at the file names above, this will allow >> configuration though a standard JDO configuration file (ByFile), or >> though a set of setter methods (setMapping, setTransactionDemarcation, >> setDatabaseEngine, setDataSource) (using java
Re: [castor-dev] Question about TransactionManagerRegistry.Loader inner class
Hi Werner, this basically seams to go into the same direction that I have in mind. But your interface seam not to take care on JPA specification which is a prerequisit for changes at bootstrapping code of Castor in my opinion. I would really appreciate if you could take care on JPA bootstrapping and interfaces. At least I don't want to introduce something that contradicts to the requirements of JPA specification. As far as I understand JPA specification, configuration gets passed to PersistenceProvider with a PersistenceUnitInfo instance to create a EntityManagerFactory if you configure things programatically. When configuring with jdo-conf.xml or persistence.xml we could translate this into PersistenceUnitInfo also. EntityManagerFactory for JPA plays about the same role that JDOManager has for Castor. What I had in mind was to refactor current codebase to internaly use a class that implements PersistenceUnitInfo to hold configuration information first. If that is reached we could add support for persistence.xml and implement PersistenceProvider. The problem when starting at that area is that PersistenceProvider need to return JDOManager instances which does not yet implement EntityManagerFactory interface and therefore does not comply to JPA. Having said that I do not see a problem with this if we use that internally (e.g. for spring-orm) but we should not make this public until full compliance to JPA is reached. Regards Ralf Werner Guttmann schrieb: > Hi Ralf, > > Ralf Joachim wrote: > >> Hi Werner, >> >> Werner Guttmann schrieb: >> >>> Hi Ralf, >>> >>> Ralf Joachim wrote: >>> >>> Hi Werner, TMR.Loader holds TMF and properties to allow lazy initialization of TM. Another posibility to implement this would be to maintain TMF, properties and initialized TM in different maps in TMR. It may also be possible that another class (e.g. DatabaseRegistry, DatabaseContext) could handle the lazy initialization. The only reason why someone would need that (lazy init of TM) could be that he loads multiple jdo-conf ... >>> So in that case, the JDO configurations would carry a name attribute, >>> right, to distinguish them from each other ? >>> >>> >> Yes. >> >>> >>> with different TM but uses only one in his application. With the lazy initialization of the TM's he prevents failures from the other TM that could not be instantiated or looked up. >>> Assuming that this would be on the same classloader (e.g. the class >>> loader from a web application), would this really make sense ? I always >>> thought that our users would like to be informed about any >>> misconfigurations as soon as possible, i.e. at startup time, similar to >>> mapping problems. >>> >>> >> I remember a request for lazy initialization of database instances. Not >> sure if this also requested lazy initialization of TM but I think we >> have introduced it in this context. >> >> About 2 weeks ago I have had a peek in this area of code myself when >> looking at an open issue to refactor DatabaseRegistry. Targets of this >> refactoring should be to make code easier to understand and make Castor >> bootstrapping compliant to JPA. An first outcome of this was the >> refactoring of ConnectionFactories. To get JPA compliant we will also >> need to support persistence.xml files as an alternative to jdo-conf. If >> you compare this 2 configurations you will recognize that >> persistence.xml allows to specify a transaction manager for each >> database instance. My impression is that this will also make >> bootstrapping code much simpler and may also influence the lazy >> initialization of TM. >> >> Do you have any problems with TM handling or what caused you to look at >> this area of code again? I you don't mind to share. >> > I am currently working on introducing two new classes, named > JDOManagerfactoryByFile and JDOMansgerFactory. Both classes will > basically allow you to configure the required properties to instantiate > *one* (and one only) JDOManager instance. > > As you can see by looking at the file names above, this will allow > configuration though a standard JDO configuration file (ByFile), or > though a set of setter methods (setMapping, setTransactionDemarcation, > setDatabaseEngine, setDataSource) (using java 5.0 enums etc.) > > Why all this ? When working on the Mavenization of the CPACTF test suite > (its POM, introducing sql-maven-plugins executions, ...), I - once again > - came to realize that I want to be able to configure Castor JDO without > having to use a JDO configuration file. And I think that the JdoConf > classes we introduced years ago don't really fit this need any more. > > I think the code will most likely look similar to > > BasicDataSource dataSource = new BasicDataSource(); > dataSource.setUsername(...); > ... > > Mapping mapping = > ... > > J
Re: [castor-dev] Question about TransactionManagerRegistry.Loader inner class
Hi Ralf,
Ralf Joachim wrote:
> Hi Werner,
>
> Werner Guttmann schrieb:
>> Hi Ralf,
>>
>> Ralf Joachim wrote:
>>
>>> Hi Werner,
>>>
>>> TMR.Loader holds TMF and properties to allow lazy initialization of TM.
>>> Another posibility to implement this would be to maintain TMF,
>>> properties and initialized TM in different maps in TMR. It may also be
>>> possible that another class (e.g. DatabaseRegistry, DatabaseContext)
>>> could handle the lazy initialization.
>>>
>>> The only reason why someone would need that (lazy init of TM) could be
>>> that he loads multiple jdo-conf ...
>>>
>> So in that case, the JDO configurations would carry a name attribute,
>> right, to distinguish them from each other ?
>>
> Yes.
>>
>>> with different TM but uses only one in
>>> his application. With the lazy initialization of the TM's he prevents
>>> failures from the other TM that could not be instantiated or looked up.
>>>
>> Assuming that this would be on the same classloader (e.g. the class
>> loader from a web application), would this really make sense ? I always
>> thought that our users would like to be informed about any
>> misconfigurations as soon as possible, i.e. at startup time, similar to
>> mapping problems.
>>
> I remember a request for lazy initialization of database instances. Not
> sure if this also requested lazy initialization of TM but I think we
> have introduced it in this context.
>
> About 2 weeks ago I have had a peek in this area of code myself when
> looking at an open issue to refactor DatabaseRegistry. Targets of this
> refactoring should be to make code easier to understand and make Castor
> bootstrapping compliant to JPA. An first outcome of this was the
> refactoring of ConnectionFactories. To get JPA compliant we will also
> need to support persistence.xml files as an alternative to jdo-conf. If
> you compare this 2 configurations you will recognize that
> persistence.xml allows to specify a transaction manager for each
> database instance. My impression is that this will also make
> bootstrapping code much simpler and may also influence the lazy
> initialization of TM.
>
> Do you have any problems with TM handling or what caused you to look at
> this area of code again? I you don't mind to share.
I am currently working on introducing two new classes, named
JDOManagerfactoryByFile and JDOMansgerFactory. Both classes will
basically allow you to configure the required properties to instantiate
*one* (and one only) JDOManager instance.
As you can see by looking at the file names above, this will allow
configuration though a standard JDO configuration file (ByFile), or
though a set of setter methods (setMapping, setTransactionDemarcation,
setDatabaseEngine, setDataSource) (using java 5.0 enums etc.)
Why all this ? When working on the Mavenization of the CPACTF test suite
(its POM, introducing sql-maven-plugins executions, ...), I - once again
- came to realize that I want to be able to configure Castor JDO without
having to use a JDO configuration file. And I think that the JdoConf
classes we introduced years ago don't really fit this need any more.
I think the code will most likely look similar to
BasicDataSource dataSource = new BasicDataSource();
dataSource.setUsername(...);
...
Mapping mapping =
...
JDOManagerFactory factory = new JDOManagerFactory();
factory.setDataSource(dataSource);
factory.setTransactionDemarcation(TransactionDemarcation.Local);
factory.setMapping(mapping)
factory.setDatabaseEngine(DatabaseEngine.MYSQL);
factory.setXXX(...);
factory.setDatabaseName("test");
JDOManager manager = factory.createInstance("test");
This will have a couple of advantages:
a) You can supply external javx.sql.DataSources.
b) Configuration is easy, and can be supplied more easily from outside
(without having to make available a JDO configuration file for each test
suite invocation, ...)
c) It's a step towards where frameworks like Hibernate and various JPA
providers are.
d) It will allow me to remove a lot of work-arounds in the Spring ORM
code for Castor JDO.
e) I am sure there's more .. ;-)
Cheers
Werner
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [castor-dev] Question about TransactionManagerRegistry.Loader inner class
Hi Werner, Werner Guttmann schrieb: > Hi Ralf, > > Ralf Joachim wrote: > >> Hi Werner, >> >> TMR.Loader holds TMF and properties to allow lazy initialization of TM. >> Another posibility to implement this would be to maintain TMF, >> properties and initialized TM in different maps in TMR. It may also be >> possible that another class (e.g. DatabaseRegistry, DatabaseContext) >> could handle the lazy initialization. >> >> The only reason why someone would need that (lazy init of TM) could be >> that he loads multiple jdo-conf ... >> > So in that case, the JDO configurations would carry a name attribute, > right, to distinguish them from each other ? > Yes. > >> with different TM but uses only one in >> his application. With the lazy initialization of the TM's he prevents >> failures from the other TM that could not be instantiated or looked up. >> > Assuming that this would be on the same classloader (e.g. the class > loader from a web application), would this really make sense ? I always > thought that our users would like to be informed about any > misconfigurations as soon as possible, i.e. at startup time, similar to > mapping problems. > I remember a request for lazy initialization of database instances. Not sure if this also requested lazy initialization of TM but I think we have introduced it in this context. About 2 weeks ago I have had a peek in this area of code myself when looking at an open issue to refactor DatabaseRegistry. Targets of this refactoring should be to make code easier to understand and make Castor bootstrapping compliant to JPA. An first outcome of this was the refactoring of ConnectionFactories. To get JPA compliant we will also need to support persistence.xml files as an alternative to jdo-conf. If you compare this 2 configurations you will recognize that persistence.xml allows to specify a transaction manager for each database instance. My impression is that this will also make bootstrapping code much simpler and may also influence the lazy initialization of TM. Do you have any problems with TM handling or what caused you to look at this area of code again? I you don't mind to share. Regards Ralf > >> Regards >> Ralf >> >> Werner Guttmann schrieb: >> >>> Hi, >>> >>> can anybody share his memories with me and explain to me what the >>> purpose of this inner class is. I have now been staring at this class >>> for some odd 15 minutes, and somehow I don't reach a conclusion. >>> >>> Anybody ? >>> >>> Regards >>> Werner >>> >>> - >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >>> >>> >>> > > - > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- Syscon Ingenieurbüro für Meß- und Datentechnik GmbH Ralf Joachim Raiffeisenstraße 11 72127 Kusterdingen Germany Tel. +49 7071 3690 52 Mobil: +49 173 9630135 Fax+49 7071 3690 98 Internet: www.syscon.eu E-Mail: [email protected] Sitz der Gesellschaft: D-72127 Kusterdingen Registereintrag: Amtsgericht Stuttgart, HRB 382295 Geschäftsleitung: Jens Joachim, Ralf Joachim
Re: [castor-dev] Question about TransactionManagerRegistry.Loader inner class
Hi Ralf, Ralf Joachim wrote: > Hi Werner, > > TMR.Loader holds TMF and properties to allow lazy initialization of TM. > Another posibility to implement this would be to maintain TMF, > properties and initialized TM in different maps in TMR. It may also be > possible that another class (e.g. DatabaseRegistry, DatabaseContext) > could handle the lazy initialization. > > The only reason why someone would need that (lazy init of TM) could be > that he loads multiple jdo-conf ... So in that case, the JDO configurations would carry a name attribute, right, to distinguish them from each other ? > with different TM but uses only one in > his application. With the lazy initialization of the TM's he prevents > failures from the other TM that could not be instantiated or looked up. Assuming that this would be on the same classloader (e.g. the class loader from a web application), would this really make sense ? I always thought that our users would like to be informed about any misconfigurations as soon as possible, i.e. at startup time, similar to mapping problems. > > Regards > Ralf > > Werner Guttmann schrieb: >> Hi, >> >> can anybody share his memories with me and explain to me what the >> purpose of this inner class is. I have now been staring at this class >> for some odd 15 minutes, and somehow I don't reach a conclusion. >> >> Anybody ? >> >> Regards >> Werner >> >> - >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [castor-dev] Question about TransactionManagerRegistry.Loader inner class
Hi Werner, TMR.Loader holds TMF and properties to allow lazy initialization of TM. Another posibility to implement this would be to maintain TMF, properties and initialized TM in different maps in TMR. It may also be possible that another class (e.g. DatabaseRegistry, DatabaseContext) could handle the lazy initialization. The only reason why someone would need that (lazy init of TM) could be that he loads multiple jdo-conf with different TM but uses only one in his application. With the lazy initialization of the TM's he prevents failures from the other TM that could not be instantiated or looked up. Regards Ralf Werner Guttmann schrieb: > Hi, > > can anybody share his memories with me and explain to me what the > purpose of this inner class is. I have now been staring at this class > for some odd 15 minutes, and somehow I don't reach a conclusion. > > Anybody ? > > Regards > Werner > > - > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- Syscon Ingenieurbüro für Meß- und Datentechnik GmbH Ralf Joachim Raiffeisenstraße 11 72127 Kusterdingen Germany Tel. +49 7071 3690 52 Mobil: +49 173 9630135 Fax+49 7071 3690 98 Internet: www.syscon.eu E-Mail: [email protected] Sitz der Gesellschaft: D-72127 Kusterdingen Registereintrag: Amtsgericht Stuttgart, HRB 382295 Geschäftsleitung: Jens Joachim, Ralf Joachim - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
