ginp-developers

[Ginp-developers] Latest changes

[Brian B. <br...@Pi...>]

Doug,

You will see I've made quite a few changes (commit little and often) to 
improve the quality of the existing unit tests, but I'm slightly puzzled 
that I cannot find them on
http://ginp.sourceforge.net/statscm/2007-01.html

do you know why?

You will see I've mainly been working on logging during unit tests... I 
don't have an ideal solution at the moment because it is not possible to 
programatically change the Commons Logging level /after/ the first Log 
instance has been created by the LoggerFactoryImpl. This is a 
combination of limitations in the way LoggerFactoryImpl processes the 
sources of its Properties and a lack of flexibility in SimpleLogger.

If I had more time and enthusiasm, I would start with some code I have 
in another (private) project and do it properly. Perhaps later this year?

I also had to convert the Picture class to use Commons Logging - it was 
still explicitly using log4j. Once done, I discovered 4 test cases were 
failing because they could not find a jpeg file to play with. I sorted 
all that out.

I wonder whether there are more classes still unconverted Commons Logging?


Anyway, the project builds and tests satisfactorily. I've deployed it to 
my own server and it looks OK. Can you try it out too?

Brian

Re: [Ginp-developers] Latest changes

[Doug C. <do...@cu...>]

Brian Burch wrote:
> Doug,
>
> You will see I've made quite a few changes (commit little and often) to 
> improve the quality of the existing unit tests, but I'm slightly puzzled 
> that I cannot find them on
> http://ginp.sourceforge.net/statscm/2007-01.html
>
> do you know why?
>   
I need to do a
> mvn clean site site:deploy
this updates the public website so let me know when you want it updated
and it will do it.

> You will see I've mainly been working on logging during unit tests... I 
> don't have an ideal solution at the moment because it is not possible to 
> programatically change the Commons Logging level /after/ the first Log 
> instance has been created by the LoggerFactoryImpl. This is a 
> combination of limitations in the way LoggerFactoryImpl processes the 
> sources of its Properties and a lack of flexibility in SimpleLogger.
>   
I would not worry too much the logging of errors is correct behavior and
the testing of error conditions is also correct therefore it is only in
the case of a test failure that the log is interesting.
> If I had more time and enthusiasm, I would start with some code I have 
> in another (private) project and do it properly. Perhaps later this year?
>
> I also had to convert the Picture class to use Commons Logging - it was 
> still explicitly using log4j. Once done, I discovered 4 test cases were 
> failing because they could not find a jpeg file to play with. I sorted 
> all that out.
>   
Good work.
> I wonder whether there are more classes still unconverted Commons Logging?
>   
Maybe?
>
> Anyway, the project builds and tests satisfactorily. I've deployed it to 
> my own server and it looks OK. Can you try it out too?
>   
Will do in due course as I use the head in my own website.
> Brian
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Ginp-developers mailing list
> Gin...@li...
> https://lists.sourceforge.net/lists/listinfo/ginp-developers
>   

Re: [Ginp-developers] Latest changes - deployment problems

[Brian B. <br...@Pi...>]

Doug Culnane wrote:
> I need to do a
> mvn clean site site:deploy
> this updates the public website so let me know when you want it updated
> and it will do it.
> 

Don't do it yet, Doug. I'm having some problems deploying the war on my 
own development system and am worried I might have broken something.

> Will do in due course as I use the head in my own website.

Take a backup first! Perhaps you could find time to test the new version 
  with your web site BEFORE updating the public version?

------------

First, some good news... the latest version serves up my photo's under 
https url's as well as http, so that problem has gone away.


------------

I think I screwed up my own deployment testing by not clearing all the 
tomcat files before unpacking the new war. It looked for a while as if 
it was OK, but I'm not confident about what exactly was running (jsps, 
etc get compiled into {CATALINA_HOME}/work/).

I've now done a thorough clearout and am having some problems. In 
particular, I'm quite worried about the setup process I don't think I've 
broken it, but I can't be certain.

The biggest problem is with ginp.xml. When the new ginp-0.30-SNAPSHOT 
cannot find ginp.xml, it runs the ginpSetup Tapestry application as 
intended. I have a good version that worked with the pre-maven war in 
home/config/ginp.xml, but I can't make setup use my existing file. 
However, when I manually copy the file to ../ginp/WEB-INF/ginp.xml, it 
is detected and used properly. I've slogged through a lot of the logic 
but cannot see what is going wrong yet.

I decided to work through your manual, but I'm not making a lot of sense 
of it yet. I'd like to update it based on what I can get working here.

I would like to explain four different scenarios (not necessarily in 
this order):-

1. Whether someone has downloaded the war, or built it from source with 
maven.. how to configure it to serve up some of their own pictures using 
the default home page and the "Basic" demo style.

a) manually, by cloning/updating a sample ginp.xml file (e.g. when the 
setup application is failing).

b) using the setup application, when I can get it working again.

2. How to customise the system for one's own web site.

a) using an existing style.

