woody, flow and database confusion

[Bert Van Kets <be...@vankets.com>]

I have been trying for several days to get grips on the "super trio" Woody,
Flow and OJB/JDO. I don't have any succes yet, but that is mainly to the
complexity of getting OJB/JDO to run. Could someone please shed a light on
this to get me going again?

I have created a bean to store all form data. The Woody form and the
FlowScipt have been created too. I have used the obj/woody sample as a
template to get things running. That's the easy part (relatively speaking).
I'm using mySQL as a databasource and have a datasource configured in
cocoon.xconf. This datasource is used in XSP pages using ESQL without any
problem, so that works for sure.
My biggest confusion is where I need to configure the link from the bean
datastore to the database. Where do I configure OJB and JDO?
I have OJB.properties, package.jdo, repository.dtd and repository.xml in the
WEB-INF/classes directory. I see a total overlap in the configuration in the
package.jdo and repository.xml file. Why is that? Is either of them not
needed?

I have created a DAO class file too. This is a direct copy of the
Employee_DAO class file from the samples. I only replaced the package and
replaced the bean methods with the ones from my bean. All this compiles
without any problem. The bean and the DAO class are packaged in a jar file
and put in the WEB-INF lib directory. I assume this is where I will
eventually create queries using OJB code to fill the bean with data. Am I
correct?

Thanks a lot for any help,
Bert



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: woody, flow and database confusion

[Joerg Heinicke <jo...@gmx.de>]

On 22.02.2004 04:07, Antonio Gallardo wrote:

>>Maybe we should put together our efforts to get this thing working and to
>>help other people with a wiki page.
> 
> 
> I need
> to tell I am newbie in OJB too. Maybe 1 or 2 days ahead in some cases, but
> this is nothing.

Pure understatement :)

>>We have at least our own application running with OJB. We can retrieve
>>lists or single objects from the db and display them with Woody, we can
>>store them back and delete them. We only have still a problem with
>>object identity,
> 
> 
> I think there is an old bug in JDO implementation in OJB related to
> indetities. We fight with this problem 2 weeks with no results, then we
> decided to switch to PB implementation. But let the open door to rewrote
> the code when JDO will be avaliable.

We don't JDO at all so it can't be a JDO bug :) It was also not a bug in 
OJB, but in my binding file. The id of the object was read/write, I 
changed it, now it works. (It's only strange IMO that updating an object 
with resetting the id to 0 stores the object correctly (probably because 
of object identity in the Java sense) and adds a new object (object 
identity in the ojb sense = new primary key) additionally - that might 
be a bug in OTM.)

>>so that storing does indeed create a new object in db,
>>but that's another problem we didn't have a closer look yesterday evening.
>>
>>We started also with OJB/JDO and had bad feelings when we saw that we
>>have to maintain at least two files (package.jdo, repository.xml) to get
>>it working. The reason for it is that JDO and OJB are two different
>>products, OJB provides only a plugin for Sun JDO at the moment, but both
>>must get their configuration. Though it's easy to write a stylesheet
>>that converts one format into the other I tried to use only JDO.
> 
> 
> While writing the code in Druid, I noted that repository.xml has far more
> info that the .jdo onces.

Indeed.

> In fact after querying on the OJB maillist I noted we don't need to put
> too much info inside the .jdo. AFAIK, the only need info in .jdo is the
> info that currently druid put on the .jdo files.

Don't know what Druid puts into it, but you only need the information 
for the JDO enhancing and the class usage at runtime. The file is 
completely not interesting for OJB.

>>But JDO is just the API, the SPI must be provided by the database
>>vendor and as
>>there are probably not that much for a specific at the moment, you need
>>OJB. Then we found out that the JDO implementation has a performance
>>problem: Retrieving 20 rows out of 6.000 in a db leads to instantiation
>>of all 6.000 objects, they are filtered by JDO. That's not a problem of
>>OJB, it's just how Sun JDO works. So we were back nearly to the
>>beginning.
> 
> 
> Hmm.. switching between JDO->(PB|OTM|ODMG) is not too painfull. This in
> one of the best features of OJB at all.

Hope so :)

