Re: Barracuda: Refactoring changes (please read!!!)

Hi Christian,

 > core.helper.servlet.ResourceGateway --> webapp.servlet.ResourceGateway

I hate to reverse your changes to ResourceGateway, but it really doesn't 
need to be in the webapp.servlet in order to work.  All that needed to be 
done is to use the Thread context classloader instead of the local 
classloader to load resources.  So, we can move ResourceGateway back to the 
way it was and get rid of "public static final String EXT_RESOURCE_ID = 
"xlib";" in BComponent.

I changed everything back to the way it was and am checking it all in.  I 
have tested it and it works fine.  Please report any problems, but it 
should be good.

here's the commit comment:

<quote name="Jake">
jrk_2002-12-02 - I reversed all changes Christian made previously to
ResouceGateway.  Using the Thread context classloader, we can load resources
from the WebappClassloader just fine even if ResourceGateway is in a parent
classloader.  So, ResourceGateway is now back to
core.helper.servlet.ResourceGateway.

Make sure you do an "ant superclean" before you build Barracuda because 
sample.web.xml needs to write out a new web.xml to account for the new 
(old) location of ResourceGateway

Jake
</quote>

Jake

At 11:59 AM 11/27/2002 -0500, you wrote:
>Hi folks,
>
>As you will recall, we recently revamped the Barracuda source to build
>things into non-overlapping .jar files. This makes it possible to more
>easily put the Barracuda and Log4j jars into the Tomcat shared/lib
>directory. Of course it also means that some of the old class files
>(particularly under org.enhydra.barracuda.core.util have moved to new
>locations, which means that in order to use them you will need to refactor
>your code. The purpose of this email is to try an list what changes need to
>be made in order to do this...
>
>1. In your source...
>--------------------
>In general, you can make the following global replacements...
>
>core.util.data --> plankton.data
>core.util.exceptions --> plankton.exceptions
>core.util.http --> plankton.http
>core.util.l10n --> plankton.l10n
>core.util.srv --> plankton.srv
>core.util.xml --> plankton.xml
>
>core.util.Classes --> plankton.Classes
>core.util.DateUtil --> plankton.DateUtil
>core.util.StringUtil --> plankton.StringUtil
>core.util.data.Collections --> plankton.data.CollectionsUtil
>core.util.logging.Log4jCRS --> log4j.Log4jCRS
>core.util.logging.Log4jApplicationWatch -->
>webapp.log4j.Log4jApplicationWatch
>core.util.logging.Log4jInit --> webapp.log4j.Log4jInit
>core.helper.servlet.ResourceGateway --> core.webapp.servlet.ResourceGateway
>
>After you make these changes you can try compiling, and this should take
>care of most of the issues. There are a few classes that had to stay in
>core.util however, so you may need to manually add import stmts for these
>back into your code if you use any of these classes...
>
>core.util.dom --> all these classes stayed put
>core.util.http --> ContextServices, SessionServices, URLRewriter
>core.util.l10n --> Locales
>core.util.srv --> SimpleServiceFinder
>
>You may also encounter problems compiling classes that use the forms
>package, as some methods have been renamed to what they were originally and
>deprecated methods have been removed. Here are the remappings:
>
>getSingleStringValue --> getStringVal
>getSingleBooleanValue --> getBooleanVal
>getSingleIntegerValue --> getIntegerVal
>getSingleDateValue --> getDateVal
>getSingleLongValue --> getLongVal
>getSingleShortValue --> getShortVal
>getSingleDoubleValue --> getDoubleVal
>getSingleFloatValue --> getFloatVal
>getVals() --> getElementVals()
>getSingleValue --> getVal
>getMultipleValues --> getVals
>
>2. In your config files...
>--------------------------
>You will also want to check for these renaming issues in any of your
>configuration files (web.xml, object-repository.xml, log4j.xml, etc).
>Specifically, you should make the following changes...
>
>core.helper.servlet.ResourceGateway --> core.webapp.servlet.ResourceGateway
>core.util.data.ObjectRepositoryAssembler -->
>plankton.data.ObjectRepositoryAssembler
>core.util.logging.Log4jCRS --> log4j.Log4jCRS
>core.util.logging.Log4jApplicationWatch -->
>webapp.log4j.Log4jApplicationWatch
>core.util.logging.Log4jInit --> webapp.log4j.Log4jInit
>
>This should cover just about everything you need to do to refactor.
>
>Note that if you are recompiling Barracuda on your machine, you should
>delete the following files prior to rebuilding:
>
>src/build.properties
>src/version.properties
>WEB-INF/web.xml
>WEB-INF/log4j.xml
>WEB-INF/object-repository.xml
>WEB-INF/event-gateway.xml
>
>[Note to Jake - we should probably modify build.xml so that changes to
>sample.version.properties and sample.build.properties will cause those files
>to automatically override the main version.properties and build.properties,
>since failure to do so may result in build problems...talk to me if this
>doesn't make sense]
>
>This work was tagged in cvs under csc_122702_2 (so all these rules apply to
>that version or newer).
>
>That should do it. Holler if problems...
>Christian
>----------------------------------------------
>Christian Cryder [[email protected]]
>Internet Architect, ATMReports.com
>Barracuda - http://barracuda.enhydra.org
>----------------------------------------------
>"Coffee? I could quit anytime, just not today"
>
>_______________________________________________
>Barracuda mailing list
>[email protected]
>http://www.enhydra.org/mailman/listinfo.cgi/barracuda
>FAQ - http://www.jguru.com/faq/Barracuda