You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Bert Van Kets <be...@vankets.com> on 2004/02/20 15:12:18 UTC
building Collection from JDO problems
Using Cocoon 2.1.4 with Woody, flow and JDO
I have a bean containing a Collection to build an editable list with woody.
If I fill the Bean manually, everything is displayed properly without any
problems, but as soon as I try to fill the bean using JDO I get errors. I
have tried all kinds of things, read a zillion docs, but can't figure out
what's srong. :-(
Here's a snip from my flow:
var linksBean = new Packages.be.bvar.admin.links.LinksBean();
var dao = new Packages.be.bvar.admin.links.LinksDAO();
dao.retrieve(linksBean, factory);
And here's the code I use to fill the Collection:
public void retrieve(LinksBean bean, JdoPMF pmf) {
/* 1. Get the PersistenceManager */
PersistenceManager persistenceManager = pmf.getPersistenceManager();
System.out.println("persistanceManager instantiated");
// 2. start transaction
persistenceManager.currentTransaction().begin();
Query query = persistenceManager.newQuery(Link.class);
Collection thisCollection = (Collection) query.execute();
System.out.println("collection = " + thisCollection);
bean.setLinks(thisCollection);
System.out.println();
System.out.println(bean);
// 3. End transaction
persistenceManager.currentTransaction().commit();
}
The error I get is
ConversionError: The undefined value has no properties.
(file:/D:/java/projects/bvar/links/linkFlow.js; line 12)
Line 12 is where dao.retrieve is called.
Full stack trace is below.
I'm certain the LinkDAO class can be found. The class in the same directory
as the LinksBean class, which is instantiated perfectly.
What can be wrong here? Am I retreiving the Collection teh wrong way???
Please advise. :-/
Bert
Original Exception: ConversionError: The undefined value has no properties.
(file:/D:/java/projects/bvar/links/linkFlow.js; line 12)
at
org.mozilla.javascript.NativeGlobal.constructError(NativeGlobal.java:581)
at
org.mozilla.javascript.NativeGlobal.constructError(NativeGlobal.java:541)
at org.mozilla.javascript.ScriptRuntime.getProp(ScriptRuntime.java:716)
at
org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(Conti
nuationInterpreter.java:677)
at
org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(Conti
nuationInterpreter.java:190)
at
org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(Conti
nuationInterpreter.java:138)
at
org.mozilla.javascript.continuations.InterpretedFunctionImpl.call(Interprete
dFunctionImpl.java:121)
at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.c
allFunction(FOM_JavaScriptInterpreter.java:719)
at
org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(C
allFunctionNode.java:160)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:84)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invok
e(PreparableMatchNode.java:165)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:107)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipel
ineNode.java:162)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:107)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pipe
linesNode.java:136)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
or.java:371)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
or.java:312)
at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNod
e.java:133)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:84)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invok
e(PreparableMatchNode.java:165)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:107)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipel
ineNode.java:162)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:107)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pipe
linesNode.java:136)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
or.java:371)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
or.java:312)
at org.apache.cocoon.Cocoon.process(Cocoon.java:656)
at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1112)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:256)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2417)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180
)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.
java:171)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172
)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:193)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:781)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
ction(Http11Protocol.java:549)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:589)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:666)
at java.lang.Thread.run(Thread.java:479)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: building Collection from JDO problems
Posted by Antonio Gallardo <ag...@agssa.net>.
Neil Bacon dijo:
> Antonio,
> your quote from the JDO spec does not imply that the JDO objects
> contained in the Collection returned by a query are unmodifiable.
> You can't add and remove elements from the Collection, but you can
> update the fields of the JDO objects it contains (and have JDO
> update the database accordingly).
Hi Neil:
Maybe you are right, but in the first test I did in mid last year the Sun
reference implementation (maybe JDO 1.0) trows the exception even if I
tried to change a field inside any of the returned Beans of the
collection.
I don't tested it again in Sun reference implementation JDO 1.01.
Best Regards,
Antonio Gallardo.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: building Collection from JDO problems
Posted by Antonio Gallardo <ag...@agssa.net>.
Stefan Klein dijo:
> Hi Bert,
>
>> Does the problem with object identities mean that OJB is not the right
>> way to go when building forms that display editable lists? If that is
>> that case I lost quite a lot of time just trying to find an quicker way
>> to build web forms.
>> What are the limitiations of OJB exactly?
>
> thought I'd point this out to you, since it cost me a lot of time and I
> still haven't solved it in a satisfying way. AFAIK, there is a bug in the
> current OJB release rc5 with the use of javax.jdo.Query (as you use in
> your retrieve method). The objects in the collection it returns are
> actually not persistent as they should be.
Later I remeber about this issue and in fact this is not a bug!
>From the JDO 1.01 specification (page 109):
<snip>
14.6.1 Query Execution
The Query interface provides methods that execute the query based on the
parameters given. They return an UNMODIFIABLE Collection wich the user can
iterate to get results.
Executing ANY operation on the Collection that might change it throws
UnsupportedOperationException. For future extension, the signature of the
execute methods specifies that they return an Object that must be cast to
Collection by user.
</snip>
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: building Collection from JDO problems
Posted by Antonio Gallardo <ag...@agssa.net>.
Stefan Klein dijo:
> Hi Bert,
>
>> Does the problem with object identities mean that OJB is not the right
>> way to go when building forms that display editable lists? If that is
>> that case I lost quite a lot of time just trying to find an quicker way
>> to build web forms.
>> What are the limitiations of OJB exactly?
>
> thought I'd point this out to you, since it cost me a lot of time and I
> still haven't solved it in a satisfying way. AFAIK, there is a bug in the
> current OJB release rc5 with the use of javax.jdo.Query (as you use in
> your retrieve method). The objects in the collection it returns are
> actually not persistent as they should be. The nasty implication is:
> You retrieve a collection, you edit it via your form. You call
> transaction.commit() and the database doesn't get updated!
> The only way to retrieve a persistent object is by using
> getObjectByIdentity (or something like that) like they do in the JDO
> tutorial on the OJB site.
>
> They recently fixed the bug (get the latest CVS HEAD and compile it
> yourself),
Done. It is in the Cocoon CVS right now.
> For the moment, I actually gave up on OJB-JDO after spending a lot of
> time on it and just use the OJB PersistenceBroker-API which so far works
> perfectly and reliably for my relatively small persistence needs.
I think it is a good start. I am using PB right now. Because the same
problems.
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: building Collection from JDO problems
Posted by Stefan Klein <kl...@web.de>.
Hi Bert,
> Does the problem with object identities mean that OJB is not the right
> way to go when building forms that display editable lists? If that is
> that case I lost quite a lot of time just trying to find an quicker way
> to build web forms.
> What are the limitiations of OJB exactly?
thought I'd point this out to you, since it cost me a lot of time and I
still haven't solved it in a satisfying way. AFAIK, there is a bug in the
current OJB release rc5 with the use of javax.jdo.Query (as you use in
your retrieve method). The objects in the collection it returns are
actually not persistent as they should be. The nasty implication is:
You retrieve a collection, you edit it via your form. You call
transaction.commit() and the database doesn't get updated!
The only way to retrieve a persistent object is by using
getObjectByIdentity (or something like that) like they do in the JDO
tutorial on the OJB site.
They recently fixed the bug (get the latest CVS HEAD and compile it
yourself), however, I am still running into a problem: I have got an
object of class User that contains a field roles that is a collection of
Role objects. When I retrieve a collection of User objects via Query, the
respective Role objects are retrieved with them automatically. The users
are persistent as they should be (thanks to the bug being fixed), the
connected roles however still aren't. So by the time you commit, OJB
tries to re-create the roles in the database and you get duplicate key
errors. I haven't had the time yet to ask the OJB people about it.
This is not to do with your current problems, but I thought I'd point it
out to you before you run into it.
For the moment, I actually gave up on OJB-JDO after spending a lot of
time on it and just use the OJB PersistenceBroker-API which so far works
perfectly and reliably for my relatively small persistence needs.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: building Collection from JDO problems
Posted by Bert Van Kets <be...@vankets.com>.
> AFAIK, the problem is that you need to JDO "enhance" your classes. See the
> build.xml that Druid did for you. Also remeber you need to use jdo 1.01
> NOT jdo 1.00
>
OK, more reading to do. I haven't touched Druid yet (I think). I'll try that
today.
I am using 1.01. I read that on the JDOand OJB Wiki page.
Does the problem with object identities mean that OJB is not the right way
to go when building forms that display editable lists? If that is that case
I lost quite a lot of time just trying to find an quicker way to build web
forms.
What are the limitiations of OJB exactly?
Plese keep in mind that all of this is VERY new to me.
Regards,
Bert
> Best Regards,
>
> Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: building Collection from JDO problems
Posted by Joerg Heinicke <jo...@gmx.de>.
On 22.02.2004 15:24, Bert Van Kets wrote:
> Antonio,
> I got Druid to run, imported my databse, configured the JDO generation and
> got the build.xml file you speak of. It took me a bit longer than it souncs
> though.
> Then I copied jdo 1.01 libraries (double checked the version) to the lib
> directory in my output dir and built.
> The class file is enhanced as mentioned by Ant.
> I removed the old link class from my webapp and copied the new jar file
> over.
> But when I use this generated library I still get the same error.
> javax.jdo.JDOUserException: Class given to getExtent,
> be.bvar.admin.links.Link, does not implement
> javax.jdo.spi.PersistenceCapable
AFAIK this only means that the class has not been enhanced. Are you sure
that Ant told you they are enhanced? Just 'done' is not enough. Switch
to verbose mode (-v as additional argument to the jdo enhancing task)
and you will see if the classes are enhanced successfully or not.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: building Collection from JDO problems
Posted by Bert Van Kets <be...@vankets.com>.
> Instead, try to use OJB-PB (PersistenceBroker). Yesterday, I extended
> Cocoon CVS to allow the use of PBFactory.
>
> Currently, seems like the JDO implementation in OJB is broken. The
> persistence broker is stable and can be used. You can very easy switch to
> PB. For a tutorial see:
>
> http://db.apache.org/ojb/pb-tutorial.html
>
> WDYT?
Thanks for the tip and help.
I'll spend this evening trying to get my "link test app" working with
OJB-PB. If I succeed, I'll go this way. I don't have any more spare time in
this project to learn all this neat stuff.
I'm happy I can use flow and woody. That's already a big help. At least it
takes away the repetition in web form building.
As you might have guessed, I'm pretty new at all this stuff and still have
quite a long way to go, but I'm determined to get there. My personal web
site (http://www.dream-models.com) will become commercial soon and that
allone is worth investing the time. I guess I'll have to move it from the
Forrest built sites to the Cocoon built sites list then. :-)
I also hope it will allow me to give something back to the community.
Bert
>
> Best Regards,
>
> Antonio Gallardo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: building Collection from JDO problems
Posted by Antonio Gallardo <ag...@agssa.net>.
Bert Van Kets dijo:
> I am on the verge of throwing this whole thing out and using plain jdbc
> connections in my bean. :-(
I know it can be frustrating sometimes. But going back to plain jdbc is
not a good move. ;-)
Instead, try to use OJB-PB (PersistenceBroker). Yesterday, I extended
Cocoon CVS to allow the use of PBFactory.
Currently, seems like the JDO implementation in OJB is broken. The
persistence broker is stable and can be used. You can very easy switch to
PB. For a tutorial see:
http://db.apache.org/ojb/pb-tutorial.html
WDYT?
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: building Collection from JDO problems
Posted by Bert Van Kets <be...@vankets.com>.
Antonio,
I got Druid to run, imported my databse, configured the JDO generation and
got the build.xml file you speak of. It took me a bit longer than it souncs
though.
Then I copied jdo 1.01 libraries (double checked the version) to the lib
directory in my output dir and built.
The class file is enhanced as mentioned by Ant.
I removed the old link class from my webapp and copied the new jar file
over.
But when I use this generated library I still get the same error.
javax.jdo.JDOUserException: Class given to getExtent,
be.bvar.admin.links.Link, does not implement
javax.jdo.spi.PersistenceCapable
I am on the verge of throwing this whole thing out and using plain jdbc
connections in my bean. :-(
Bert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: building Collection from JDO problems
Posted by Antonio Gallardo <ag...@agssa.net>.
Hi Bert:
It looks like a table game :-)
Well you went to the next step and you are faced with the next trivia :-D
AFAIK, the problem is that you need to JDO "enhance" your classes. See the
build.xml that Druid did for you. Also remeber you need to use jdo 1.01
NOT jdo 1.00
Best Regards,
Antonio Gallardo
Bert Van Kets dijo:
> And the woes continue... :-(
>
> The LinkDAO class is now instantiated, but when I get to building the
> Query
> I get an error saying I don't implement javax.jdo.spi.persistenceCapable
> on
> the class used for putting data in my collection. No document references
> the
> need for a persistanceCapable implementation in this situation.
> Full stack trace below.
>
> When debugging in Eclipse, javaw.exe (Tomcat) even throws me a bug crash.
>
> Here's the code again I use to retreive the data. Am I missing a step? The
> OJB docs don't tell me a lot. :-/
>
> public void retrieve(LinksBean bean, JdoPMF pmf) {
> /* 1. Get the PersistenceManager */
> PersistenceManager persistenceManager = pmf.getPersistenceManager();
> // 2. start transaction
> persistenceManager.currentTransaction().begin();
> Query query = persistenceManager.newQuery(Link.class);
> Collection thisCollection = (Collection) query.execute();
> bean.setLinks(thisCollection);
> // 3. End transaction
> persistenceManager.currentTransaction().commit();
> }
>
> Any help is appreciated.
>
> Bert
>
> Original Exception: javax.jdo.JDOUserException: Class given to getExtent,
> be.bvar.admin.links.Link, does not implement
> javax.jdo.spi.PersistenceCapable
> at com.sun.jdori.common.PersistenceManagerImpl.getExtent(Unknown Source)
> at com.sun.jdori.common.query.QueryImpl.checkCandidates(Unknown Source)
> at com.sun.jdori.common.query.QueryImpl.execute(Unknown Source)
> at be.bvar.admin.links.LinksDAO.retrieve(LinksDAO.java:26)
> at java.lang.reflect.Method.invoke(Native Method)
> at
> org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:230)
> at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244)
> at
> org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(Conti
> nuationInterpreter.java:1105)
> at
> org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(Conti
> nuationInterpreter.java:190)
> at
> org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(Conti
> nuationInterpreter.java:138)
> at
> org.mozilla.javascript.continuations.InterpretedFunctionImpl.call(Interprete
> dFunctionImpl.java:121)
> at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244)
> at
> org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.c
> allFunction(FOM_JavaScriptInterpreter.java:719)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(C
> allFunctionNode.java:160)
> at
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
> keNodes(AbstractParentProcessingNode.java:84)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invok
> e(PreparableMatchNode.java:165)
> at
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
> keNodes(AbstractParentProcessingNode.java:107)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipel
> ineNode.java:162)
> at
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
> keNodes(AbstractParentProcessingNode.java:107)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pipe
> linesNode.java:136)
> at
> org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
> or.java:371)
> at
> org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
> or.java:312)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNod
> e.java:133)
> at
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
> keNodes(AbstractParentProcessingNode.java:84)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invok
> e(PreparableMatchNode.java:165)
> at
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
> keNodes(AbstractParentProcessingNode.java:107)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipel
> ineNode.java:162)
> at
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
> keNodes(AbstractParentProcessingNode.java:107)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pipe
> linesNode.java:136)
> at
> org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
> or.java:371)
> at
> org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
> or.java:312)
> at org.apache.cocoon.Cocoon.process(Cocoon.java:656)
> at
> org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1112)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
> FilterChain.java:247)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
> ain.java:193)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
> va:256)
> at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
> eNext(StandardPipeline.java:643)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
> va:191)
> at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
> eNext(StandardPipeline.java:643)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> at
> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2417)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180
> )
> at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
> eNext(StandardPipeline.java:643)
> at
> org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.
> java:171)
> at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
> eNext(StandardPipeline.java:641)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172
> )
> at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
> eNext(StandardPipeline.java:641)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
> :174)
> at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
> eNext(StandardPipeline.java:643)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> at
> org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:193)
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:781)
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
> ction(Http11Protocol.java:549)
> at
> org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:589)
> at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
> a:666)
> at java.lang.Thread.run(Thread.java:479)
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: building Collection from JDO problems
Posted by Bert Van Kets <be...@vankets.com>.
And the woes continue... :-(
The LinkDAO class is now instantiated, but when I get to building the Query
I get an error saying I don't implement javax.jdo.spi.persistenceCapable on
the class used for putting data in my collection. No document references the
need for a persistanceCapable implementation in this situation.
Full stack trace below.
When debugging in Eclipse, javaw.exe (Tomcat) even throws me a bug crash.
Here's the code again I use to retreive the data. Am I missing a step? The
OJB docs don't tell me a lot. :-/
public void retrieve(LinksBean bean, JdoPMF pmf) {
/* 1. Get the PersistenceManager */
PersistenceManager persistenceManager = pmf.getPersistenceManager();
// 2. start transaction
persistenceManager.currentTransaction().begin();
Query query = persistenceManager.newQuery(Link.class);
Collection thisCollection = (Collection) query.execute();
bean.setLinks(thisCollection);
// 3. End transaction
persistenceManager.currentTransaction().commit();
}
Any help is appreciated.
Bert
Original Exception: javax.jdo.JDOUserException: Class given to getExtent,
be.bvar.admin.links.Link, does not implement
javax.jdo.spi.PersistenceCapable
at com.sun.jdori.common.PersistenceManagerImpl.getExtent(Unknown Source)
at com.sun.jdori.common.query.QueryImpl.checkCandidates(Unknown Source)
at com.sun.jdori.common.query.QueryImpl.execute(Unknown Source)
at be.bvar.admin.links.LinksDAO.retrieve(LinksDAO.java:26)
at java.lang.reflect.Method.invoke(Native Method)
at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:230)
at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244)
at
org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(Conti
nuationInterpreter.java:1105)
at
org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(Conti
nuationInterpreter.java:190)
at
org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(Conti
nuationInterpreter.java:138)
at
org.mozilla.javascript.continuations.InterpretedFunctionImpl.call(Interprete
dFunctionImpl.java:121)
at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.c
allFunction(FOM_JavaScriptInterpreter.java:719)
at
org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(C
allFunctionNode.java:160)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:84)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invok
e(PreparableMatchNode.java:165)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:107)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipel
ineNode.java:162)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:107)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pipe
linesNode.java:136)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
or.java:371)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
or.java:312)
at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNod
e.java:133)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:84)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invok
e(PreparableMatchNode.java:165)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:107)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipel
ineNode.java:162)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:107)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pipe
linesNode.java:136)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
or.java:371)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
or.java:312)
at org.apache.cocoon.Cocoon.process(Cocoon.java:656)
at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1112)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:256)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2417)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180
)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.
java:171)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172
)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:193)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:781)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
ction(Http11Protocol.java:549)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:589)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:666)
at java.lang.Thread.run(Thread.java:479)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: building Collection from JDO problems
Posted by Bert Van Kets <be...@vankets.com>.
> I saw in your flow script:
>
> var dao = new Packages.be.bvar.admin.links.LinksDAO();
>
> but in your Java file:
>
> public class linksDAO {
>
> Just a typo?
>
No, it is not a typo and probably the reason why I have this problem.
I'm not going to repeat what I was just shouting, but it wasn't pretty.
Like always, the problems that are the most difficult to solve are the most
stupid problems made.
I still have to test it, but I'm sure this is at least one problem solved.
I'll see where I get now. I have another obligation at the moment (family).
Thanks a lot all for your help and explanation. I will type out (a) step by
step Wiki page(s) to explain on how to set up Flow/Woody/OJB. There's no
need for other people to go through my ordeal (even though they probably
won't make the same stupid error as I made).
Bert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: building Collection from JDO problems
Posted by Joerg Heinicke <jo...@gmx.de>.
On 21.02.2004 15:24, Bert Van Kets wrote:
>>This is not really a JDO problem this is a Flow problem that cannot find
>>the right Java class.
>
> Aparently. And it has me scratching my head for several days now.
Just a "clever" comment: Before having the flow problem (instantiation
of Java classes) fixed I would not go on one step with the persistence
layer.
I saw in your flow script:
var dao = new Packages.be.bvar.admin.links.LinksDAO();
but in your Java file:
public class linksDAO {
Just a typo?
>>>And here is the class descriptor from the repository.xml file :
>>><class-descriptor class="be.bvar.admin.links.Links" table="links">
>>
>>This class is diferent from the LinksBean. Why you are using 2 diferent
>>classes? Any way here is not the problem.
>
> From my understanding, the structure of the repository node must match the
> class in which you load the data. As I have Link classes in a Collection (in
> the LinksBean class), each containing one record of data, I thought the
> repository has to point to the Link class and not to the bean containing the
> Collection.
That's correct, you just fill the LinksBean. Link is the class you
retrieve form db and so absolutely ok.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: building Collection from JDO problems
Posted by Bert Van Kets <be...@vankets.com>.
> Hint: Set the above line in sitemap to avoid writing it over and over:
OK, did that. It does indeed make life easier in the long run. :-)
>
> When dao will got a right Object, the above line will print something
like:
>
> dao=be.bvar.admin.links.LinksDAO@11492ed
>
> but you got dao=undefined
right
> So this means you are not getting the right object. Flow is not able to
> got it. Can you tell where are you deploying be.bvar.admin.links.LinksDAO?
>
> Please write the full dir structure you are using in WEB-INF/classes.
Here's the full path to the class file :
D:\java\projects\bvar\WEB-INF\classes\be\bvar\admin\links
D:\java\projects\bvar is where my project resides. The class file is clearly
there.
> This is not really a JDO problem this is a Flow problem that cannot find
> the right Java class.
Aparently. And it has me scratching my head for several days now.
> >
> > And here is the class descriptor from the repository.xml file :
> > <class-descriptor class="be.bvar.admin.links.Links" table="links">
> ^^^^^
>
> This class is diferent from the LinksBean. Why you are using 2 diferent
> classes? Any way here is not the problem.
>From my understanding, the structure of the repository node must match the
class in which you load the data. As I have Link classes in a Collection (in
the LinksBean class), each containing one record of data, I thought the
repository has to point to the Link class and not to the bean containing the
Collection.
Bert
>
> Best Regards,
>
> Antonio Gallardo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: building Collection from JDO problems
Posted by Antonio Gallardo <ag...@agssa.net>.
Bert Van Kets dijo:
> Here is my flowscript. In this form it fails on dao.retrieve(linksBean,
> factory); because dao is undefined.
>
> cocoon.load("resource://org/apache/cocoon/woody/flow/javascript/woody2.js");
Hint: Set the above line in sitemap to avoid writing it over and over:
<map:flow language="javascript">
<map:script
src="resource://org/apache/cocoon/woody/flow/javascript/woody2.js"/>
<!-- Here put other scripts,
you can include many script as you want.
I prefer to put in 1 file related functions for one operation
-->
</map:flow>
> function linksForm_JDO(form) {
> // Get OJB factory
> var factory =
> cocoon.getComponent(Packages.org.apache.cocoon.ojb.jdo.components.JdoPMF.ROL
> E);
> // Create a empty Bean
> var linksBean = new Packages.be.bvar.admin.links.LinksBean();
^^^^^^^^^^^
Not showed, but I guess it exists. Anyway this is not the problem.
> var dao = new Packages.be.bvar.admin.links.LinksDAO();
> cocoon.log.error("dao =" + dao);
When dao will got a right Object, the above line will print something like:
dao=be.bvar.admin.links.LinksDAO@11492ed
but you got dao=undefined
So this means you are not getting the right object. Flow is not able to
got it. Can you tell where are you deploying be.bvar.admin.links.LinksDAO?
Please write the full dir structure you are using in WEB-INF/classes.
This is not really a JDO problem this is a Flow problem that cannot find
the right Java class.
> And here is the DAO class (I took the update method out to minimise teh
> possible problems) :
OK. :-D
> package be.bvar.admin.links;
> import java.util.Collection;
> import javax.jdo.PersistenceManager;
> import javax.jdo.Query;
> import org.apache.cocoon.ojb.jdo.components.JdoPMF;
> /**
> * @author BeKe
> *
> */
> public class linksDAO {
> public void retrieve(LinksBean bean, JdoPMF pmf) {
> /* 1. Get the PersistenceManager */
> PersistenceManager persistenceManager =
> pmf.getPersistenceManager();
> // 2. start transaction
> persistenceManager.currentTransaction().begin();
> Query query =
> persistenceManager.newQuery(be.bvar.admin.links.Link.class);
> Collection thisCollection = (Collection) query.execute();
> bean.setLinks(thisCollection);
> // 3. End transaction
> persistenceManager.currentTransaction().commit();
> }
> }
>
> And here is the class descriptor from the repository.xml file :
> <class-descriptor class="be.bvar.admin.links.Links" table="links">
^^^^^
This class is diferent from the LinksBean. Why you are using 2 diferent
classes? Any way here is not the problem.
> <field-descriptor name="ID" column="ID" jdbc-type="INTEGER"
> primarykey="true"/>
> <field-descriptor name="url" column="url" jdbc-type="VARCHAR"/>
> <field-descriptor name="titel" column="title" jdbc-type="VARCHAR"/>
> <field-descriptor name="description" column="description"
> jdbc-type="VARCHAR"/>
> </class-descriptor>
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: building Collection from JDO problems
Posted by Bert Van Kets <be...@vankets.com>.
Here is my flowscript. In this form it fails on dao.retrieve(linksBean,
factory); because dao is undefined.
cocoon.load("resource://org/apache/cocoon/woody/flow/javascript/woody2.js");
function linksForm_JDO(form) {
// Get OJB factory
var factory =
cocoon.getComponent(Packages.org.apache.cocoon.ojb.jdo.components.JdoPMF.ROL
E);
// Create a empty Bean
var linksBean = new Packages.be.bvar.admin.links.LinksBean();
var dao = new Packages.be.bvar.admin.links.LinksDAO();
cocoon.log.error("dao =" + dao);
dao.retrieve(linksBean, factory);
// Load the Bean to the form
form.load(linksBean);
// Let woody handle the form
form.showForm("links-form-display");
// Update the Bean based on user input
form.save(linksBean);
// Update Bean in Database
//dao.update(linksBean, factory);
// Clean up the operation
cocoon.releaseComponent(factory);
// Send response to the user
cocoon.request.setAttribute("linksForm", form.getWidget());
cocoon.sendPage("links-success-pipeline");
}
And here is the DAO class (I took the update method out to minimise teh
possible problems) :
package be.bvar.admin.links;
import java.util.Collection;
import javax.jdo.PersistenceManager;
import javax.jdo.Query;
import org.apache.cocoon.ojb.jdo.components.JdoPMF;
/**
* @author BeKe
*
*/
public class linksDAO {
public void retrieve(LinksBean bean, JdoPMF pmf) {
/* 1. Get the PersistenceManager */
PersistenceManager persistenceManager = pmf.getPersistenceManager();
// 2. start transaction
persistenceManager.currentTransaction().begin();
Query query =
persistenceManager.newQuery(be.bvar.admin.links.Link.class);
Collection thisCollection = (Collection) query.execute();
bean.setLinks(thisCollection);
// 3. End transaction
persistenceManager.currentTransaction().commit();
}
}
And here is the class descriptor from the repository.xml file :
<class-descriptor class="be.bvar.admin.links.Links" table="links">
<field-descriptor name="ID" column="ID" jdbc-type="INTEGER"
primarykey="true"/>
<field-descriptor name="url" column="url" jdbc-type="VARCHAR"/>
<field-descriptor name="titel" column="title" jdbc-type="VARCHAR"/>
<field-descriptor name="description" column="description"
jdbc-type="VARCHAR"/>
</class-descriptor>
Thansk again for your help!!
Bert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: building Collection from JDO problems
Posted by Antonio Gallardo <ag...@agssa.net>.
Bert Van Kets dijo:
>> Are you jaring the DAO classes?
> No, just compiling them in the classes folder in the right package
> directory. I tried to jar them at first, but then none of them were found.
This is weird! How jaring is not avaliable. In my devel environment I use
eclipse + ant to build a jar with my DAO classes that is then copied to
WEB-INF/lib directory of my Cocoon app. After this I need to reboot
tomcat.
This way I did it hundreds if not thousands of times while developing my
current work.
Are you tried to investigate why your classes packaged in a jar are not
seeing by Cocoon. I think this is the root of the problem.
>>Are the classes visibles at all?
> Aparently not in the Cocoon package.
> I did a print(dao) in the flowscript and it returns "undefind"
> Your system, writing to the log, has the same message. Printing to the
> console is a little easier int his case as I don't have to shut down
> Tomcat
> to open the log file. Freaking MS. :-(
No problem :-D
>
>
>> To help me know if this variable is empty or not.
> Aparently it not. :-(
Yes. It is empty, because you got "undefined" that means the variable
don't got any value.
Can you send again the javascript code? Please don't snip, because the
problem can be related where you define the variable and where you use it.
This is why I prefer to write the code in Java and not in Javascript. I
will be glad to have a similar IDE as eclipse for Javascript. ;-)
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: building Collection from JDO problems
Posted by Bert Van Kets <be...@vankets.com>.
> Are you jaring the DAO classes?
No, just compiling them in the classes folder in the right package
directory. I tried to jar them at first, but then none of them were found.
>Where are you puting this classes?
see above
>Are the classes visibles at all?
Aparently not in the Cocoon package.
I did a print(dao) in the flowscript and it returns "undefind"
Your system, writing to the log, has the same message. Printing to the
console is a little easier int his case as I don't have to shut down Tomcat
to open the log file. Freaking MS. :-(
> To help me know if this variable is empty or not.
Aparently it not. :-(
Hence my question in my previous mail.
Bert
>
> Best Regards,
>
> Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: building Collection from JDO problems
Posted by Antonio Gallardo <ag...@agssa.net>.
Bert Van Kets dijo:
> What is are the possible reasons for flowscript to have an "undefined"
> when
> instatiating a class (creating a variable out of the Package)?
> This is the line of code I use in the flow:
> var dao = new Packages.be.bvar.admin.links.LinksDAO();
Are you jaring the DAO classes? Where are you puting this classes? Are the
classes visibles at all? I often add a line:
cocoon.log.error("dao =" + dao);
To help me know if this variable is empty or not.
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: building Collection from JDO problems
Posted by Bert Van Kets <be...@vankets.com>.
I have Tomcat running in Eclipse and can debug my own Java classes, that's
no problem at all. Thanks for the suggestion though. :-D
It seems I don't even get to the DAO class. :-(
I have tried to debug the fluscript, but see that I don't even get into the
DAO class. Aparently when I instatiate the DAO class it appears to be
"undefined". Now I'm totally baffled as I see no reason what so ever why
this could be.
The class can certainly be found. It's in the classes directory in the same
package as my bean, which is fuond without any problem. Eclipse compiles teh
DAO class without any errors. :-/
What is are the possible reasons for flowscript to have an "undefined" when
instatiating a class (creating a variable out of the Package)?
This is the line of code I use in the flow:
var dao = new Packages.be.bvar.admin.links.LinksDAO();
Thanks,
Bert
----- Original Message -----
From: "Antonio Gallardo" <ag...@agssa.net>
To: <us...@cocoon.apache.org>
Sent: Saturday, February 21, 2004 11:16 AM
Subject: Re: building Collection from JDO problems
> Bert Van Kets dijo:
> >>
> >> Hmm. I think it is not a good idea to have a list as a bean in the
> >> repository.xml. My approach is similar as yours but in the
> >> repository.xml
> >> there are beans not lists of beans.
> >>
> >
> > Sorry for the confusion.
> > I meant that I created a class called Link containing integers and
strings
> > to fill the Collection in the bean called LinksBean. I don't see what's
> > wrong with this approach. After all, this is how it's done in several
> > samples. The only thing I am trying to do here is to fill the bean using
> > ojb.
> >
> > Right now, I'm trying to get Rhino Debugger running so that I can have a
> > peak in the instantiation of the objects in the Flow.
>
> You can also use eclipse.org to debug your Cocoon servlet:
>
> http://wiki.cocoondev.org/Wiki.jsp?page=DebuggingCocoon
>
> It would help inside the Java DAO class. Remember to put a breakpoint
> inside the DAO class.
>
> Best Regards,
>
> Antonio Gallardo.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: building Collection from JDO problems
Posted by Antonio Gallardo <ag...@agssa.net>.
Bert Van Kets dijo:
>>
>> Hmm. I think it is not a good idea to have a list as a bean in the
>> repository.xml. My approach is similar as yours but in the
>> repository.xml
>> there are beans not lists of beans.
>>
>
> Sorry for the confusion.
> I meant that I created a class called Link containing integers and strings
> to fill the Collection in the bean called LinksBean. I don't see what's
> wrong with this approach. After all, this is how it's done in several
> samples. The only thing I am trying to do here is to fill the bean using
> ojb.
>
> Right now, I'm trying to get Rhino Debugger running so that I can have a
> peak in the instantiation of the objects in the Flow.
You can also use eclipse.org to debug your Cocoon servlet:
http://wiki.cocoondev.org/Wiki.jsp?page=DebuggingCocoon
It would help inside the Java DAO class. Remember to put a breakpoint
inside the DAO class.
Best Regards,
Antonio Gallardo.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: building Collection from JDO problems
Posted by Bert Van Kets <be...@vankets.com>.
>
> Hmm. I think it is not a good idea to have a list as a bean in the
> repository.xml. My approach is similar as yours but in the repository.xml
> there are beans not lists of beans.
>
Sorry for the confusion.
I meant that I created a class called Link containing integers and strings
to fill the Collection in the bean called LinksBean. I don't see what's
wrong with this approach. After all, this is how it's done in several
samples. The only thing I am trying to do here is to fill the bean using
ojb.
Right now, I'm trying to get Rhino Debugger running so that I can have a
peak in the instantiation of the objects in the Flow.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: building Collection from JDO problems
Posted by Antonio Gallardo <ag...@agssa.net>.
Bert Van Kets dijo:
> Antonio,
> thanks for the help.
> The funny thing is everything worked fine getting one record. I used the
> ojb sample and modified that to use my database and table.
> I then tried to modify the bean and DAO class to return a collection
> instead is strings and integers so I can build a list instead of
> a simple record.
> The Collection is filled with classes of the same structure as the
> original
> bean. I also modified the repository.xml file to point to the new class
> instead of the bean.
Hmm. I think it is not a good idea to have a list as a bean in the
repository.xml. My approach is similar as yours but in the repository.xml
there are beans not lists of beans.
> Of course the form was adjusted to accept the Collection and return the
> different records.
> When I fill the Collection manually the form works fine.
>
> I checked all the variable types and can not find anything wrong. :-/
It is still not working? Please review the above hint.
>
> AFAIK There is no example of a database filled list Woody form using flow.
You can define a BeanList that you will fill with an iterator. This
BeanList can be retrieved from the flow. Then use "CForm binding
framework" to pass the list to a woody repeater. This will work.
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: building Collection from JDO problems
Posted by Bert Van Kets <be...@vankets.com>.
Antonio,
thanks for the help.
The funny thing is everything worked fine getting one record. I used the ojb
sample and modified that to use my database and table.
I then tried to modify the bean and DAO class to return a collection instead
is strings and integers so I can build a list instead of a simple record.
The Collection is filled with classes of the same structure as the original
bean. I also modified the repository.xml file to point to the new class
instead of the bean.
Of course the form was adjusted to accept the Collection and return the
different records.
When I fill the Collection manually the form works fine.
I checked all the variable types and can not find anything wrong. :-/
AFAIK There is no example of a database filled list Woody form using flow.
Any ideas on how to perform tests?
Bert
----- Original Message -----
From: "Antonio Gallardo" <ag...@agssa.net>
To: <us...@cocoon.apache.org>
Sent: Saturday, February 21, 2004 2:48 AM
Subject: Re: building Collection from JDO problems
> Hi Bert:
>
> Review variable names. Based on the error looks like you are trying to use
> a method or property of a JS variable that was not initializated.
>
> Check for the
> new Packages.... if they are correct written.
>
> Best Regards,
>
> Antonio Gallardo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: building Collection from JDO problems
Posted by Antonio Gallardo <ag...@agssa.net>.
Hi Bert:
Review variable names. Based on the error looks like you are trying to use
a method or property of a JS variable that was not initializated.
Check for the
new Packages.... if they are correct written.
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org