b) by creating a new personalised style.


At the moment, I'm keeping my life simple by working on 1a. However, 
when I choose the w2k4 (or backinblack or textart) demos from index.jsp, 
it fails. I keep reading the manual to see what you are really saying 
about the style folders, but seem to be missing something important.

If you have any idea why ...

http://www2.pingtoo.com/ginp/styles/w2k4/ginpservlet?cmd=selectcollection&id=0&nocache=207183762

fails with ...

org.apache.jasper.JasperException: /styles/w2k4/collection.jsp(38,0) 
Unable to load tag handler class "net.sf.ginp.tags.GetFolderInfo" for 
tag "ginp:getfolderinfo"

please let me know soon!

Brian

Re: [Ginp-developers] Latest changes - deployment problems

[Doug C. <do...@cu...>]

Sorry Brian but I have not finished the set up wizard and it does not
work.  Either we need to go back to the tapestry version from Justin or
Someone needs to finish it.

It would be great to update the manual because it was written by someone
that understands the GINP, not a user.  However the code needs to work
first.... Maybe your effort would be better served improving the code
then the manual.

Your error looks like the WebAp server can not load the taglib class. 
Check supported version of JSP and Servet specifications in web.xml and
ginp.tld and for your server. Also check for any start up errors on your
web server.

All the best,

Doug

Brian Burch wrote:
> Doug Culnane wrote:
>   
>> I need to do a
>> mvn clean site site:deploy
>> this updates the public website so let me know when you want it updated
>> and it will do it.
>>
>>     
>
> Don't do it yet, Doug. I'm having some problems deploying the war on my 
> own development system and am worried I might have broken something.
>
>   
>> Will do in due course as I use the head in my own website.
>>     
>
> Take a backup first! Perhaps you could find time to test the new version 
>   with your web site BEFORE updating the public version?
>
> ------------
>
> First, some good news... the latest version serves up my photo's under 
> https url's as well as http, so that problem has gone away.
>
>
> ------------
>
> I think I screwed up my own deployment testing by not clearing all the 
> tomcat files before unpacking the new war. It looked for a while as if 
> it was OK, but I'm not confident about what exactly was running (jsps, 
> etc get compiled into {CATALINA_HOME}/work/).
>
> I've now done a thorough clearout and am having some problems. In 
> particular, I'm quite worried about the setup process I don't think I've 
> broken it, but I can't be certain.
>
> The biggest problem is with ginp.xml. When the new ginp-0.30-SNAPSHOT 
> cannot find ginp.xml, it runs the ginpSetup Tapestry application as 
> intended. I have a good version that worked with the pre-maven war in 
> home/config/ginp.xml, but I can't make setup use my existing file. 
> However, when I manually copy the file to ../ginp/WEB-INF/ginp.xml, it 
> is detected and used properly. I've slogged through a lot of the logic 
> but cannot see what is going wrong yet.
>
> I decided to work through your manual, but I'm not making a lot of sense 
> of it yet. I'd like to update it based on what I can get working here.
>
> I would like to explain four different scenarios (not necessarily in 
> this order):-
>
> 1. Whether someone has downloaded the war, or built it from source with 
> maven.. how to configure it to serve up some of their own pictures using 
> the default home page and the "Basic" demo style.
>
> a) manually, by cloning/updating a sample ginp.xml file (e.g. when the 
> setup application is failing).
>
> b) using the setup application, when I can get it working again.
>
> 2. How to customise the system for one's own web site.
>
> a) using an existing style.
>
> b) by creating a new personalised style.
>
>
> At the moment, I'm keeping my life simple by working on 1a. However, 
> when I choose the w2k4 (or backinblack or textart) demos from index.jsp, 
> it fails. I keep reading the manual to see what you are really saying 
> about the style folders, but seem to be missing something important.
>
> If you have any idea why ...
>
> http://www2.pingtoo.com/ginp/styles/w2k4/ginpservlet?cmd=selectcollection&id=0&nocache=207183762
>
> fails with ...
>
> org.apache.jasper.JasperException: /styles/w2k4/collection.jsp(38,0) 
> Unable to load tag handler class "net.sf.ginp.tags.GetFolderInfo" for 
> tag "ginp:getfolderinfo"
>
> please let me know soon!
>
> Brian
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Ginp-developers mailing list
> Gin...@li...
> https://lists.sourceforge.net/lists/listinfo/ginp-developers
>   

Re: [Ginp-developers] Latest changes - deployment problems

[Brian B. <br...@Pi...>]

Doug Culnane wrote:
> Sorry Brian but I have not finished the set up wizard and it does not
> work.  Either we need to go back to the tapestry version from Justin or
> Someone needs to finish it.

That is a huge relief to me. I really didn't want to back out my changes 
but I had to assume I was the guilty party in the absence of evidence to 
the contrary.

I'll stop worrying and move forward instead.


> It would be great to update the manual because it was written by someone
> that understands the GINP, not a user.  However the code needs to work
> first.... Maybe your effort would be better served improving the code
> then the manual.

