Stability

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Stability

John Eichelsdorfer
We may actually have to go with the 1.0.5 release in production because of our desire to use one of the newer features.  The last RC came out 29JAN2008 with the last code changes in subversion on 30JAN2008, so the RC1 does not contain some fixes.  Is there anything you consider important to get into the RC prior to it being considered "safe enough for use"?

As we use the PB API the only issues that might stop us are:
        http://issues.apache.org/jira/browse/OJB-143
        http://issues.apache.org/jira/browse/OJB-142   <- Likely not so important to us.


Is there anything else that prevent the current version from use?

Looking at the release notes, it appears that we just need to change out the properties file and the dtd.  Some properties have changed, but as we use the default current 1.0.4 properties in file mostly, I am not sure we would notice changes.

Has anybody else had difficulties or successes with this in a production environment?  We use Maven, so it is a bit of an aggravation manually pushing in the library, but appreciative users like myself should not be so picky.

Thanks for your ideas.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Stability

John Eichelsdorfer
In first testing the 1.0.5 RC, I get the error below.  This worked as is in 1.0.4.  Something different with the count use in the RC?

Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Long which comes from this line as shown in more detail below:
count = new Integer(((Long)obj[2]).intValue());


This came out of getting a count out of a ReportByCriteria result set.

Where the columns look like:
       private static final String[] crColumns = new String[]{"countryId", "regionId", "count(countryId)","count(regionId)"};
       ReportQueryByCriteria query = new ReportQueryByCriteria(specificActiveServiceLocationQueryVO,
                crColumns, crit, true);
.....
.....
obj = (Object[]) resultsIt.next();
count = new Integer(((Long)obj[2]).intValue());


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Stability

John Eichelsdorfer
In reply to this post by John Eichelsdorfer
So quiet!!!

Anyway, I noticed the change that happened after the RC might have had something to do with the count() issue I seem to be having with the RC.

So...  I downloaded trunk and am trying to build to get the latest jar.  I have been spending the last hour trying to finding the 1.0.1 versions of jdo.jar, jdori-enhancer.jar, and jdori.jar.  It seems that Sun has the 2.0 version, but the links for the 1.0.1 version there fail for me.  Nothing for jdori.  In searching further, I noticed that the 2.1.1 verion is locatable here: http://db.apache.org/jdo/downloads.html as well as a jdo-enhancer, but still no jdori.jar or jdori-enhancer.jar.   I was also not able to find the older versions in the Maven repositories I use.

So...I am having a hard time doing a build to test the latest code in SVN.  Ideas on where those libraries can be downloaded?   Maybe they can be upgraded to 2.1.1 versions that are more available?

The message I got when I tried to build was:

BUILD FAILED
c:\source\external\ojb\build.xml:490: The following error occurred while executing this line:
c:\source\external\ojb\build.xml:104: Please download the JDO 1.0.1 reference implementation from http://jcp.org/aboutJava/communityprocess/final/jsr012/index2.ht
ml and copy the jdo.jar, jdori.jar and jdori-enhancer.jar contained in the reference implementation binary archive, into OJB's lib directory.


Also, this was the second error.  The first error was that JUnit.jar was missing out of the ant library directory which I just downloaded (normally use Maven).   I looked in the Ant library directory and saw what looks like JUnit libraries including ant-junit.jar (may be their own version)?    I did download and install junit4.5.jar and it seemed to quiet that error when I put it into Ant's library directory.

Anyway, if either I can get a later build or get those libaries so I can make my own, it would help.

John
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Stability

John Eichelsdorfer
Me yet again!

After a couple hours of searching, can't seem to find those libraries anywhere.

Also, I looked at the build to see if I could avoid them somehow.  I noticed in the build that Java 6.* is not included in the allowed JDKs, but Java 1.2 && 1.3 is?  I recognize that there is likely old support to keep, but it would likely be important to support 6.0 Java as many, like myself, use it.

Just some feedback.

John
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Stability

Armin Waibel
In reply to this post by John Eichelsdorfer
Hi JohnE,

johne wrote:

> We may actually have to go with the 1.0.5 release in production
> because of our desire to use one of the newer features.  The last RC
> came out 29JAN2008 with the last code changes in subversion on
> 30JAN2008, so the RC1 does not contain some fixes.  
> Is there anything
> you consider important to get into the RC prior to it being
> considered "safe enough for use"?
>
> As we use the PB API the only issues that might stop us are:
> http://issues.apache.org/jira/browse/OJB-143

This issue affects 1.0.4 too, so you already have to deal with it.


> http://issues.apache.org/jira/browse/OJB-142   <- Likely not so
> important to us.

This will be fixed in 1.0.5 RC2

>
>
> Is there anything else that prevent the current version from use?
>

