Hi Victor, I believe this is a more specifically a geoserver issue... you should probably move the conversation there. As for the fix I still think modifying the SecuredObject* interfaces in geoserver to explicitly pass down the interface is the most robust option. But that is something for discussion on geoserver-devel.
-Justin On Mon, Apr 11, 2011 at 2:32 AM, <[email protected]> wrote: > Hi Andrea, > > > > I am at a lost on how to resolve this issue as it only occurs on specific > environment. In our case its a debian server. > > > > I believe it’s some policy setting to created this issue but I do not know > how the policy works and I could not find any documentation on it as well. > Would you be able to give some advice? > > > > Below is a brief conversation with Justin; I was lost at how to resolve > this therefore created a workaround patch which is more of a bandaid(as > quoted by Justin) > > > > > > > > Victor Tey<http://jira.codehaus.org/secure/ViewProfile.jspa?name=victortey> > added a comment - 05/Apr/11 4:32 AM > > Due to the error below, I need your approval for this patch for trunk and > branch. > > SecuredFeatureCollection.features() is supposed to return a FeatureIterator > but due to some policy setting on the server, it seem to return a Iterator > instead. I was unable to replicate the issue on my local machine and it is > machine setting specific. > > I was also unable to get any response from Andrea with regards to this > therefore had to submit this workaround. > > 2011-02-24 11:04:02,941 ERROR [geoserver.ows] - > java.lang.ClassCastException: > org.geoserver.security.decorators.SecuredIterator cannot be cast to > org.geotools.feature.FeatureIterator > at > org.geoserver.security.decorators.SecuredFeatureCollection.features(SecuredFeatureCollection.java:57) > > at > org.geoserver.wfs.response.HitsOutputFormat.countFeature(HitsOutputFormat.java:102) > > at > org.geoserver.wfs.response.HitsOutputFormat.write(HitsOutputFormat.java:85) > > at org.geoserver.ows.Dispatcher.response(Dispatcher.java:751) > at > org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:233) > at > org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153) > > at > org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48) > > at > org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875) > > at > org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809) > > at > org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571) > > > > Justin > Deoliveira<http://jira.codehaus.org/secure/ViewProfile.jspa?name=jdeolive> > added a comment - 05/Apr/11 9:33 AM > > This patch is a bandaid... the real problem is in the security system so we > should fix it there. > > I believe what is happening in this case is that there are iterator objects > that implement both FeatureIterator and Iterator. So the security wrapper is > wrapping it in this case as an Iterator when it should be wrapping it as a > FeatureIterator. I am not sure exactly which iterator is doing this but one > such iterator is ForceCoordinateSystemIterator. > > Not sure exactly what the best way to solve that issue is... perhaps > passing in the interface into SecuredObjects.secure rather than just the > object. Or perhaps just hunt down feature iterators that implement both and > separate them out.I think the former is a more robust solution. Would like > to hear Andrea weigh in on this one. > > > > > > *Victor Tey * > > Software Engineer > ASRDC > CSIRO Earth Science and Resource Engineering** > > Phone: [image: cid:[email protected]][image: > cid:[email protected]][image: > cid:[email protected]][image: > cid:[email protected]][image: > cid:[email protected]][image: > cid:[email protected]][image: > cid:[email protected]][image: > cid:[email protected]][image: > cid:[email protected]][image: > cid:[email protected]][image: > cid:[email protected]][image: > cid:[email protected]]+61 8 6436 8944 > [email protected] *|* www.csiro.au *|* > Address: Australian Resources Research Centre, 26 Dick Perry Avenue, > Kensington WA 6151** > > *PLEASE NOTE* > The information contained in this email may be confidential or privileged. > Any unauthorised use or disclosure is prohibited. If you have received this > email in error, please delete it immediately and notify the sender by return > email. Thank you. To the extent permitted by law, CSIRO does not represent, > warrant and/or guarantee that the integrity of this communication has been > maintained or that the communication is free of errors, virus, interception > or interference. > > *Please consider the environment before printing this email.* > > > > > ------------------------------------------------------------------------------ > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial.
<<image003.gif>>
<<image004.gif>>
<<image002.gif>>
<<image001.gif>>
------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev
_______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
