[2006-09-20 00:06:05] * apetro (n=microcli@ip68-99-95-247.ph.ph.cox.net) has joined ##uportal
[2006-09-20 00:06:18] <apetro> hello JA-SIG world
[2006-09-20 00:07:16] * apetro (n=microcli@ip68-99-95-247.ph.ph.cox.net) has left ##uportal
[2006-09-20 08:41:42] * deuce (n=deuce@ip68-2-81-129.ph.ph.cox.net) has joined ##uportal
[2006-09-20 09:19:49] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[2006-09-20 09:19:55] * bszabo (n=bszabo@uni1.unicon.net) has joined ##uportal
[2006-09-20 09:20:13] <bszabo> Good morning Eric
[2006-09-20 09:20:20] <EricDalquist> good morning
[2006-09-20 09:20:27] * ChanServ sets mode +o EricDalquist
[2006-09-20 09:20:32] * EricDalquist sets mode -o EricDalquist
[2006-09-20 09:40:13] * deuce (n=deuce@ip68-2-81-129.ph.ph.cox.net) has joined ##uportal
[2006-09-20 09:45:12] * dmccallum (n=dmccallu@uni1.unicon.net) has joined ##uportal
[2006-09-20 10:23:27] * deuce (n=deuce@ip68-2-81-129.ph.ph.cox.net) has joined ##uportal
[2006-09-20 10:26:27] * deuce_ (n=deuce@ip68-2-81-129.ph.ph.cox.net) has joined ##uportal
[2006-09-20 11:04:39] * deuce (n=deuce@ip68-2-81-129.ph.ph.cox.net) has joined ##uportal
[2006-09-20 12:11:03] * deuce_ (n=deuce@uni1.unicon.net) has joined ##uportal
[2006-09-20 12:15:26] * peterk (n=Kharchen@24-181-224-213.dhcp.oxfr.ma.charter.com) has joined ##uportal
[2006-09-20 12:23:21] * apetro (n=microcli@uni1.unicon.net) has joined ##uportal
[2006-09-20 12:23:31] <apetro> hello uportal world
[2006-09-20 12:23:40] <EricDalquist> hello andrew
[2006-09-20 12:34:14] <peterk> hi andrew
[2006-09-20 12:43:16] <EricDalquist> so ... the servlet spec is really annoying
[2006-09-20 12:45:02] <EricDalquist> did anyone here read the email from Jan a few days ago about multithreaded access to the request/response and rules about wrapping them?
[2006-09-20 12:48:32] <deuce_> protected void setCommandArg (PortletRequest request, String arg) {
[2006-09-20 12:48:32] <deuce_> // TODO: we need to write this param into the request. It is not clear how.
[2006-09-20 12:48:32] <deuce_> //runtimeData.setParameter("grpCommandArg",arg);
[2006-09-20 12:48:33] <deuce_> }
[2006-09-20 12:48:43] <deuce_> from groups manager .. anyone have any ideas?
[2006-09-20 12:49:16] <EricDalquist> nope ... who does the source annotation say checked that code in?
[2006-09-20 12:50:49] <deuce_> looks like michael
[2006-09-20 12:51:22] <EricDalquist> :/ yeah not sure
[2006-09-20 12:51:25] <deuce_> 
[2006-09-20 12:51:28] <deuce_> fun fun
[2006-09-20 12:53:28] <EricDalquist> does it actually get called by any other code?
[2006-09-20 12:54:50] <deuce_> lots ..
[2006-09-20 12:55:09] <deuce_> looks like i can just pass it along with setAttribute and getAttribute
[2006-09-20 12:55:34] * deuce_ loves the groups manager
[2006-09-20 12:55:43] <EricDalquist> i bet
[2006-09-20 12:56:32] <deuce_> hmmm .. maybe i can't
[2006-09-20 13:24:31] * shawnlonas (n=shawn@uni1.unicon.net) has joined ##uportal
[2006-09-20 13:42:57] * deuce (n=deuce@uni1.unicon.net) has joined ##uportal
[2006-09-20 14:01:42] * peterk (n=Kharchen@24-181-224-213.dhcp.oxfr.ma.charter.com) has joined ##uportal
[2006-09-20 14:51:16] <shawnlonas> Can anyone tell me about the DtdResolver used in uportal3\tests\org\jasig\portal\layout\uportal2\simple\SimpleUserLayoutManagerTest.java (and other tests)?
[2006-09-20 14:51:37] <EricDalquist> I think it is pretty much a drop in from uP2
[2006-09-20 14:52:02] <EricDalquist> what else do you need to know about it (I know a little, I think peterk put it in)
[2006-09-20 14:52:11] <shawnlonas> So if I move the location of up3userlayout.dtd I suspect that will break something
[2006-09-20 14:52:18] <shawnlonas> ?
[2006-09-20 14:53:04] <peterk> well, resolves dtd to local file ... I am not sure we want to change this anyhow
[2006-09-20 14:53:09] <EricDalquist> hrm, I'd imagine it would
[2006-09-20 14:53:23] <EricDalquist> I guess the question then is how does the DtdResolver know where to look for the DTDs?
[2006-09-20 14:53:33] <peterk> the whole dtd on the web thing is good for validation tools, but I can't think why a given installation would want to use it instead of the local copy
[2006-09-20 14:54:00] <peterk> Eric: it just knows to look for dtd directory in classpath, or something like that
[2006-09-20 14:54:35] <peterk> in fact, production installations shouldn't even do validation
[2006-09-20 14:55:49] <EricDalquist> well what happens if shawn moves the dtd location?
[2006-09-20 14:56:44] <peterk> nothing the JIRA issue will get closed
[2006-09-20 14:57:26] <shawnlonas>
[2006-09-20 14:57:58] <EricDalquist> good answer
[2006-09-20 14:58:00] <peterk> if you also modify the layout.xml, you'll have to make sure that DTD resolver picks up local id, not system id of the schema
[2006-09-20 14:59:49] <shawnlonas> I'm not sure I'm following you, Peter.
[2006-09-20 15:04:00] <peterk> uPortal encounters that schema in one case- when it reads layout from the DAO. It parses the layout, and during parsing it encounters the schema description (which includes both system and public ids). During parsing, SLM uses a helper class - entity resolver - which knows where to find a local copy of the layout.dtd. If you're changing the dtd location in the layout XML, make sure that the resolver can still recognize layout.dt
[2006-09-20 15:07:11] <shawnlonas> Should we move both the up3userlayout.dtd and up3layout.dtd? Thus far I have only been focusing on the up3userlayout.dtd?
[2006-09-20 15:08:25] * johnalewi1 (n=jlewis@uni1.unicon.net) has joined ##uportal
[2006-09-20 15:08:35] <peterk> ok, I guess if we want to be thorough we should modify all our layout XMLs to include the new URL. Then you should modify org.jasig.portal.layout.uportal2.simple.dao.hibernate.SerializingUserLayoutDao to print out the new url - this will cause newly created layouts to have the updated URL.
[2006-09-20 15:09:31] <peterk> but the DtdResolver should still work - it simply matches on "up3userlayout.dtd" anywhere in the location, and if it finds it, returns a local copy
[2006-09-20 15:10:47] <shawnlonas> If I rename the file and replace all references to the old name with the new name, it should work to the best of your knowledge?
[2006-09-20 15:11:20] <peterk> yes
[2006-09-20 15:11:56] <peterk> what I am saying, that there are also a couple of places where portal tries to write out full URL of that dtd - you'll need to replace those accordingly
[2006-09-20 15:12:15] <shawnlonas> What would be the best way to test it? Just deploy and run the portal or is there something else that I would need to do?
[2006-09-20 15:14:41] <peterk> I think the reason this whole issue came up is because a number of unit tests were failing (were trying to do parsing without a custom dtd resolver, etc.). Andrew (apetro) is probably the best person to ask about that.
[2006-09-20 15:15:05] <shawnlonas> ok
[2006-09-20 15:16:51] <shawnlonas> Also my plan is to rename "up3userlayout.dtd" to "userlayout-SLM-1.0.dtd" to reflect the fact that it is specific to SLM. Is "up3layout.dtd" dependent on something else (like the structure)? Or can I safely rename it "layout-1.0.dtd"?
[2006-09-20 15:21:42] <peterk> up3layout.dtd doesn't depend on anything, but other things can depend on it. If you search the project, you'll find one java, one xml and one xsl file referencing it.
[2006-09-20 15:22:32] <shawnlonas> excellent, I will find and replace all references. thx.
[2006-09-20 15:22:35] <peterk> Also, I am not sure that userlayout-SLM-1.0.dtd is a good name - it doesn't reflect the fact that this is essentially a port of uP2 layout XML to uP3 (but perhaps that's reflected in the path where you're planning on putting it)
[2006-09-20 15:23:12] <shawnlonas> The path will be: http://developer.ja-sig.org/projects/dtds/uportal/3/userlayout-SLM-1.0.dtd
[2006-09-20 15:23:21] <apetro> +1
[2006-09-20 15:25:57] <shawnlonas> Ok. Unless anyone objects I will plan to also move "up3layout.dtd" to "layout-1.0.dtd". The full path will be: http://developer.ja-sig.org/projects/dtds/uportal/3/layout-1.0.dtd
[2006-09-20 15:27:54] * peterk doubts
[2006-09-20 15:28:36] <peterk> we don't even have a name for what's described by layout-1.0.dtd - it's a quick draft of a uP3-specific layout - not even close to 1.0
[2006-09-20 15:28:57] <apetro> 0.1 ?
[2006-09-20 15:29:15] <peterk> that's closer ... why do we need it on the web again ?
[2006-09-20 15:31:17] <shawnlonas> personally, numbers less than 1.0 for versioning is a bit arbitrary in my opinion. If we ever change it we can go to 2.0, or 1.x.
[2006-09-20 15:32:00] <apetro> no
[2006-09-20 15:32:06] <apetro> 1.0 indicates releasedness
[2006-09-20 15:32:12] <apetro> it means that we've settled on something
[2006-09-20 15:32:22] <apetro> that we then have implicit backwards compatibility, upgrade path, etc. issues around
[2006-09-20 15:32:25] <apetro> it's a contract
[2006-09-20 15:32:30] <apetro> prior to 1.0, we're just screwing around
[2006-09-20 15:32:36] <apetro> which it sounds like is where we're at at this moment
[2006-09-20 15:32:55] <apetro> if we suspect that the dtd as it exists at this moment will not be the dtd that ships with the release in December
[2006-09-20 15:33:55] <peterk> except we could just number then according to the CVS version
[2006-09-20 15:34:04] <apetro> no
[2006-09-20 15:34:14] <apetro> CVS version changes do not necessarily reflect semantic changes
[2006-09-20 15:34:19] <apetro> change the comment? Didn't change the dtd
[2006-09-20 15:34:28] <apetro> fix the whitespace? Didn't change the dtd
[2006-09-20 15:34:40] <apetro> we could adopt the Maven practice of "SNAPSHOT"
[2006-09-20 15:34:47] <apetro> layout-SNAPSHOT.dtd
[2006-09-20 15:34:52] <peterk> right, and you wouldn't want to change all the references when doing that
[2006-09-20 15:34:53] <apetro> which indicates a moving target
[2006-09-20 15:35:04] <apetro> then all the references can be to SNAPSHOT
[2006-09-20 15:35:10] <apetro> SNAPSHOT isn't any particular version
[2006-09-20 15:35:13] <apetro> and can change arbitrarily
[2006-09-20 15:35:22] <apetro> and is working towards something that is a particular version
[2006-09-20 15:35:28] <peterk> I guess I am still wondering what's the value of having layout-MOVING-TARGEt.dtd on the ja-sig site
[2006-09-20 15:35:28] <apetro> which then gets a name that includes a version number
[2006-09-20 15:35:40] <apetro> so that the code can find it and resolve against it
[2006-09-20 15:35:50] <peterk> but the code should do local resolution anyway
[2006-09-20 15:35:56] <apetro> so that we've practiced the logistics of posting the DTDs
[2006-09-20 15:36:03] <apetro> so we'll be able to do it when a real release occurs
[2006-09-20 15:36:13] * johnalewi1 (n=jlewis@uni1.unicon.net) has left ##uportal
[2006-09-20 15:36:32] <peterk> why would you want production installation to fetch DTD from some web site (that may be down) instead of reading a local copy?
[2006-09-20 15:36:43] <apetro> right, so internally uPortal can use a local copy
[2006-09-20 15:36:47] <apetro> I need it to really be at that URL
[2006-09-20 15:36:52] <apetro> so that my tools can find it and use it
[2006-09-20 15:36:55] <apetro> Stylus Studio
[2006-09-20 15:36:57] <apetro> XML Spy
[2006-09-20 15:36:58] <apetro> XMLBuddy
[2006-09-20 15:36:59] <apetro> whatever
[2006-09-20 15:37:01] <EricDalquist> thats just what I was going to say
[2006-09-20 15:37:02] <peterk> ok, that's what I thought.
[2006-09-20 15:37:19] <EricDalquist> but uPortal itself should always use the dtdresolver and get the local version
[2006-09-20 15:37:40] <apetro> fair enough. So we still have the problem of getting this DTD onto the real actual web
[2006-09-20 15:37:51] <apetro> am I getting any buy-in on the Maven-style SNAPSHOT idea?
[2006-09-20 15:38:34] <shawnlonas> I guess I question when we will ever go back and change the references from SNAPSHOT to 1.0
[2006-09-20 15:39:01] <EricDalquist> yup +1 to SNAPSHOT
[2006-09-20 15:39:02] <peterk> I guess I would use HEAD instead
[2006-09-20 15:39:02] <apetro> when SNAPSHOT goes away so we have to?
[2006-09-20 15:39:23] <apetro> I'm not sure why we'd want to invent our own name for this when Maven has given us a name for the concept
[2006-09-20 15:39:27] <EricDalquist> lets go with the maven concepts since we're adopting that as our build platform
[2006-09-20 15:39:47] <peterk> HEAD just refers to head CVS branch - that makes it clear when something should be numbered - when it's branched
[2006-09-20 15:39:51] <peterk> or tagged
[2006-09-20 15:40:19] <apetro> naming it has little to do with branching or tagging
[2006-09-20 15:40:36] <apetro> SNAPSHOT becomes 1.0 when it's settled on enough that someone would actually be inconvenienced if it changed
[2006-09-20 15:40:45] <apetro> such that upgrade path logistics are worth considering
[2006-09-20 15:41:01] <apetro> that happens asynchronously with branches and releases, though presumably is a pre-requisite to an actual release tgag
[2006-09-20 15:41:03] <apetro> tag
[2006-09-20 15:41:30] <apetro> I guess what I'm saying is that the SNAPSHOT as of M10 and as of M11 may or may not be the same and whether they are or not doesn't need to be reflected in their names
[2006-09-20 15:42:36] <peterk> ok, I guess I am not used to maven terms... seems like it essentially means that it's a version out of head branch
[2006-09-20 16:00:38] * arybicki (n=arybicki@pool-71-107-26-50.lsanca.dsl-w.verizon.net) has joined ##uportal
[2006-09-20 16:00:56] * arybicki (n=arybicki@pool-71-107-26-50.lsanca.dsl-w.verizon.net) has left ##uportal
[2006-09-20 16:08:24] <apetro> okay
[2006-09-20 16:08:45] <apetro> Shawn and I just had a deep and heartfelt conversation about the subtle and nefarious issues of DTD naming and versioning
[2006-09-20 16:08:52] <apetro> so I think he's prepared to run with this...
[2006-09-20 16:13:41] <EricDalquist> ...
[2006-09-20 16:16:51] <shawnlonas> The plan is to append -SNAPSHOT to the name of the dtds, change all references to the SNAPSHOT version. When we do an official release, someone will need to create -1.0 and change all the references to point to that.
[2006-09-20 16:18:07] <shawnlonas> If it again goes into flux subsequently, we could go create another SNAPSHOT version and change the references to that until the next release version.
[2006-09-20 16:18:28] <EricDalquist> sounds like a good plan
[2006-09-20 16:18:32] <shawnlonas> Otherwise, if no changes are needed all references can remain.
[2006-09-20 16:19:16] <shawnlonas> It seems like it is a good plan if everyone touching the files knows the plan
[2006-09-20 16:19:53] <EricDalquist> yup
[2006-09-20 16:19:55] <shawnlonas> It sure would be nice to automate this process...
[2006-09-20 16:20:07] <EricDalquist> and I think once that initial release is done the DTDs won't change very often
[2006-09-20 16:20:14] <shawnlonas> true
[2006-09-20 16:22:22] <apetro> I don't think it would be nice to automate this
[2006-09-20 16:22:31] <apetro> automating it doesn't solve a real problem
[2006-09-20 16:22:59] <apetro> the real problem is the pain of maintaining multiple versions of DTDs and doing intelligent things to get between them and producing good upgrade paths
[2006-09-20 16:23:09] <shawnlonas> I'm not saying we should automate the decision
[2006-09-20 16:23:19] <apetro> and in the context of that pain, the value in automating the logistics of DTD naming is low
[2006-09-20 16:23:45] <apetro> my bad. Needless flame on my part.
[2006-09-20 16:24:00] <apetro> How about "Sure, it would be nice to automate this, but that isn't likely to hit the top of the priority queue"
[2006-09-20 16:24:43] <shawnlonas>
[2006-09-20 16:26:28] <shawnlonas> In the same folder as these DTDs I see "web-app_2_3.dtd" and "portlet-app_1_0.xsd". These appear to be local copies of files that we don't maintain. Should I create a separate location for the DTDs that we do maintain, or expect that we can intelligently pick between them?
[2006-09-20 16:27:09] <shawnlonas> (Not to mention that we have an XSD file in a DTD folder)
[2006-09-20 16:27:26] <EricDalquist> we should probably look at creating a better structure for these
[2006-09-20 16:27:52] <EricDalquist> create some '3rdparty' subdir to put those files in
[2006-09-20 16:28:09] <EricDalquist> and perhaps create different dirs for XSDs and DTDs?
[2006-09-20 16:30:00] <shawnlonas> ok. will do.
[2006-09-20 16:50:22] <EricDalquist> night all
[2006-09-20 18:32:31] * bszabo (n=bszabo@uni1.unicon.net) has left ##uportal
[2006-09-20 18:57:03] * shawnlonas (n=shawn@uni1.unicon.net) has left ##uportal
[2006-09-20 19:36:18] * dmccallum (n=dmccallu@uni1.unicon.net) has left ##uportal
[2006-09-20 19:46:44] * EricDalquist (n=dalquist@adsl-71-150-245-185.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
General
Content
Integrations