Agreed. I'm very pleased to find the war from the latest source works in 
basic demo mode. I think I will (very soon) start to restructure the 
manual. I'll follow the simplistic scheme that I suggested until we have 
the "clever stuff" working, then I'll re-organise the manual.

ginp.xml isn't too complex to copy/paste/edit by hand for a demo system, 
so I will start there.


> Your error looks like the WebAp server can not load the taglib class. 
> Check supported version of JSP and Servet specifications in web.xml and
> ginp.tld and for your server. Also check for any start up errors on your
> web server.

Good advice, thanks. I probably have some jars in 
{CATALINA_HOME}/common/lib that worked OK with the "old" ginp.war and 
the Container ClassLoader is pre-empting the jars bundled in the new war.


-----------------------

Your comments above have encouraged me to keep going. When I started 
researching maven, I was a die-hard ant advocate. By the time I had done 
some sample maven applications, I was beginning to be convinced. I made 
a mental note to convert one of my own complex systems to manage its 
dependencies better.

I found it very hard to gain any traction when working on the ginp setup 
problems yesterday. There was so much new (but useful) technology 
involved, but it was so hard to penetrate because I didn't have any 
experience with what it should look like when working. I'm familiar with 
reading java servlet source files generated from jsp's, but they are 
almost impenetrable when custom taglibs are involved. Then throw in 
Tapestry and Hivemind and Spring....

I'd like to refactor ginp into a (small) set of dependent maven 
projects. I don't think it would take a lot of work, but it will mean 
major surgery to the source tree. The maven team have convinced me it is 
a bad idea to make the pom.xml more complex by using a "non-standard" 
directory structure... get it right and then forget it.

I'd like to move the setup logic (Tapestry application) off into a 
sub-project. This would make it much simpler to understand and also 
remove it from the mainline webapp. Of course, the sub-project will 
still be built into the final war, but it will be MUCH simpler to 
understand and work on (and fix) when it is ring-fenced.

The refactoring will naturally identify some core classes used by the 
setup and mainline sub-projects. With luck, some of the more complex 
classes can be refactored into their respective sub-projects. This would 
be a good opportunity to sort out the platform-specific path issues by 
writing more unit tests.

I wonder whether this refactoring might make it much easier for someone 
to create and build their own webapp for their own photos and style? 
Let's wait and see.

I will not start on refactoring unless you like the idea. If you do, I'd 
try out some ideas in my own sandbox to see what structure feels most 
natural. Then we can talk about the best approach and how to restructure 
the source tree.

Thanks again...

Brian

Re: [Ginp-developers] Latest changes - deployment problems

[Doug C. <do...@cu...>]

>
>
> I found it very hard to gain any traction when working on the ginp setup 
> problems yesterday. There was so much new (but useful) technology 
> involved, but it was so hard to penetrate because I didn't have any 
> experience with what it should look like when working. I'm familiar with 
> reading java servlet source files generated from jsp's, but they are 
> almost impenetrable when custom taglibs are involved. Then throw in 
> Tapestry and Hivemind and Spring....
>   
Me too which is why the setup thing is not finished.
> I'd like to refactor ginp into a (small) set of dependent maven 
> projects. I don't think it would take a lot of work, but it will mean 
> major surgery to the source tree. The maven team have convinced me it is 
> a bad idea to make the pom.xml more complex by using a "non-standard" 
> directory structure... get it right and then forget it.
>   
Project standardization is one of the benefits of Maven.
> I'd like to move the setup logic (Tapestry application) off into a 
> sub-project. This would make it much simpler to understand and also 
> remove it from the mainline webapp. Of course, the sub-project will 
> still be built into the final war, but it will be MUCH simpler to 
> understand and work on (and fix) when it is ring-fenced.
>   
Not sure is splitting up the ginp into sub projects is such a good
idea.  This will make a very simple application complex.  The whole idea
of the wizard is that it make the install easy not more complex. The
wizard just needs fixed or refactored for clearer explanation.
> The refactoring will naturally identify some core classes used by the 
> setup and mainline sub-projects. With luck, some of the more complex 
> classes can be refactored into their respective sub-projects. This would 
> be a good opportunity to sort out the platform-specific path issues by 
> writing more unit tests.
>
> I wonder whether this refactoring might make it much easier for someone 
> to create and build their own webapp for their own photos and style? 
> Let's wait and see.
>   
This would be a good argument for refactoring.
> I will not start on refactoring unless you like the idea. If you do, I'd 
> try out some ideas in my own sandbox to see what structure feels most 
> natural. Then we can talk about the best approach and how to restructure 
> the source tree.
>
> Thanks again...
>
> Brian
>
>   
By all means refactor but be careful that the changes you make make
sense and are not just changes.  I would say that effort fixing the
wizard or building in new features would be a better use of your time. 
However I am not motivated to work too much on the ginp so if you can
progress the project to a new release go for it.

All the best,

Doug