Hi all, this commit is a bit related to this morning discussion about
groupOwner, I would suggest the following changes :
* remove the GetByOwner class & service as far as Lucene search could
provide exactly the same results (with better flexibility). One main
reason is that this service does not provide paging so an admin using
this service on a 10000 records database will just dump everything.
Other reason, it provides less sorting options than default Lucene
search (eg. no title option), response will mix ISO, FGDC, DC records,
which is probably hard to deal with when receiving the response
(xml.search provide the brief formatting instead).
* add a metadata group (mdGroup) and a metadata owner (mdOwner)
parameters to LuceneQueryBuilder to be able to do similar search that
GetByOwner does.
What do you think ?
Francois
2010/10/28 <josegar74@anonymised.com>:
(attachments)
search-by-owner-and-group.patch (2.64 KB)
hi,
one issue might be that some users are using this service (I know this for a fact), and removing it might break whatever they’re doing with it. Can we “deprecate” services ?
LQB can already search for metadata owner, it’s the “owner” parameter. As for groupOwner, I still think we should first finish our IRC discussion and come up with some kind of rationale what it is supposed to mean–in view of the fact that groupOwner might be A whereas users in group A could be not allowed to edit or even view the metadata, but users in group B could. As it stands, this GetByOwner retrieving metadata based on groupOwner (for reviewers) could retrieve totally unusable results, if the user can neither view or edit them…
I’ve just added to 26x a function that is probably similar to the intent of this, a “my metadata” function that displays all metadata you are allowed to edit, which indeed uses Lucene.
regards
heikki
On Tue, Dec 21, 2010 at 7:22 PM, Francois Prunayre <fx.prunayre@anonymised.com> wrote:
Hi all, this commit is a bit related to this morning discussion about
groupOwner, I would suggest the following changes :
- remove the GetByOwner class & service as far as Lucene search could
provide exactly the same results (with better flexibility). One main
reason is that this service does not provide paging so an admin using
this service on a 10000 records database will just dump everything.
Other reason, it provides less sorting options than default Lucene
search (eg. no title option), response will mix ISO, FGDC, DC records,
which is probably hard to deal with when receiving the response
(xml.search provide the brief formatting instead).
- add a metadata group (mdGroup) and a metadata owner (mdOwner)
parameters to LuceneQueryBuilder to be able to do similar search that
GetByOwner does.
What do you think ?
Francois
2010/10/28 <josegar74@anonymised.com…>:
Forrester recently released a report on the Return on Investment (ROI) of
Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even
within 7 months. Over 3 million businesses have gone Google with Google Apps:
an online email calendar, and document program that’s accessible from your
browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Hello Heikki,
2010/12/21 heikki <tropicano@anonymised.com>:
hi,
one issue might be that some users are using this service (I know this for a
fact), and removing it might break whatever they're doing with it. Can we
"deprecate" services ?
This service has been added to 2.6.1, and I sent commets to Jose
directly some times ago. I don't think so much people are using it. At
least we don't have any GUI using it in 2.6.x or trunk. so +1 from me
to remove it.
LQB can already search for metadata owner, it's the "owner" parameter.
Not sure, Owner is in the OR clause of user groups... mdOwner is in
the main query. to be checked.
As
for groupOwner, I still think we should first finish our IRC discussion and
come up with some kind of rationale what it is supposed to mean--in view of
the fact that groupOwner might be A whereas users in group A could be not
allowed to edit or even view the metadata, but users in group B could. As it
stands, this GetByOwner retrieving metadata based on groupOwner (for
reviewers) could retrieve totally unusable results, if the user can neither
view or edit them..
The patch only retrieve metadata you could view, and edit privileges
will be returned according to user session.
But I agree we should finish the discussion.
I've just added to 26x a function that is probably similar to the intent of
this, a "my metadata" function that displays all metadata you are allowed to
edit, which indeed uses Lucene.
Yep I've seen that.
More discussion needed.
Thanks Heikki.
Francois
regards
heikki
On Tue, Dec 21, 2010 at 7:22 PM, Francois Prunayre <fx.prunayre@anonymised.com>
wrote:
Hi all, this commit is a bit related to this morning discussion about
groupOwner, I would suggest the following changes :
* remove the GetByOwner class & service as far as Lucene search could
provide exactly the same results (with better flexibility). One main
reason is that this service does not provide paging so an admin using
this service on a 10000 records database will just dump everything.
Other reason, it provides less sorting options than default Lucene
search (eg. no title option), response will mix ISO, FGDC, DC records,
which is probably hard to deal with when receiving the response
(xml.search provide the brief formatting instead).
* add a metadata group (mdGroup) and a metadata owner (mdOwner)
parameters to LuceneQueryBuilder to be able to do similar search that
GetByOwner does.
What do you think ?
Francois
2010/10/28 <josegar74@anonymised.com>:
------------------------------------------------------------------------------
Forrester recently released a report on the Return on Investment (ROI) of
Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even
within 7 months. Over 3 million businesses have gone Google with Google
Apps:
an online email calendar, and document program that's accessible from your
browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
Hi
About the GetByOwner service, I agree with Francois, we can remove it for now and do the same functionality using xml.search, maybe with some minor changes. I did not have time to check about this, but can check for 2.6.3.
Regards,
Jose García
On Tue, Dec 21, 2010 at 8:58 PM, Francois Prunayre <fx.prunayre@anonymised.com> wrote:
Hello Heikki,
2010/12/21 heikki <tropicano@anonymised.com…>:
hi,
one issue might be that some users are using this service (I know this for a
fact), and removing it might break whatever they’re doing with it. Can we
“deprecate” services ?
This service has been added to 2.6.1, and I sent commets to Jose
directly some times ago. I don’t think so much people are using it. At
least we don’t have any GUI using it in 2.6.x or trunk. so +1 from me
to remove it.
LQB can already search for metadata owner, it’s the “owner” parameter.
Not sure, Owner is in the OR clause of user groups… mdOwner is in
the main query. to be checked.
As
for groupOwner, I still think we should first finish our IRC discussion and
come up with some kind of rationale what it is supposed to mean–in view of
the fact that groupOwner might be A whereas users in group A could be not
allowed to edit or even view the metadata, but users in group B could. As it
stands, this GetByOwner retrieving metadata based on groupOwner (for
reviewers) could retrieve totally unusable results, if the user can neither
view or edit them…
The patch only retrieve metadata you could view, and edit privileges
will be returned according to user session.
But I agree we should finish the discussion.
I’ve just added to 26x a function that is probably similar to the intent of
this, a “my metadata” function that displays all metadata you are allowed to
edit, which indeed uses Lucene.
Yep I’ve seen that.
More discussion needed.
Thanks Heikki.
Francois
regards
heikki
On Tue, Dec 21, 2010 at 7:22 PM, Francois Prunayre <fx.prunayre@anonymised.com>
wrote:
Hi all, this commit is a bit related to this morning discussion about
groupOwner, I would suggest the following changes :
- remove the GetByOwner class & service as far as Lucene search could
provide exactly the same results (with better flexibility). One main
reason is that this service does not provide paging so an admin using
this service on a 10000 records database will just dump everything.
Other reason, it provides less sorting options than default Lucene
search (eg. no title option), response will mix ISO, FGDC, DC records,
which is probably hard to deal with when receiving the response
(xml.search provide the brief formatting instead).
- add a metadata group (mdGroup) and a metadata owner (mdOwner)
parameters to LuceneQueryBuilder to be able to do similar search that
GetByOwner does.
What do you think ?
Francois
2010/10/28 <josegar74@…11…>:
Forrester recently released a report on the Return on Investment (ROI) of
Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even
within 7 months. Over 3 million businesses have gone Google with Google
Apps:
an online email calendar, and document program that’s accessible from your
browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
Forrester recently released a report on the Return on Investment (ROI) of
Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even
within 7 months. Over 3 million businesses have gone Google with Google Apps:
an online email calendar, and document program that’s accessible from your
browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Hallo all,
We tried to deploy a geonetwork system (v2.4) inside an Oracle weblogic container. The complete system is running as standalone system in the delivered jetty container without any problems. But deployment and running in a weblogic container is impossible at the moment. During GN system start a lot of EPSG connection warnings appear in the container logfile like:
...
WARNING: Unavailable authority factory: European Petroleum Survey Group
org.opengis.referencing.FactoryException: Failed to connect to the EPSG database.
at org.geotools.referencing.factory.epsg.ThreadedEpsgFactory.createBackingStore(ThreadedEpsgFactory.java:428)
at org.geotools.referencing.factory.DeferredAuthorityFactory.getBackingStore(DeferredAuthorityFactory.java:132)
...
Caused by: java.sql.SQLException: Failed to get the data source for name "jdbc/EPSG".
at org.geotools.referencing.factory.epsg.ThreadedEpsgFactory.createDataSource(ThreadedEpsgFactory.java:306)
at org.geotools.referencing.factory.epsg.ThreadedEpsgFactory.createBackingStore0(ThreadedEpsgFactory.java:373)
at org.geotools.referencing.factory.epsg.ThreadedEpsgFactory.createBackingStore(ThreadedEpsgFactory.java:421)
... 96 more
Caused by: javax.naming.NamingException: String index out of range: -1
at weblogic.jndi.Environment.getContext(Environment.java:308)
at weblogic.jndi.Environment.getContext(Environment.java:285)
...
@The GN background database is an Oracle DB.
Is there someone who had such a problem and could assist us?
Cheers
Hans
our weblogic.xml file:
<?xml version = '1.0' encoding = 'windows-1252'?>
<!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 8.1//EN" "http://www.bea.com/servers/wls810/dtd/weblogic810-web-jar.dtd">
<weblogic-web-app>
<reference-descriptor/>
<context-root>/geonetwork</context-root>
<container-descriptor>
<show-archived-real-path-enabled>true</show-archived-real-path-enabled>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
</weblogic-web-app>
--
Hans Ramthun
Tel.: +49 (0)40 460 094 - 112
Email:hans.ramthun@anonymised.com
Deutsches Klimarechenzentrum - DKRZ
Abteilung Datenmanagementhttp://www.mad.zmaw.de/
Bundesstr. 45a
D-20146 Hamburg Germany
Max Planck Institute for Meteorology (MPI-M)
Bundesstraße 53 www.mpimet.mpg.de
20146 Hamburg Germany
„Only he who knows his destination finds the way.“ (Laozi)