portals-pluto-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Hesmer <shes...@apache.org>
Subject Re: Roadmap completion anytime soon?
Date Thu, 29 Jan 2004 23:04:42 GMT
Thanks for all your feedback ! Amazing.

See a few comments below


Endre StĂžlsvik wrote:

> On Wed, 28 Jan 2004, Nick Lothian wrote:
> | In early December there was a list of items that needed to be done sent to
> | the list:
> | <http://nagoya.apache.org/eyebrowse/ReadMsg?listName=pluto-dev@jakarta.apach
> | e.org&msgNo=282>
> | 
> | The list was (with the current status in []'s):
> | 
> | - support jdk 1.4 [Done]
> The "nested exception" classes in pluto, the API, and the driver (?) say
> something about using the native 1.4 Exception chaining (with the
> cause-Exception in the constructor of the Exception(msg, excp)). This
> shouldn't be done - as this would limit the coude to only be able to
> compile (and run) on 1.4.
>   Instead, a approach where the getCause() is utilized (as already), and
> make the printStackTrace() and getMessage() methods be intelligent: if it
> detects 1.4, then use "buildt in chaining", if not, then do chaining self,
> like this (similar for getMessage()).
>         try {
>             // Check whether we find the 1.4 method Throwable.getStackTrace(),
>             //  if so, use 1.4's built-in Exception chaining.
>             Throwable.class.getDeclaredMethod("getStackTrace", new Class[] {});
>             super.printStackTrace(out);
>         }
>         catch (NoSuchMethodException nsmE) {
>             // Method not found, do the chaining ourselves.
>             out.print("[Nested Exception]");
>             super.printStackTrace(out);
>             out.println();
>             if (_cause == null) {
>                 out.println("<< No cause.. >>");
>             }
>             else {
>                 out.println("<< Cause: >>");
>                 _cause.printStackTrace(out);
>             }
>         }
> If this isn't done, then you'll get chaining twice - which is annoying at 
> best.

good point. I'll try that out some time next week. if it works, I will 
check it into the CVS.

> | 
> | - support tomcat 5 [Not done, see
> | <http://issues.apache.org/bugzilla/show_bug.cgi?id=25128> and
> | <http://issues.apache.org/bugzilla/show_bug.cgi?id=26288>]
> Those are the same bug, I resolved the latest as a duplicate, and posted a 
> suggested fix for the first (crossContext="true" in <Context> 
> description) - tomcat 5 "WORKSFORME".
> Btw: I had problems with my IDE saying that PageFragment was already 
> defined in aggregation/PageFragment.jsp. It is due to line #8, and this 
> line can simply be removed - and things worked still, with no error.

I try to remember nect time I committ something

> Another urelated problem: 
>   I'd like to use the unix-style linking, and -link- up to the webapp from
> the tomcat's webapps dir to within the src. Another approach that is just
> as good, is to make a "portal.xml" file, as suggested in suggested fix of
> bug #25128, and point the docBase -directly- into the dir within the
> source tree.
>    This is very nice so that you don't have to copy anything, simply set 
> your IDE's build-target to the classes-directory within the src's webapp.
> This causes two problems:
> a) These files are missing from the source tree:
> ? portal/src/java/org/apache/pluto/portalImpl/xml/XMLSchema.dtd
> ? portal/src/java/org/apache/pluto/portalImpl/xml/datatypes.dtd
> ? portal/src/java/org/apache/pluto/portalImpl/xml/portlet-app_1_0.xsd
> ? portal/src/java/org/apache/pluto/portalImpl/xml/web-app_2_3.dtd
> ? portal/src/java/org/apache/pluto/portalImpl/xml/xml.xsd
> ? portal/src/webapp/WEB-INF/lib  :
>     castor-
>     jakarta-regexp-1.2.jar
> b) Since the portal uses actual file-based parsing of surrounding
> webapps's web.xml and porlets.xml files, the directory is gotten wrong;  
> the testsuite isn't found. The deal is that it gets the "real path" of its
> own position, and this then resolves to its position with the source-tree, 
> and not the position that the link has within Tomcat's "webapps" 
> directory. It then misses the "testsuite" directory, and instead tries to 
> parse the "CVS", "java" and "resources" directories as webapps!
> This is the class where this parsing happens.
>   org.apache.pluto.portalImpl.services.portletdefinitionregistryPortletDefinitionRegistryServiceFileImpl
> The trick is either to let a user define -where- the tomcat webapps dir 
> is, "hard-specified" and not use this magic, OR hack it using a "backlink" 
> the other way, on the same level as CVS, java, resources, webapp:
>   A link called "testsuite" going to the testsuite's position within the
> tomcat's webapps directory solves the problem - I guess it also could be
> done by just linking to the testsuite dir within the source tree too, as
> it only needs the web.xml and portlets.xml files.
> The a) should probably be fixed anyways, since those files should be
> within the .jar, and those jars should be within the .war file.
>   Some people would probably argue that it is not the correct way to run
> the webapp straight off from the source tree - but hey, it saves a second
> on the build process, and you can edit "dynamic resources" like .jsp's or
> WebMacro/Velocity templates right in the source tree w/o the need for
> copying them to the correct position before clicking reload in your
> browser: PHP style coding!
> | 
> | - change logging to commons logging [Done]
> This seems to be done in a terribly unoptimal way - it is done by making
> the "LogFactory" of pluto log to a commons-Logger logger that is looked up
> -when the log-method is invoked-. This causes the Logger to be looked up
> on each and every log-line, doing the "hashmap treewalk" of the hierarchy
> - at least that's what I've understood so far by browsing the code real
> fast! The same is indeed true for the "isDebugEnabled()"-style code (which
> isn't even present throughout), which causes the impact twice if the
> log-line should be logged.
>   It should be changed to actually -use- the Logger - that is: fetch the
> Logger object on class or object instantiation, and never more - basically
> remove the entire LogFactory code-thing in Pluto and driver - the commons
> logger -is- just such a Factory.
> | 
> | - mavenize build [Done]
> There are some clutter left around - I didn't have any experience with 
> maven, and wasn't connected to the internet when I tried to build it - but 
> I had everything I needed, so by using my IDE (CodeGuide) for the compile 
> instead of the maven-stuff, I finally managed after tons of hassle!
>   There are jars inside there (in particular, the Deploy-thing) that
> obviously is built using old code, as the new code have the "war"-path
> creation commented out (which failed), and replaced by a new path-creation
> line. Thus - the code and the jars are not in synch.
> ALL this clutter should be completely removed before a "done" status is 
> set, I feel - think of all the new people that haven't seen the code 
> before! (like me!)
> | 
> | - howto guide about using the pluto container [not done]
> YES! How many factories have to be made, and what is the om-model? I can't
> seem to grasp that just yet - I haven't seen that castor-stuff ever
> before. - some getting-started docs on how this thing is screwed togehther
> would do miracles!

A first document will be posted next week by Stefan Hepper and me.
We still have a long way to go, but every step forward is good.


View raw message