Re: [Mav-user] jar hell with jdom reloaded
+1 - Original Message - I'm +1 for giving him commit rights. Can we have a vote please? --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl [INVALID FOOTER]
Re: [Mav-user] VOTE: Make Eelco a committer
+1, then he can put the link up :) - Original Message - From: Schnitzer, Jeff [EMAIL PROTECTED] I propose making Eelco a committer. I'm +1. --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 [INVALID FOOTER]
Re: [Mav-user] Eclipse plugin
What about using the config file to help navigate to the controller classes. It would be nice to be able to see your project space in terms of the commands and controllers, and then to navigate to the source files associated with them. Just an idea... Also, if you are using xsl stuff (with domify) it would be great if the tool could pick up the xml transform data at various steps and do local (development) transforms with the xsl sources without having to deploy to the app server. Then you could do front-end presentation testing, html validation and such, in eclipse without having to deploy new version of the application. If this doesn't make sense I write in a little more detail, just let me know. - Original Message - From: Eelco Hillenius [EMAIL PROTECTED] I'm kind of working on an Eclipse plugin for Maverick. After making some contributions for the Jetty Plugin (http://spindle.sourceforge.net) I decided that now is the time to really learn how to write them properly. Right now, the plugin does some pretty printing of the Maverick config file, and displays it's structure in the outline view a little bit smarter than just the XML outline. Does anyone have any good ideas for a useful Maverick plugin (or... are people interested in such a plugin at all?). Eelco --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click [INVALID FOOTER] --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 [INVALID FOOTER]
Re: [Mav-user] Proposed XSLTransform Modification
We are not, we never finished getting the exec permissions setup on cvs. There was a request sent to sf.net, but I never followed up like I should have :( - Original Message - From: Ted Husted [EMAIL PROTECTED] [snip] * Is the CVS list broken? Are we using the syncmail mail script? [snip] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf [INVALID FOOTER]
Re: [Mav-user] PROPOSAL: Move java packaging to net.sf.mav.*
+1. I've been traveling through California the last few days. - Original Message - From: Ted Husted [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, September 27, 2003 12:52 PM Subject: Re: [Mav-user] PROPOSAL: Move java packaging to net.sf.mav.* Mike Moulton wrote: I'm all for a repackaging. While were at it, are there any other changes that have been lingering that could get incorporated into a new release. Personally there are a few things I have intended to look into. Most notably I want to add support for Xalan's XSLTC in the XSL transforms. So I'm +0.5 too :-) If Scott's on-board too, then I'd suggest that we make these types of changes first, make a 2.2.1 release, and then bring out 2.3 immediately thereafter with just the package change. This gives the community access to the latest code and the opportunity to migrate at their leisure. Meanwhile, I just pinged Anthon about my FormProc patch, which would clear the way to committing the opt-formproc extension. -Ted. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf [INVALID FOOTER] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf [INVALID FOOTER]
Re: [Mav-user] PROPOSAL: Add Ted Husted as committer
I have to agree with Ted on this one. It is a little longer, but much clearer, when we use .opt. - Original Message - From: Ted Husted [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, September 27, 2003 12:55 PM Subject: Re: [Mav-user] PROPOSAL: Add Ted Husted as committer Schnitzer, Jeff wrote: How about getting rid of the opt and just have packages like this: net.sf.mav.formproc.* I'd suggest keeping the opt. It's helpful to clearly delineate the Maverick core from packages like this, which extend the Controller core for a specialized use. One of the nice things about Maverick is that it is quite clear where the core ends, and these other things begin. -Ted. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf [INVALID FOOTER] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf [INVALID FOOTER]
[Mav-user] Soccer Sample
I'd be interested in seeing it, and we can add a link to the source in the docs if you would like. The more samples, the better. random type=comment I'm always amazed at home much technology we can squeeze in an application for such a little thing like a soccer team. I remember when I was kid all we did was xerox schedules and phone lists and bring them home to our parents. Now I just say, zyz.com, and wham everything is there. We are generating so much more information it is out of control. It is a Burdon and creates so many benefits I just don't know how to feel about it :) /random - Original Message - From: Aapo Laakkonen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 22, 2003 12:23 PM Subject: RE: [Mav-user] PROPOSAL: Add Ted Husted as committer I agree. I looked at the code that Ted wrote and it looked good to me, althought I'm not using it, :-). FormProc is too bloat for my usage (or maybe I'm going to use it in future) - not to say that FormProc is a really nice component. I'm currently working on my Soccer team's new web site. I'm really happy with my architecture and I like it a lot. I'm also willing to donate the code if someone want's it (when it's finished). I think that it will be a really good example of Maverick (maybe a demo app for Maverick) and several other open source tools (including XDoclet, Hibernate, PicoContainer and Velocity). Regards, Aapo --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf [INVALID FOOTER]
Re: [Mav-user] PROPOSAL: Add Mike Moulton as committer
+1; Absolutely! _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 [INVALID FOOTER]
Re: [Mav-user] q: multiple config files
The unfortunate side affect of doing this entity inclusion is that the partX.xml files are xml fragments and not well-formed documents. XLink provides a better alternative but is implementation bound. Not all xml processors/parsers support the XLink syntax. You could also use the transformation of the configuration file support in mav to include multiple source documents into a single output document. There is a lot of latitude here as to how you can do this. One way would work something like this. add to web.xml in servlet-mapping configFileWEB-INF/master.xml/configFile configTransformWEB-INF/loadComponents.xsl/configTransform - master.xml - maverick version=2.0 default-view-type=document loadComponents filecomponent1.xml/file filecomponent2.xml/file /loadComponents /maverick - loadComponents.xsl xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; !-- copy attributes and elements into the output doc -- xsl:template match=@*|node() xsl:copy xsl:apply-templates select=@*|node()/ /xsl:copy /xsl:template xsl:template match=loadComponents xsl:variable name=component select=document(file)/component/ commands xsl:apply-templates select=$component/commands/*/ /commands views xsl:apply-templates select=$component/views/*/ /views /xsl:template /xsl:stylesheet - component1.xml - component commands ... /commands views ... /views /component This is method is a litte more complicated, but also gives much more flexibility and control over what is included where. - Original Message - From: Schnitzer, Jeff [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 11, 2002 1:00 PM Subject: RE: [Mav-user] q: multiple config files Yes, this is easy to do - since the XML config file is read with a standard XML parser, use the XML entity mechanism to chop up the file. This should probably be a FAQ, but the best explanation I have seen for how to do this is in the Docbook documentation: http://www.docbook.org/tdg/en/html/ch01.html#s-entities Basically, you define entities for each chunk: !ENTITY part1 SYSTEM part1.xml !ENTITY part2 SYSTEM part2.xml !ENTITY part3 SYSTEM part3.xml maverick version=2.0 part1; part2; part3; /maverick That should work just fine. The config format already allows multiple commands and views elements. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf [INVALID FOOTER]
Re: [Mav-user] Re: Large sites, performance issues? (jim moore)
Yeah, This is about right. It actually loads the new version of config
before releasing the existing copy. This is so the site will work until the
new config is loaded. You don't want to drop the old stuff until the new
config is validated and loaded.
It looks something like this in code.
try{
newConfig = reloadConfig();
}
...
//if all goes well
currentConfig = newConfig;
So, when reloading you will possibly need twice as much memory (more of less
depending on what mode you using and what changes you have made to the
config) for template reloading.
IMHO, 256 is probably not enough for development (of a large application).
- Original Message -
From: jim moore [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, November 01, 2002 7:23 AM
Subject: Re: [Mav-user] Re: Large sites, performance issues? (jim moore)
I can't say for sure, but knowing java garbage collection, the situation
you
mention sounds reasonable. When mav reloads the views, it drops its
references to the existing cached references, essentially marking them for
garbage collection. Then it loads the new views. Now, until garbage
collection actually collects the old views, java will essentially have two
versions in memory, one that it is using, and one that is marked for
garbage
collection but whose memory has not yet been freed. Possibly the time lag
between simply loading and reloading has to do with dumping the old and
then
loading the new--at startup it only needs to load. Jeff, does this sound
like a reasonable explanation? Feel free to correct me.
---
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
[INVALID FOOTER]
Re: [Mav-user] how to keep domify from reading all properties of a bean
What version of Xalan/Xerces are you using? What do your lazy init'd collections look like? It is possible that the xml parser is reading more data than it should... but it really depends on the XSL/XML used. I need more information, or an simpler example to see what is going on here. - Original Message - From: Christoph Sturm [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 29, 2002 10:16 AM Subject: [Mav-user] how to keep domify from reading all properties of a bean Hi All! I am using domify with xalan and xerces, and I am accessing a collection of elements where each element contains a lazily initialized collection of other elements. my xsl fragment looks like this: xsl:for-each select=/model/results/items xsl:value-of select=name/ xsl:value-of select=someotherproperty/ ... /xsl:for-each I am reading some properties, but not the lazily initialized collection. Nevertheless accesses the collection, and I get a database hit. What can I do about this? regards chris --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/ --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/
Re: [Mav-user] Creating patches
Yes, please send what you have to this list. If it is really big 200k (?) please just announce it and someone will contact you for the patch files. We are pretty laid back here, don't worry about etiquette. We try not to :) Roy, you might want to check that you are on the list. I've cc'd you because I had to approve this post because it didn't come from a subscribed email. - Original Message - From: Roy Truelove [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 01, 2002 7:06 PM Subject: [Mav-user] Creating patches Hey folks, Since there's no dev list for this projects, should we post / discuss possible patches here to this list? I haven't contributed to any open source before, so I don't want to break a rule of etiquette. Thanks, Roy --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/