If your own tests pass with 1.0.5rc1 there is no reason to prevent from
use. The OJB test-suite contains a lot of tests (all tests from 1.0.4 +
many new tests) and 1.0.5rc1 pass all tests (except the known issues).

Explored 1.0.5rc1 bugs:
http://www.mail-archive.com/ojb-user%40db.apache.org/msg16078.html

regards,
Armin

> Looking at the release notes, it appears that we just need to change
> out the properties file and the dtd.  Some properties have changed,
> but as we use the default current 1.0.4 properties in file mostly, I
> am not sure we would notice changes.
>
> Has anybody else had difficulties or successes with this in a
> production environment?  We use Maven, so it is a bit of an
> aggravation manually pushing in the library, but appreciative users
> like myself should not be so picky.
>
> Thanks for your ideas.
>
> ----- JohnE
>
> http://www.jobbank.com jobbank.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Stability

Armin Waibel
In reply to this post by John Eichelsdorfer
johne wrote:

> In first testing the 1.0.5 RC, I get the error below.  This worked as is in
> 1.0.4.  Something different with the count use in the RC?
>
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to
> java.lang.Long which comes from this line as shown in more detail below:
> count = new Integer(((Long)obj[2]).intValue());
>
>
> This came out of getting a count out of a ReportByCriteria result set.
>
> Where the columns look like:
>        private static final String[] crColumns = new String[]{"countryId",
> "regionId", "count(countryId)","count(regionId)"};
>        ReportQueryByCriteria query = new
> ReportQueryByCriteria(specificActiveServiceLocationQueryVO,
>                 crColumns, crit, true);
> .....
> .....
> obj = (Object[]) resultsIt.next();
> count = new Integer(((Long)obj[2]).intValue());
>

This could be jdbc-driver issue. If OJB doesn't know the field (detect a
not mapped field), in your case the count(...) field, the jdbc-type is
resolved by using the ResultSet metadata (rsMetaData.getColumnType(...))
of the jdbc-driver.

You can try to use the query.setJdbcTypes method to specify the
sql-types, then OJB resolves the proper java-jdbc-types
http://db.apache.org/ojb/docu/guides/jdbc-types.html

int types[] = new int[]{Types.DECIMAL, Types.VARCHAR, Types.BIGINT};
ReportQueryByCriteria q = QueryFactory.newReportQuery(Person.class, crit);
q.setAttributes(new String[]{"id", "firstname", "count(*)"});
q.setJdbcTypes(types);

This should work for all none mapped query fields. If the field is
mapped the type setting will be ignored - this is a bug and will be
fixed in 1.0.5rc2.

regards,
Armin

>
>
>
> -----
> JohnE
>
> http://jobbank.com/ jobbank.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Stability

John Eichelsdorfer
In response to below, it worked in 1.0.3 and then 1.0.4.  When I tried 1.0.5 it failed.  I backed off to 1.0.4 again and it works.  In all cases I use the same latest MySql database driver.  No other changes other then the change in OJB version.

JohnE


Armin Waibel wrote
johne wrote:
> In first testing the 1.0.5 RC, I get the error below.  This worked as is in
> 1.0.4.  Something different with the count use in the RC?
>
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to
> java.lang.Long which comes from this line as shown in more detail below:
> count = new Integer(((Long)obj[2]).intValue());
>
>
> This came out of getting a count out of a ReportByCriteria result set.
>
> Where the columns look like:
>        private static final String[] crColumns = new String[]{"countryId",
> "regionId", "count(countryId)","count(regionId)"};
>        ReportQueryByCriteria query = new
> ReportQueryByCriteria(specificActiveServiceLocationQueryVO,
>                 crColumns, crit, true);
> .....
> .....
> obj = (Object[]) resultsIt.next();
> count = new Integer(((Long)obj[2]).intValue());
>

This could be jdbc-driver issue. If OJB doesn't know the field (detect a
not mapped field), in your case the count(...) field, the jdbc-type is
resolved by using the ResultSet metadata (rsMetaData.getColumnType(...))
of the jdbc-driver.

You can try to use the query.setJdbcTypes method to specify the
sql-types, then OJB resolves the proper java-jdbc-types
http://db.apache.org/ojb/docu/guides/jdbc-types.html

int types[] = new int[]{Types.DECIMAL, Types.VARCHAR, Types.BIGINT};
ReportQueryByCriteria q = QueryFactory.newReportQuery(Person.class, crit);
q.setAttributes(new String[]{"id", "firstname", "count(*)"});
q.setJdbcTypes(types);

This should work for all none mapped query fields. If the field is
mapped the type setting will be ignored - this is a bug and will be
fixed in 1.0.5rc2.

regards,
Armin

>
>
>
> -----
> JohnE
>
> http://jobbank.com/ jobbank.com

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Stability

Armin Waibel
Hi JohnE,

