cayenne dependencies

Hi,

We're having awful time upgrading to a the new version of Sun's JSAS  
8.1 app server.   Based on what we're seeing so far, it's class  
loader related issues.    The first error we're seeing is related to  
Log4j and commons logging, but I'm guessing that this is the first  
layer of an ugly onion we'll have to peel.

First thing I'm attempting to figure out is the versions of the 3rd  
party packages cayenne 1.1 (final) depends on.

org.apache.commons.beanutils
org.apache.commons.collections
org.apache.commons.lang
org.apache.commons.logging
org.apache.log
org.apache.log4j
org.apache.oro
org.apache.velocity

I believe that's all of them, right?  Is there somewhere on the  
objectstyle site that will give me this information?

Thanks in advance,
Eric

Re: cayenne dependencies

http://www.objectstyle.org/cayenne/userguide/install/postinstall.html

Robert

Eric Schneider wrote:
> Hi,
> 
> We're having awful time upgrading to a the new version of Sun's JSAS 
> 8.1 app server.   Based on what we're seeing so far, it's class  loader
> related issues.    The first error we're seeing is related to  Log4j and
> commons logging, but I'm guessing that this is the first  layer of an
> ugly onion we'll have to peel.
> 
> First thing I'm attempting to figure out is the versions of the 3rd 
> party packages cayenne 1.1 (final) depends on.
> 
> org.apache.commons.beanutils
> org.apache.commons.collections
> org.apache.commons.lang
> org.apache.commons.logging
> org.apache.log
> org.apache.log4j
> org.apache.oro
> org.apache.velocity
> 
> I believe that's all of them, right?  Is there somewhere on the 
> objectstyle site that will give me this information?
> 
> Thanks in advance,
> Eric

Re: cayenne dependencies

Thanks Robert!

That was the tip I needed.  

Cheers,
e.

On Aug 1, 2005, at 10:22 AM, Robert Zeigler wrote:

> http://www.objectstyle.org/cayenne/userguide/install/postinstall.html
>
> Robert
>
> Eric Schneider wrote:
>
>> Hi,
>>
>> We're having awful time upgrading to a the new version of Sun's JSAS
>> 8.1 app server.   Based on what we're seeing so far, it's class   
>> loader
>> related issues.    The first error we're seeing is related to   
>> Log4j and
>> commons logging, but I'm guessing that this is the first  layer of an
>> ugly onion we'll have to peel.
>>
>> First thing I'm attempting to figure out is the versions of the 3rd
>> party packages cayenne 1.1 (final) depends on.
>>
>> org.apache.commons.beanutils
>> org.apache.commons.collections

ordering a selectQuery by ID DESC

Re: ordering a selectQuery by ID DESC

You may want to try this:

new Ordering("db:" + Referentiel.ID_REFERENTIEL_PK_COLUMN,  
Ordering.DESC)

"db:" prefix tells Cayenne that you are specifying ordering in terms  
of database columns, not object properties.

Andrus

On Aug 1, 2005, at 6:45 PM, stefan.leidner <at> tudor.lu wrote:

>
> hello,
>
> i try to execute a SelectQuery wich results i want  to be in the  
> descending order according to the ID of my object
>
> DataContext ctx= CayenneMappingFactory.getInstance().getDataContext();
> SelectQuery query=new SelectQuery(Referentiel.class);
> query.setDistinct(false);
> query.addOrdering(new Ordering 
> (Referentiel.ID_REFERENTIEL_PK_COLUMN, Ordering.DESC));
> List list=ctx.performQuery(query);
>
> it works perfectly on all attributes but not on the ID_PK
>
> have someone an idea ?
>
> thanks

Cayenne committ Exception in M-M relation

weird behaviour with commit?

Hi everyone,

I do something along the following lines:

x= dc.createAndRegisterNewObject(MyClass.class);

y.setSomeProperty("newValue");
y.setToMyClass(x);
dc.commitChanges();

