- This topic has 6 replies, 3 voices, and was last updated 12 years, 6 months ago by
.
-
Posts
-
I was able to determine the issues I was having were cookie related per browser I was using but could you explain what is going on here.
I was able to get the example working with MySQL and as I understand it the same example could work with different DAO support objects
(e.g Apache OJB, JdbcDaoSupport, JPADaoSupport , HibernateDaoSupport … etc. ???.)
In the example the Oracle TopLink Essentials is used. It is said this package is limited would you agree with that? e.g is the following true?
open-source community edition of Oracle’s TopLink product. TopLink Essentials is a limited version of the proprietary product. For example, TopLink Essentials doesn’t provide cache synchronization between clustered applications, some cache invalidation policy, and query Cache.
And could this be partly the cause of the weird cookie problem I experienced?
Namely that the access to databases through index.jsp page buttons resulted in pop up session error boxes with no data. Only when I disabled the cookies setting on the browser did this problem go away and the data display. Can you please comment on this issue???rss245b,
I have escalated it to a dev team member. They will get back to you.
Sorry for inconvenience caused.rss,
The deficiencies of Toplink Essentials are purely limited to the direct manipulation and retrieval of data. I’m quite sure your session / web layer level errors are unrelated.
On another note, Toplink Essentials was used for the example because at the time the example was written, it was one of the primary free JPA offerings. You can now actually use EclipseLink, which the successor to TopLink (the commercial version of Toplink Essentials). EclipseLink is one of the frameworks supported by our current JPA capabilities wizard. For more on EclipseLink – see here: http://www.eclipse.org/eclipselink/
Hope this helps.
Are you saying you know about the cookies/Session problem with the DWRSpringJPAExample ?
If so why is this happening? Does it have anything to do with changes in security on browsers and DWR? Is DWR still a viable way to cross Javascript locally and database connections remotely??The session errors only occur on the remote Tomcat server using the .jar file. Can anyone explain why these session errors occur with this example? How might I debug these problems?
@rss245b wrote:
The session errors only occur on the remote Tomcat server using the .jar file. Can anyone explain why these session errors occur with this example? How might I debug these problems?
I miss wrote here I meant .war not .jar file they are very similar files. Sorry!
Still I wish to understand why this cookie madness is happening on the remote server whereas the MyEclipse sandbox Tomcat Server handles all connections fine without session errorsI am still trying to understand where the JSESSIONID cookie is coming from:
It appears to be generated in index_jsp.java but what does the generation? Isn’t it Tomcat that generates it from the index.jsp page?
e.g:
.metadata\.me_tcat\work\Catalina\localhost\DWRSpringJPA\org\apache\jsp\index_jsp.java
contains the code to open sessions e.g .getsession()
If so what in the DWRSpringJPA example sets this session up and why does it fail with cookies enabled as a result. Shouldn’t it just create a new cookie every time the browser runs?
I get the following cookie on the same workstation running the example but the behavior with the browser is different so I am a bit frustrated – Perhaps the Tomcat server.xml file is the difference I may try that file just to see if that makes a difference but it makes little sense to me. Does anyone have something more substantial to add here. I am going to try the scaffolding sample next.