>>Now the application itself. I don't love the idea of accessing the
>>persistence layer from the flow/controller layer directly. We access it
>>only from the application layer to have obvious tiers. We have a
>>DAOFactory that returns DAOs (e.g. either JDO or OTM), the
>>implementation of the persistence framework access is abstracted.
> 
> 
> We choosed to have DAO classes with static methods, that way we don't need
> to create too many DAO objects. Between Flow and DAO classes fly the
> Beans. Some of them are BeanList. They are easily passed to  the cforms
> using the framework binding.

Similar to ours, but in our approach the flow has no access to the 
persistence layer. The request goes through the business logic layer.

> I am not sure if this is the best approach, but it works. I will be glad
> if we can comment about what are the pros and the cons of Joerg approach
> vs. this approach. I am not a Java or OO guru. Comments are very welcome.

I guess it just depends. We will have much business logic, so a layered 
architecture is important. A direct access from flow to persistence 
layer will be dangerous in this case.

>>In
>>theory we can switch to Castor, Hibernate or what else without touching
>>the application layer.
> 
> 
> Can you explain what is the application layer? I am confused here. Is the
> application layer the view in the MVC paradigm?

MVC is a bit coarse-grained (if that's the correct word?) IMO. A good 
architecture needs more layers. A searched around using Google about 
application layer. In some cases the word is used synonymous to business 
logic layer, on other pages it's between presentation layer and business 
logic layer. What I meant above was indeed the business logic layer.

>>Each object specific DAO will provide different
>>methods for retrieving, storing, deleting etc. As the layers below the
>>flow layer are no Avalon components and not in relation to Cocoon, but
>>"Plain Old Java" we kicked out Cocoon OJB block completely and just use
>>OJB. If this was a good decision we will see.
> 
> 
> I thought to do this too. In fact the first experiment was using directly
> OJB in Cocoon:
> 
> http://wiki.cocoondev.org/Wiki.jsp?page=OJBWithJDO
> 
> Later, I thought that the best approach was to use a common factory for
> all the servlet instead of using OJB directly.

I don't understand your objection here, maybe it's only a 
misinterpretation. We use a factory too that creates a specific DAO. But 
the usage of the DAO is completely independent on its implementation and 
so we don't use OJB directly neither.

>>But it won't be that difficult to switch the datasource back to
>>Avalon/Cocoon in OJB properties file.
> 
> 
> AFAIK, using OJB as an avalon component is better from an architectural
> view because it follow the same approach as the other components. AFAIK,
> we can also use other components outside Avalon schema, but this is rather
> not desired.

There are more layers that had to be made Avalon components. We decided 
to avoid this effort for the beginning.

>>BTW, we package all classes, configuration files and so on into our
>>application JAR, deploy it in WEB-INF/lib and it works without any
>>problem.
> 
> 
> I use 2 jar approach, one for beans and other for DAO. BTW, I prefer to
> call them "Handlers" because they are more or less oriented to handle data
> from/to CForms forms.

Might be again a misinterpretation but DAO do not stand in any relation 
to CForms. They handle just the the data access and so they are Data 
Access Objects.

> Instead of writing the code in Flow files, I prefer
> to use Flow just as a true controller (shorter files). It does not do the
> work just decide what to do with the recieved request.

Same here.

> To me Flow is just
> the controller that recieve request and decides where to send the beans to
> be processed.

For me the flow does not decide even this. The flow delegates a request 
to the business logic and gets and object at a specific place. This one 
the flow can bind to the form.

Joerg

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: woody, flow and database confusion

[Antonio Gallardo <ag...@agssa.net>]

Joerg Heinicke dijo:
> Hello Bert,
>
> it seems we went exactly the same route this week.

Great! I think I takes me 1 or 2 months while understanding how to start
all this puzzle and choicing between OJB and Hibernate and why + what if I
am wrong and this cannot work at all, also waiting for a more functional
Woody and Flow, and a couple of additional things, etc.! :-DD

In fact, I am glad to see the "path" being opened in mid 2003 now is clear
and other can use and improve the road. This was the main goal of OJB
block and I like to see that it is useful to other people. Share the ideas
with the community is great!

> Maybe we should put together our efforts to get this thing working and to
> help other people with a wiki page.

I will love this! I am sad that I cannot had the time to do this. I need
to tell I am newbie in OJB too. Maybe 1 or 2 days ahead in some cases, but
this is nothing. Of course we are trying to improve our knowledge and will
share it.

In short, please write the wiki page and I promise to review it and
improve it in case I know a little bit more. I will do it very glad.

> I only don't have that time til beginning of March because there is
> still an exam to be passed. So let me write a "short" mail about
> my experiences.
>
> We have at least our own application running with OJB. We can retrieve
> lists or single objects from the db and display them with Woody, we can
> store them back and delete them. We only have still a problem with
> object identity,

I think there is an old bug in JDO implementation in OJB related to
indetities. We fight with this problem 2 weeks with no results, then we
decided to switch to PB implementation. But let the open door to rewrote
the code when JDO will be avaliable.

> so that storing does indeed create a new object in db,
> but that's another problem we didn't have a closer look yesterday evening.
>
> We started also with OJB/JDO and had bad feelings when we saw that we
> have to maintain at least two files (package.jdo, repository.xml) to get
> it working. The reason for it is that JDO and OJB are two different
> products, OJB provides only a plugin for Sun JDO at the moment, but both
> must get their configuration. Though it's easy to write a stylesheet
> that converts one format into the other I tried to use only JDO.

While writing the code in Druid, I noted that repository.xml has far more
info that the .jdo onces.

In fact after querying on the OJB maillist I noted we don't need to put
too much info inside the .jdo. AFAIK, the only need info in .jdo is the
info that currently druid put on the .jdo files.

> But JDO is just the API, the SPI must be provided by the database
> vendor and as
> there are probably not that much for a specific at the moment, you need
> OJB. Then we found out that the JDO implementation has a performance
> problem: Retrieving 20 rows out of 6.000 in a db leads to instantiation
> of all 6.000 objects, they are filtered by JDO. That's not a problem of
> OJB, it's just how Sun JDO works. So we were back nearly to the
> beginning.

Hmm.. switching between JDO->(PB|OTM|ODMG) is not too painfull. This in
one of the best features of OJB at all.

> We decided to go on with OJB (as it allows easy switch
> between different persistence frameworks (JDO, ODMG, OTM, PB)), but used
> the OTM. This one provides also object level transaction.

> Now the application itself. I don't love the idea of accessing the
> persistence layer from the flow/controller layer directly. We access it
> only from the application layer to have obvious tiers. We have a
> DAOFactory that returns DAOs (e.g. either JDO or OTM), the
> implementation of the persistence framework access is abstracted.

We choosed to have DAO classes with static methods, that way we don't need
to create too many DAO objects. Between Flow and DAO classes fly the
Beans. Some of them are BeanList. They are easily passed to  the cforms
using the framework binding.

I am not sure if this is the best approach, but it works. I will be glad
if we can comment about what are the pros and the cons of Joerg approach
vs. this approach. I am not a Java or OO guru. Comments are very welcome.

> In
> theory we can switch to Castor, Hibernate or what else without touching
> the application layer.

Can you explain what is the application layer? I am confused here. Is the
application layer the view in the MVC paradigm?

> Each object specific DAO will provide different
> methods for retrieving, storing, deleting etc. As the layers below the
> flow layer are no Avalon components and not in relation to Cocoon, but
> "Plain Old Java" we kicked out Cocoon OJB block completely and just use
> OJB. If this was a good decision we will see.

I thought to do this too. In fact the first experiment was using directly
OJB in Cocoon:

http://wiki.cocoondev.org/Wiki.jsp?page=OJBWithJDO

Later, I thought that the best approach was to use a common factory for
all the servlet instead of using OJB directly.

> But it won't be that difficult to switch the datasource back to
> Avalon/Cocoon in OJB properties file.

AFAIK, using OJB as an avalon component is better from an architectural
view because it follow the same approach as the other components. AFAIK,
we can also use other components outside Avalon schema, but this is rather
not desired.

> BTW, we package all classes, configuration files and so on into our
> application JAR, deploy it in WEB-INF/lib and it works without any
> problem.

I use 2 jar approach, one for beans and other for DAO. BTW, I prefer to
call them "Handlers" because they are more or less oriented to handle data
from/to CForms forms. Instead of writing the code in Flow files, I prefer
to use Flow just as a true controller (shorter files). It does not do the
work just decide what to do with the recieved request. To me Flow is just
the controller that recieve request and decides where to send the beans to
be processed.

I am open to discuss this in more detail because it will be great to find
the best approach based on all our experiences. We are learning here and
will be fine to share our knowledges.

>From my POV, is a very important note that maybe we don't need avalon
based components in OJB block. But I think we need the block to show users
how this technology can be easily used inside Cocoon.

AFAIK Cocoon is: "web glue for your web application development needs" in
this way the OJB block is a key component for DB integration. :-D

Best Regards,

Antonio Gallardo

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: woody, flow and database confusion

[Joerg Heinicke <jo...@gmx.de>]

Hello Bert,

it seems we went exactly the same route this week. Maybe we should put 
together our efforts to get this thing working and to help other people 
with a wiki page. I only don't have that time til beginning of March 
because there is still an exam to be passed. So let me write a "short" 
mail about my experiences.

We have at least our own application running with OJB. We can retrieve 
lists or single objects from the db and display them with Woody, we can 
store them back and delete them. We only have still a problem with 
object identity, so that storing does indeed create a new object in db, 
but that's another problem we didn't have a closer look yesterday evening.

The way to this was long and stony, so you are not the only one :)

