cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sands Alden Fish <sa...@MIT.EDU>
Subject Re: Determining blocks specified for building an existing cocoon 2.1.9 jar
Date Fri, 09 Dec 2011 15:17:36 GMT
It sounds like this is going to be the best solution possible.  I have a built version from
this source (2.1.9) now and I'm going to try using the resulting JARs for debugging.

(I'm not sure why exactly, but the 2.1.9 build had errors in it from the tag.  ClobHelper
and BlobHelper were missing overrides.  But I was able to put no-op methods in place and get
it to build.)

We'll see how using these dependencies goes, probably today.

-Sands


On Dec 9, 2011, at 10:13 AM, Robby Pelssers wrote:

Did you checkout the tagged version from SVN?

http://svn.apache.org/repos/asf/cocoon

You will find a /tags/cocoon-2.1/RELEASE_2_1_9  (tagged version)

If you check this out you might be able to attach the sources and still be able to do quite
a lot of debugging.  And if you can deduce what blocks you use you even might be able to somehow
reconstruct the jar. I noticed that this version of Cocoon indeed has a block.properties file
where you declare block dependencies.

It might sound like a long shot but I guess it’s better than nothing?!

Robby

From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]
Sent: Friday, December 09, 2011 3:35 PM
To: Robby Pelssers; dev@cocoon.apache.org<mailto:dev@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<mailto:sands@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<mailto:scott.a.phillips@gmail.com>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

The application is mission critical and not trivial to rewrite.  We are currently evaluating
options for a better long term solution including switching the underlying DSpace to version
1.8.x which uses Cocoon 2.2.    I was hoping for a ‘quick’ solution to be able to better
debug the current code base, but I agree that this may not be a viable option.

Thanks Again,

Joe

--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Robby Pelssers [mailto:Robby.Pelssers@nxp.com]
Sent: Friday, December 09, 2011 8:28 AM
To: DeVries, Joe; dev@cocoon.apache.org<mailto:dev@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<mailto:sands@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<mailto:scott.a.phillips@gmail.com>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hi Joe,

I can understand that you want to be able to restore a situation where you actually have matching
sources and config for your existing application.   On the other hand this might be a tricky
task from the looks of it. Is this a huge application?!  Porting the app to Cocoon2.2 or Cocoon
3 is no option?  I’m pretty sure you will like working with the newer versions even more
and even I am planning to switch from Cocoon2.2 to Cocoon3 next year. I know this involves
a lot of work but sometimes the effort is worth the return you get.

If you guys should consider moving to C2 or higher there might be more response to help out.
  If this is impossible maybe some die hard ‘Cocoon 2.1.x’ people can give more help.

Robby

From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Friday, December 09, 2011 3:19 PM
To: Robby Pelssers; dev@cocoon.apache.org<mailto:dev@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<mailto:sands@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<mailto:scott.a.phillips@gmail.com>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hi Robby,

Regarding my objective, we have an application which relies on an old version of DSpace. 
DSpace 1.5.1 uses the custom cocoon jar for which we no longer have the source, or ability
to recreate.  I would like to build a 2.1.9 jar and have the source for debugging that is
compatible with the existing version.    My other objective (and likely the more important
one) is to gain a better understanding of how Cocoon works.

Thanks for looking into it, I appreciate your help.

Joe

--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Robby Pelssers [mailto:Robby.Pelssers@nxp.com]<mailto:[mailto:Robby.Pelssers@nxp.com]>
Sent: Friday, December 09, 2011 1:43 AM
To: dev@cocoon.apache.org<mailto:dev@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<mailto:sands@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<mailto:scott.a.phillips@gmail.com>);
DeVries, Joe
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

I’m not really that familiar with the building of Cocoon2.1.x apps but shouldn’t there
be some blocks.properties (not 100% sure about the name) file used by ant where you can determine
which blocks you want to include?  That would be a good starting point to compare with the
default one.

By the way, I noticed that the last modified timestamps were very similar, as if the Dspace
jar was from a scheduled build from another day.
Regular cocoon jar : 4/12/2006 12:56 PM
DSpace jar: 4/11/2006 12:56 PM

Can you also explain what the point is of this exercise?  You don’t have the sources used
to build the DSpace.jar in some source repository?

Kind regards,
Robby
From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Thursday, December 08, 2011 10:43 PM
To: dev@cocoon.apache.org<mailto:dev@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<mailto:sands@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<mailto:scott.a.phillips@gmail.com>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hi Robby,

I ran Java Decompiler on both jars and compared the resulting files.  Unfortunately there
are over 600 differences (see attached list), with oddities such as:

cocoon-2.1.9.src\org\apache\cocoon\Cocoon.java cocoon:
boolean result = this.threadSafeProcessor.process(environment);

dspace -2.1.9.src\org\apache\cocoon\Cocoon.java:
result = this.threadSafeProcessor.process(environment);

However, I don’t know very much about decompiling, so maybe these are misleading results.

There are also 6 new classes in the DSpace version:
org\apache\cocoon\components\flow\javascript\fom \CompilingClassLoader$1.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$2.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$3.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$4.java
org\apache\cocoon\generation\ JXTemplateGenerator$3.java
org\apache\cocoon\transformation\IncludeTransformer$1.java

I was going to look into a tool like clirr to check for binary compatibility and see if that
can narrow down any differences.

Joe

--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Robby Pelssers [mailto:Robby.Pelssers@nxp.com]<mailto:[mailto:Robby.Pelssers@nxp.com]>
Sent: Thursday, December 08, 2011 2:39 PM
To: dev@cocoon.apache.org<mailto:dev@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<mailto:sands@mit.edu>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

I unpacked both jar files with winrar and noticed some differences in size for a few files.
 One of those files is cocoon.roles for example.

I suggest you take the same approach and find out by using some compare tool to find the exact
differences.

Kind regards.
Robby Pelssers

From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Thursday, December 08, 2011 9:25 PM
To: dev@cocoon.apache.org<mailto:dev@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<mailto:sands@mit.edu>)
Subject: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hello,

I am trying to recreate a custom built Cocoon 2.1.9 jar used by DSpace.  The custom jar has
a different size and checksum from the ‘official’ cocoon-2.0.9.jar, and I don't believe
that there were and changes to the source code.  It was likely built with certain blocks included/excluded.
Is it possible to somehow determine which blocks were included/excluded at build time by looking
at an existing jar file?

http://repo1.maven.org/maven2/org/dspace/xmlui/cocoon/cocoon/2.1.9/cocoon-2.1.9.jar
md5: 8f4d38294286cb550a2262720833fb55

http://mirrors.ibiblio.org/pub/mirrors/maven2/cocoon/cocoon/2.1.9/cocoon-2.1.9.jar<http://mirrors.ibiblio.org/pub/mirrors/maven2/cocoon/cocoon/2.1.9/>
md5: 1d80a0a9ed50764c06b664427a2d5098


Thanks,
Joe DeVries


--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477



Mime
View raw message