johne wrote:
> In response to below, it worked in 1.0.3 and then 1.0.4.  When I
> tried 1.0.5 it failed.  I backed off to 1.0.4 again and it works.  In
> all cases I use the same latest MySql database driver.  No other
> changes other then the change in OJB version.
>

It's weird! I try to reproduce your issue without success. The query
include a class 'Person' and looks like this:

Criteria crit = new Criteria().addLike("firstname", "%o%")
         .addAndCriteria(new Criteria().addLike("lastname", name));
ReportQueryByCriteria q = QueryFactory.newReportQuery(Person.class, crit);
q.setAttributes(new String[]{"id", "firstname", "count(id)"});
q.addGroupBy(new String[]{"id", "firstname"});
q.addOrderByAscending("firstname");

The field 'id' is mapped as Integer in the Person class-descriptor.

In the result set array the 'count(id)' column is returned as Integer
and NOT as String (using hsql and mysql). Could you give me a hint how
to reproduce your issue?

regards,
Armin

> JohnE
>
>
>
> Armin Waibel wrote:
>> johne wrote:
>>> In first testing the 1.0.5 RC, I get the error below.  This
>>> worked as is in 1.0.4.  Something different with the count use in
>>> the RC?
>>>
>>> Caused by: java.lang.ClassCastException: java.lang.String cannot
>>> be cast to java.lang.Long which comes from this line as shown in
>>> more detail below: count = new
>>> Integer(((Long)obj[2]).intValue());
>>>
>>>
>>> This came out of getting a count out of a ReportByCriteria result
>>> set.
>>>
>>> Where the columns look like: private static final String[]
>>> crColumns = new String[]{"countryId", "regionId",
>>> "count(countryId)","count(regionId)"}; ReportQueryByCriteria
>>> query = new
>>> ReportQueryByCriteria(specificActiveServiceLocationQueryVO,
>>> crColumns, crit, true); ..... ..... obj = (Object[])
>>> resultsIt.next(); count = new Integer(((Long)obj[2]).intValue());
>>>
>>>
>> This could be jdbc-driver issue. If OJB doesn't know the field
>> (detect a not mapped field), in your case the count(...) field, the
>> jdbc-type is resolved by using the ResultSet metadata
>> (rsMetaData.getColumnType(...)) of the jdbc-driver.
>>
>> You can try to use the query.setJdbcTypes method to specify the
>> sql-types, then OJB resolves the proper java-jdbc-types
>> http://db.apache.org/ojb/docu/guides/jdbc-types.html
>>
>> int types[] = new int[]{Types.DECIMAL, Types.VARCHAR,
>> Types.BIGINT}; ReportQueryByCriteria q =
>> QueryFactory.newReportQuery(Person.class, crit);
>> q.setAttributes(new String[]{"id", "firstname", "count(*)"});
>> q.setJdbcTypes(types);
>>
>> This should work for all none mapped query fields. If the field is
>>  mapped the type setting will be ignored - this is a bug and will
>> be fixed in 1.0.5rc2.
>>
>> regards, Armin
>>
>>>
>>>
>>> ----- JohnE
>>>
>>> http://jobbank.com/ jobbank.com
>> ---------------------------------------------------------------------
>>  To unsubscribe, e-mail: [hidden email] For
>> additional commands, e-mail: [hidden email]
>>
>>
>>
>
>
> ----- JohnE
>
> http://jobbank.com/ jobbank.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Stability

John Eichelsdorfer
Still definitely having a problem.

1.0.4 is working.  I got my pom files to pull in the dependencies automatically.  Originally I had them be different between 1.0.4, but I tried having them be the same this time.  The only difference is the repository.dtd, repository-internal.xml, OJB.properties, and OJB-logging.xml, and the actual ojb jar file.  There are no library duplications.

When I move my pom.xml up to 1.0.5 I still get:
    Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Long

On the line for:
    count = new Integer(((Long)obj[2]).intValue());

After adding the following lines that are in line for what you suggested:
   String[] crColumns = new String[]{"countryId", "regionId", "count(countryId)", "count(regionId)"};
   int[] crTypes = new int[]{Types.VARCHAR, Types.VARCHAR, Types.BIGINT, Types.BIGINT};

The added line works fine in 1.0.4, but does not seem to affect the outcome in 1.0.5.  I do add different criteria to the query, but I don't see how they could affect the result set type.

countryId and regionId are both VARCHARs.  Could it be that since they are VARCHARs that it may put the count as a VARCHAR?   Maybe I can try to hunt around OJB code, but I think there might have been a change that was put into OJB after the RC1 that had to do with count().

I had not yet been able to find those libraries yet required to compile OJB though.

Have to think about this more.  Hopefully have more time for it this weekend.  In the meantime, we went up into production with 1.0.4 as we wanted to release quick.

Now we have a document repository and can give people some value added.
Loading...