The problem is that "x" isn't linked with "o" after doing the commit so
at the moment I improvise doing

x = dc.createAndRegisterNewObject(MyClass.class);
dc.commitChanges();  // this commit makes the y.setToMyClass(x) work
like intended

y.setSomeProperty("newValue");
y.setToMyClass(x);
dc.commitChanges();

This is a fairly ugly hack, acceptible, but I'd like to avoid it.
Is this the intended cayenne behaviour or is it the result of using a
not-yet-stable version (1.2b4)? I'm using MSSQL, jtds 1.0...I don't know
if anything else is relevant.

Also, while I'm on topic: commitChanges() is a transactive operation -
right?

Thanks in advance,
Tomislav

Re: weird behaviour with commit?

Hefest <Hefest <at> gmail.com> wrote:
> Hi everyone,
> 
> I do something along the following lines:
> 
> x= dc.createAndRegisterNewObject(MyClass.class);
> 
> y.setSomeProperty("newValue");
> y.setToMyClass(x);
> dc.commitChanges();
> 
> The problem is that "x" isn't linked with "o" after doing the commit so
> at the moment I improvise doing
> 
> x = dc.createAndRegisterNewObject(MyClass.class);
> dc.commitChanges();  // this commit makes the y.setToMyClass(x) work
> like intended
> 
> y.setSomeProperty("newValue");
> y.setToMyClass(x);
> dc.commitChanges();

Do you have both y and x in the same dc?
Probably not.   By default, y.setToMyClass(x) will try to convert x to y's 
dc if they are not the same.
Since x is only a temporary object until it's committed, it probably won't 
survive the conversion.

Try using:

x = y.getDataContext().createAndRegisterNewObject(MyClass.class);

Re: weird behaviour with commit?

Mike Kienenberger wrote:

>Hefest <Hefest <at> gmail.com> wrote:
>  
>
>>Hi everyone,
>>
>>I do something along the following lines:
>>
>>x= dc.createAndRegisterNewObject(MyClass.class);
>>
>>y.setSomeProperty("newValue");
>>y.setToMyClass(x);
>>dc.commitChanges();
>>
>>The problem is that "x" isn't linked with "o" after doing the commit so
>>at the moment I improvise doing
>>
>>x = dc.createAndRegisterNewObject(MyClass.class);
>>dc.commitChanges();  // this commit makes the y.setToMyClass(x) work
>>like intended
>>
>>y.setSomeProperty("newValue");
>>y.setToMyClass(x);
>>dc.commitChanges();
>>    
>>
>
>Do you have both y and x in the same dc?
>Probably not.   By default, y.setToMyClass(x) will try to convert x to y's 
>dc if they are not the same.
>Since x is only a temporary object until it's committed, it probably won't 
>survive the conversion.
>
>Try using:
>
>x = y.getDataContext().createAndRegisterNewObject(MyClass.class);
>  
>
I wish it were that simple: I'm working on a (tapestry) web application
and my DataContext is stored in the session so there is, in reality,
only one (per client): I haven't initialized any other.

Btw, I initialize it like so:

    public DataContext getContext() {
        if (context == null) {
            context = Configuration.getSharedConfiguration().getDomain(
                    "MyDomain").createDataContext();
        }
        return context;
    }

I reference this context from all the pages in the application.
I don't think this is the problem as it works just fine in several other
applications I've written.
Any other ideas?

Tomislav

Re: weird behaviour with commit?

Mike Kienenberger wrote:

> Do you have both y and x in the same dc?
> Probably not.   By default, y.setToMyClass(x) will try to convert x to y's 
> dc if they are not the same.
> Since x is only a temporary object until it's committed, it probably won't 
> survive the conversion.
> 
> Try using:
> 
> x = y.getDataContext().createAndRegisterNewObject(MyClass.class);

Actually, it's even easier than that.  If y is already registered with a
data context, there's no need to explicitly register x.

x = new MyClass();
y.setToMyClass(x);

This will auto-register x with y's data context.

--

-- 
Kevin