[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [udig-devel] UDIG-1578 related issue
|
Jody,
I have download again uDig 1.2RC3 SDK. File (on server) was dated May
17, 2010.
udig1.2RC3_sdk\plugins\net.refractions.udig_platform.source_1.2.0.201005181202\src\net.refractions.udig.catalog.oracle_1.2.0.201005181202\src\net\refractions\udig\catalog\internal\oracle
public class OracleGeoResource extends IGeoResource {
String typename = null;
/**
* Construct <code>OracleGeoResource</code>.
*
* @param parent
* @param typename
*/
public OracleGeoResource( OracleServiceImpl parent, String typename ) {
this.typename = typename;
}
OracleServiceImpl getService() {
return (OracleServiceImpl) service;
}
public URL getIdentifier() {
try {
return new URL(service.getIdentifier().toString() + "#" +
typename); //$NON-NLS-1$
} catch (MalformedURLException e) {
return service.getIdentifier();
}
}
I feel confused too. Maybe you are using latest trunk version?
regards
Lukasz
Cytowanie Jody Garnett <jody.garnett@xxxxxxxxx>:
I am a but confused Lukasz .. when I look at OracleGeoResource I see
the following code:
public OracleGeoResource( OracleServiceImpl parent, String typename ) {
this.service = parent;
this.typename = typename;
this.id = new ID(service.getID(), typename );
}
OracleServiceImpl getService() {
return (OracleServiceImpl) service;
}
@Override
public ID getID() {
return id;
}
@Override
public URL getIdentifier() {
return id.toURL();
}
And it looks fine to me; am I missing something? The ID is
constructed in the constructor up front, rather then each time
getIdentifier is called; there is none of the CorePlugin stuff
(which we did our best to remove since uDig 1.2.x).
Can I confirm you are working with uDig 1.2.x :-)
Jody
On 03/08/2010, at 11:44 PM, Lukasz Stawicki wrote:
Jody,
We have fixed it at the moment - it appeared that after adding
layers by wizard, catalogRef="....." for each layer contained
connection detailsfor all layers (instead only for its own layer).
We solved it setting empty catalogRef="" for each layer. It was
filled again after app restart, but only with single layer data.
You are right - somebody that was writing it may look at this again.
Here are two changes that allowed us to create Oracle layers:
plugin: net.refraction.udig.catalog.oracle
package net.refractions.udig.catalog.internal.oracle;
public class OracleGeoResource
-----------------------
public OracleGeoResource( OracleServiceImpl parent, String typename ) {
this.service = parent;
this.typename = typename;
}
---------------------
public URL getIdentifier() {
try {
return new URL(null, service.getIdentifier().toString()
+ "#" + typename, CorePlugin.RELAXED_HANDLER); //$NON-NLS-1$
} catch (MalformedURLException e) {
return service.getIdentifier();
}
}
------------
regards
Lukasz
Cytowanie Jody Garnett <jody.garnett@xxxxxxxxx>:
Hi Lukasz; can you provide a small example of what you are talking
about? I am not sure I understand what kind of stuff is in this
39000 characters long "SOME_TEXT"?
You may wish to raise a Jira issue; and attach an example of the problem.
The relationship between the catalog and the map layers is
interesting; my understanding is that the catalogRef should be an
ID indicating the georesource in the catalog to be displayed.
So why catalogRef and iD? I am not sure ...
The map should also contain some of the connection parameters, in
case the map is sent to another users of uDig it needs to know
about the information it is displaying; the other user of uDig
would have the required resources added to their own local catalog
etc...
Remember I mentioned the catalog starting to cache the title? We
added the idea of persisted properties to the catalog; so services
could remember some information about their resources between runs
and not have to connect for common activities such as data
discovery.
I wonder if this cache of titles has been accidentally recorded by
the Map layer as part of the catalogRef. Andrea Antonello was
looking at this a month ago; and has one task left in this area of
the code he wanted to review.
A run in the debugger; as it writes out the layer information will
probably answer these questions.
Jody
On 03/08/2010, at 10:50 PM, Lukasz Stawicki wrote:
Jody,
thanks for answering.
We managed to get things working (with some changes in Java
code). We get the
<layers name="L1" catalogRef="SOME_TEXT"
iD="jdbc:oracle:thin:@oracleserver:1521:orcl11#L1"
defaultColor="#1B9E77"> entry and it appears almost OK.
catalogRef='SOME_TEXT' is the thing that worries us - this
'SOME_TEXT' is glued together all jdbc links to all layers
(tables) and totally is about 39000 characters long. As this was
created automatically (by uDig plugin), we do not feel it a
optimal solution. Maybe
<layers name="L1"
catalogRef="jdbc:oracle:thin:@oracleserver:1521:orcl11"
iD="jdbc:oracle:thin:@oracleserver:1521:orcl11#L1"
defaultColor="#1B9E77"> would be better? If you point me where to
fix it, we may send you fixed Java code this week.
regards
Lukasz
Cytowanie Jody Garnett <jody.garnett@xxxxxxxxx>:
Hi Lukasz: you chose a good week to show up.
We had a user get oracle spatial to work; but we never quite
managed to get a clear patch committed back.
To answer your question the title comes from the GeoResourceInfo
at the end of the day; chances are if it is all being displayed
the same there has been a mistake made either in caching the
title or in requesting the title.
Jody
On 03/08/2010, at 8:07 PM, Lukasz Stawicki wrote:
Hi,
at the moment I'm migrating some things from uDig 1.1.1 to uDig 1.2.
Having downloaded latest uDig 1.2RC3, installed it and moved
our code to the new platform. Obviously many things werebroken
(and this was not a problem)
The problem was that I was unable to add OracleSpatial layer -
used 'Add layer' wizard and it crashed after reading connection
data.
Looks like RC3 doesn't contain '1578' fix.
I fixed it on my side anyway:
package net.refractions.udig.catalog.internal.oracle;
OracleGeoResource.java
public OracleGeoResource( OracleServiceImpl parent, String typename ) {
this.service = parent;
this.typename = typename;
}
After this I get the box with layers. I guess these are all my
features from database, but unfortunately all the layers names
are the same. Looks like
org.eclipse.jface.viewers.CheckboxTreeViewer get mad and
display multiple times the same (first) label for different
layers.
Anyway, I finally added two layers on the map. Closed app and
had a look at the .umap file. And I got stuck there:
<layers name="L1" catalogRef=""
iD="jdbc:oracle:thin:@oracleserver:1521:orcl11"
defaultColor="#1B9E77">
Where is the layer name??
Previously I had
<layers name="L1" catalogRef=""
iD="http://oracleserver.oracle.jdbc:1521/orcl11#L1"
defaultColor="#D95F02">
And this old entry is not accepted by uDig 1.2 anymore.
If anybody can help me with new connection params style and map
file, it would be great. Or maybe I've missed a document
describing migration HOWTO?
regards
Lukasz Stawicki
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel