Skip to main content
[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

Back to the top