We started also with OJB/JDO and had bad feelings when we saw that we 
have to maintain at least two files (package.jdo, repository.xml) to get 
it working. The reason for it is that JDO and OJB are two different 
products, OJB provides only a plugin for Sun JDO at the moment, but both 
must get their configuration. Though it's easy to write a stylesheet 
that converts one format into the other I tried to use only JDO. But JDO 
is just the API, the SPI must be provided by the database vendor and as 
there are probably not that much for a specific at the moment, you need 
OJB. Then we found out that the JDO implementation has a performance 
problem: Retrieving 20 rows out of 6.000 in a db leads to instantiation 
of all 6.000 objects, they are filtered by JDO. That's not a problem of 
OJB, it's just how Sun JDO works. So we were back nearly to the 
beginning. We decided to go on with OJB (as it allows easy switch 
between different persistence frameworks (JDO, ODMG, OTM, PB)), but used 
the OTM. This one provides also object level transaction.

Now the application itself. I don't love the idea of accessing the 
persistence layer from the flow/controller layer directly. We access it 
only from the application layer to have obvious tiers. We have a 
DAOFactory that returns DAOs (e.g. either JDO or OTM), the 
implementation of the persistence framework access is abstracted. In 
theory we can switch to Castor, Hibernate or what else without touching 
the application layer. Each object specific DAO will provide different 
methods for retrieving, storing, deleting etc. As the layers below the 
flow layer are no Avalon components and not in relation to Cocoon, but 
"Plain Old Java" we kicked out Cocoon OJB block completely and just use 
OJB. If this was a good decision we will see. But it won't be that 
difficult to switch the datasource back to Avalon/Cocoon in OJB 
properties file.

BTW, we package all classes, configuration files and so on into our 
application JAR, deploy it in WEB-INF/lib and it works without any problem.

Joerg


On 18.02.2004 12:15, Bert Van Kets wrote:
> I have been trying for several days to get grips on the "super trio" Woody,
> Flow and OJB/JDO. I don't have any succes yet, but that is mainly to the
> complexity of getting OJB/JDO to run. Could someone please shed a light on
> this to get me going again?
> 
> I have created a bean to store all form data. The Woody form and the
> FlowScipt have been created too. I have used the obj/woody sample as a
> template to get things running. That's the easy part (relatively speaking).
> I'm using mySQL as a databasource and have a datasource configured in
> cocoon.xconf. This datasource is used in XSP pages using ESQL without any
> problem, so that works for sure.
> My biggest confusion is where I need to configure the link from the bean
> datastore to the database. Where do I configure OJB and JDO?
> I have OJB.properties, package.jdo, repository.dtd and repository.xml in the
> WEB-INF/classes directory. I see a total overlap in the configuration in the
> package.jdo and repository.xml file. Why is that? Is either of them not
> needed?
> 
> I have created a DAO class file too. This is a direct copy of the
> Employee_DAO class file from the samples. I only replaced the package and
> replaced the bean methods with the ones from my bean. All this compiles
> without any problem. The bean and the DAO class are packaged in a jar file
> and put in the WEB-INF lib directory. I assume this is where I will
> eventually create queries using OJB code to fill the bean with data. Am I
> correct?
> 
> Thanks a lot for any help,
> Bert

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org