uPortal IRC Logs-2007-04-10

[09:35:26 EDT(-0400)] * deuce (n=deuce@ip70-162-119-62.ph.ph.cox.net) has joined ##uportal
[10:19:00 EDT(-0400)] <deuce> eric?
[10:20:00 EDT(-0400)] <EricDalquist> hey
[10:22:28 EDT(-0400)] <deuce> so, i was able to get the portal bootstrapped and initialized using the documentation
[10:23:14 EDT(-0400)] <EricDalquist> cool
[10:23:18 EDT(-0400)] <deuce> but i was wondering if there was any docs around adding new portlet applications
[10:23:26 EDT(-0400)] <EricDalquist> ah
[10:23:30 EDT(-0400)] <EricDalquist> lets see
[10:23:55 EDT(-0400)] <EricDalquist> apparently just a stub: http://www.ja-sig.org/wiki/display/UP3/Install+a+new+portlet+in+uPortal+3
[10:24:06 EDT(-0400)] <EricDalquist> I'll see if I can get that doc updated next
[10:24:10 EDT(-0400)] <deuce> sweeet
[10:24:14 EDT(-0400)] <deuce> :
[10:24:16 EDT(-0400)] <deuce>
[10:24:21 EDT(-0400)] <EricDalquist> unfortunatly the portlet manager is rather clunky and really needs some re-working
[10:24:50 EDT(-0400)] <deuce> agreed
[10:25:21 EDT(-0400)] <EricDalquist> plus there may be some issues with portlet management in the trunk until I get to some refactoring of the underlying object model & daos
[10:25:34 EDT(-0400)] <EricDalquist> the jist of what you do now is:
[10:25:51 EDT(-0400)] <EricDalquist> 1 - create new portlet application (a list of available portlet applications is provided to you)
[10:26:10 EDT(-0400)] <EricDalquist> 2 - create a new portlet based on one listed under the portlet app you just created
[10:28:56 EDT(-0400)] <deuce> for #1 .. is that through "Manage Portlet Applications"->"Add a Portlet Application" click thru?
[10:29:22 EDT(-0400)] <EricDalquist> yup
[10:30:00 EDT(-0400)] <deuce> what if i've deployed a new web app that's not being shown in the the dropdown?
[10:30:46 EDT(-0400)] <EricDalquist> hrm ... well in trunk I don't have a deployPortletApp ant target
[10:31:00 EDT(-0400)] <EricDalquist> so there isn't a way to run it through the pluto assembly process
[10:31:08 EDT(-0400)] <EricDalquist> so did you just drop a WAR in?
[10:31:14 EDT(-0400)] <deuce> si
[10:31:33 EDT(-0400)] <EricDalquist> yeah, I need to make a deployPortletApp target ...
[10:31:37 EDT(-0400)] <EricDalquist> give me ~ 15 minutes
[10:31:46 EDT(-0400)] <deuce> oh ok
[10:32:00 EDT(-0400)] <deuce> tanks
[10:32:03 EDT(-0400)] <EricDalquist> the pluto servlet needs to be added to the web.xml
[10:32:18 EDT(-0400)] <EricDalquist> you could peak at the web.xml from some other portlet war to see what is there
[10:32:22 EDT(-0400)] <EricDalquist> and add it by hand
[10:33:50 EDT(-0400)] <deuce> I'm using org.apache.pluto.core.PortletServlet .. same as TestPortlet1
[10:35:43 EDT(-0400)] <EricDalquist> ok ... if you have the servlet with init-param and mapping try restarting tomcat
[10:36:46 EDT(-0400)] <EricDalquist> I haven't played a whole lot with adding new portlets while running since we did the pluto upgrade
[10:41:40 EDT(-0400)] <deuce> ah .. did the init-param requirements change?
[10:42:07 EDT(-0400)] <EricDalquist> they might have ... I never muck with the web.xml's manually and leave the deploy utilities to add the pluto specifics
[10:42:18 EDT(-0400)] <esm> init params are differient in 1.1
[10:42:24 EDT(-0400)] <EricDalquist> I should have an updated root build.xml for you shortly with a deployPortletApp
[10:42:36 EDT(-0400)] <EricDalquist> morning EricDalquist
[10:42:39 EDT(-0400)] <EricDalquist> esm *
[10:42:42 EDT(-0400)] <esm>
[10:42:46 EDT(-0400)] <deuce> haha
[10:42:46 EDT(-0400)] <EricDalquist> friggin autocomplet
[10:43:04 EDT(-0400)] * deuce thinks eric's been working too many hours lately
[10:43:04 EDT(-0400)] <esm> there are pluto ant tasks as well to do the webxml munging.
[10:44:02 EDT(-0400)] * EricDalquist agrees with deuce
[10:44:07 EDT(-0400)] <EricDalquist> yeah
[10:44:16 EDT(-0400)] <EricDalquist> thats what I'm adding to the uP3 build.xml
[10:44:27 EDT(-0400)] <EricDalquist> a clone of the uP2 deployPortletApp target
[10:44:33 EDT(-0400)] <EricDalquist> using the pluto ant task
[10:47:55 EDT(-0400)] <EricDalquist> so ... with both of you here
[10:48:02 EDT(-0400)] <EricDalquist> what are the thoughts on IObjectIds
[10:48:04 EDT(-0400)] <EricDalquist> do we need them
[10:48:07 EDT(-0400)] <EricDalquist> if we do
[10:48:11 EDT(-0400)] <EricDalquist> how do we handle creating them
[10:48:20 EDT(-0400)] <esm> you saw the wiki page?
[10:48:25 EDT(-0400)] <EricDalquist> yeah
[10:48:36 EDT(-0400)] <deuce> please to point me
[10:48:49 EDT(-0400)] <EricDalquist> http://www.ja-sig.org/wiki/display/UP3/ObjectID+Requirements
[10:49:00 EDT(-0400)] <esm> http://www.ja-sig.org/wiki/display/UP3/ObjectID+Requirements
[10:49:14 EDT(-0400)] <EricDalquist> yay IRC lag
[10:49:18 EDT(-0400)] <esm>
[10:50:29 EDT(-0400)] <EricDalquist> hey deuce
[10:50:34 EDT(-0400)] <deuce> yo
[10:50:36 EDT(-0400)] <EricDalquist> there is an updated build.xml in trunk
[10:50:41 EDT(-0400)] <EricDalquist> with a deployPortletApp ant target
[10:50:46 EDT(-0400)] <deuce> ty ty
[10:51:25 EDT(-0400)] <esm> well i don't know if we need them or not. But they could use a common implementation and a common interface even.
[10:51:36 EDT(-0400)] <deuce> when IObjectId was originally introduced i had wondered why it just wasn't a long
[10:51:50 EDT(-0400)] <EricDalquist> or a string or whatever it type that id needed to be
[10:52:01 EDT(-0400)] <EricDalquist> yeah
[10:52:30 EDT(-0400)] <deuce> i just always view object ids as numbers
[10:52:54 EDT(-0400)] <esm> well, because - I think - a PortletWindow with ID of "1" isn't identical or equivilant to a UserId with an id of "1"
[10:53:26 EDT(-0400)] <deuce> sounds like a programming error to compare object ids of different types tho
[10:53:43 EDT(-0400)] <EricDalquist> well, not all are numbers and that is part of the problem with the current IObjectId interface
[10:53:53 EDT(-0400)] <EricDalquist> and I do see some value in strongly typed Ids
[10:54:05 EDT(-0400)] <EricDalquist> but it sure adds a whole other level of complexity
[10:54:07 EDT(-0400)] <esm> deuce: possibly, but what if something wanted to deal with a collection of ids
[10:54:34 EDT(-0400)] <deuce> they'd cry
[10:54:43 EDT(-0400)] <esm> hehehe
[10:54:48 EDT(-0400)] <deuce> yeah i see
[10:55:10 EDT(-0400)] <esm> we can go back to the idea that the implementation associates the id with the type
[10:55:14 EDT(-0400)] <deuce> but i also don't like the complexity
[10:55:33 EDT(-0400)] <esm> i forget how that works
[10:55:38 EDT(-0400)] <esm> yeah the complexity stinks
[10:56:09 EDT(-0400)] <esm> currently, in the maven-refactor branch, the complexity has been simplified somewhat
[10:56:28 EDT(-0400)] <EricDalquist> so if we went the AbstractIdFactory route
[10:56:37 EDT(-0400)] <EricDalquist> what is your idea for the impl of the method:
[10:56:44 EDT(-0400)] <EricDalquist> public static <T extends IObjectId> T createId(Class<T> clazz, String id)
[10:56:57 EDT(-0400)] <esm> Yeah, that sounds good - one sec...
[10:57:41 EDT(-0400)] <EricDalquist> and how does it work in both a running web app, from a command line tool and within hibernate custom types?
[10:59:33 EDT(-0400)] <EricDalquist> one way to help with the hibernate issue is to make sure code never assumes anything more than the interface
[10:59:42 EDT(-0400)] <esm> Are there special considerations for the webapp or types?
[10:59:42 EDT(-0400)] <EricDalquist> and hibernate just has its own interface impl
[10:59:47 EDT(-0400)] <esm> ok
[10:59:56 EDT(-0400)] <deuce> that's always a good assumption
[11:00:15 EDT(-0400)] <EricDalquist> well, just making sure that wereever AbstractIdFactory is getting its configuration from is always available
[11:00:19 EDT(-0400)] <EricDalquist> yeah
[11:00:53 EDT(-0400)] <EricDalquist> hrm ...
[11:01:10 EDT(-0400)] <esm> what webapps need objectids?
[11:01:14 EDT(-0400)] <esm> are they framework apps?
[11:01:24 EDT(-0400)] <EricDalquist> ah sorry I meant running within the uP3 webapp
[11:01:49 EDT(-0400)] <EricDalquist> so AbstractIdFactory is has some logic to determine what impl to return for each interface Class passed in
[11:01:54 EDT(-0400)] <esm> yes
[11:02:05 EDT(-0400)] <EricDalquist> is that logic hard coded?
[11:02:13 EDT(-0400)] <EricDalquist> or is it reading it from some config somewhere?
[11:02:16 EDT(-0400)] <deuce> there definitely may be an external web app that needs to be IObjectId aware
[11:02:16 EDT(-0400)] <esm> I was looking in fisheye, i had an implementation somewhere in the original maven branch
[11:02:21 EDT(-0400)] <esm> no spring injected
[11:02:31 EDT(-0400)] <esm> well,
[11:02:40 EDT(-0400)] <EricDalquist> ok ... so spring injected into a class that is servicing calls via a static method
[11:02:43 EDT(-0400)] <esm> the mapping of interfaces to impls was spring injected
[11:03:08 EDT(-0400)] <esm> EricDalquist: yes
[11:03:14 EDT(-0400)] <EricDalquist> is that going to work from a command line tool? what needs to be setup by that tool for AbstractIdFactory to work?
[11:03:53 EDT(-0400)] <esm> AbstractidFactory would need a spring application context, and access to any of the interfaces and impls it required
[11:04:11 EDT(-0400)] <esm> those dependencies would be theoretically in a pom.xml
[11:04:11 EDT(-0400)] <EricDalquist> ok
[11:05:03 EDT(-0400)] <esm> e.g. the tool would depend on spring, and it would depend on the up3-objectid subproject.
[11:05:10 EDT(-0400)] <esm> (or whatever we name it)
[11:05:31 EDT(-0400)] <EricDalquist> and the tool would load up the appropriate bean context to ensure everything was configured
[11:06:06 EDT(-0400)] <esm> yes, i guess - I don't have much experience with the uP command line tools.
[11:06:36 EDT(-0400)] <esm> I would think that there would be some base classes (or class) that command line tools could extend.
[11:07:18 EDT(-0400)] <esm> the base class would do stuff like validating the configuration or something
[11:07:29 EDT(-0400)] <EricDalquist> well, the issue is that much of the code is going to have to be able to be run by a command line tool (XML import would need DAOs/registries/caching) and run in the webapp
[11:07:55 EDT(-0400)] <EricDalquist> we'll likely have different context XMLs for the command line tools
[11:07:56 EDT(-0400)] <esm> i mean you have JUnit tests that need a spring bean context, and the base unit test asks the concrete class for the bean file and then loads it up, right?
[11:08:10 EDT(-0400)] <EricDalquist> yeah (don't get me started on those though )
[11:08:19 EDT(-0400)] <esm> ahah ok I won't
[11:08:26 EDT(-0400)] <EricDalquist> I guess right now I'm still going back and forth on if IObjectId is worth the complexity
[11:08:35 EDT(-0400)] <esm> sure i understand
[11:08:36 EDT(-0400)] <EricDalquist> so thats why I'm just asking all these things out loud
[11:08:46 EDT(-0400)] <EricDalquist> trying to see if I can convince myself one way or the other
[11:08:48 EDT(-0400)] <esm> I don't know what the impact would be if we took it out
[11:08:55 EDT(-0400)] <EricDalquist> yeah
[11:09:01 EDT(-0400)] <esm> we can try it
[11:09:06 EDT(-0400)] <EricDalquist> I'd hate to go through that work just to realize we really need it
[11:09:10 EDT(-0400)] <esm>
[11:09:12 EDT(-0400)] <EricDalquist> but that may be what we need to do
[11:09:16 EDT(-0400)] <EricDalquist> deuce?
[11:09:22 EDT(-0400)] <deuce> si
[11:09:27 EDT(-0400)] <EricDalquist> thoughts?
[11:09:48 EDT(-0400)] <deuce> oh .. hehe i got distracted
[11:10:05 EDT(-0400)] <EricDalquist>
[11:10:33 EDT(-0400)] <esm> http://developer.ja-sig.org/source/browse/~br=up3-maven2-integration/jasigsvn/up3/branches/maven2-integration/portal-core-api/src/main/java/org/jasig/portal/core
[11:11:02 EDT(-0400)] <esm> the ITypedObjectIdFactory (it doesn't use generics)
[11:12:32 EDT(-0400)] <EricDalquist> hrm ... ok
[11:12:50 EDT(-0400)] <EricDalquist> well I'm going to spend a bit in my local env and see what breaks badly if I just delete *ObjectId
[11:12:53 EDT(-0400)] <esm> anyway, just what I did a while back.
[11:13:16 EDT(-0400)] <deuce> dont do it!!
[11:13:24 EDT(-0400)] <EricDalquist>
[11:13:48 EDT(-0400)] <deuce> i suspect there will be a lot that breaks
[11:13:55 EDT(-0400)] <EricDalquist> yeah
[11:14:08 EDT(-0400)] <EricDalquist> the only bits I'm really worried about are places that use composite ids
[11:14:20 EDT(-0400)] <deuce> yea
[11:14:27 EDT(-0400)] <esm> If there are classes which have a field of type IObjectId or one of its sub-interfaces and this class delegates equals() to the IObjectId field, I think that is where they are valuble
[11:14:27 EDT(-0400)] <EricDalquist> like IPortletDeploymentId actually contains a IPortletApplicationDeploymentId
[11:14:34 EDT(-0400)] <esm> BUT
[11:14:42 EDT(-0400)] <esm> that may not happen often at all
[11:15:16 EDT(-0400)] <esm> if at all.
[11:15:28 EDT(-0400)] <deuce> what about in maps
[11:16:32 EDT(-0400)] <esm> ah right
[11:16:36 EDT(-0400)] <esm> yeah.
[11:16:45 EDT(-0400)] <EricDalquist> so Map<IObjectId, foo> versus Map<Integer, foo> ?
[11:16:48 EDT(-0400)] <deuce> ah .. well if someone decides to map objects of different types
[11:16:54 EDT(-0400)] <deuce> yeah
[11:16:59 EDT(-0400)] <esm> right if there are places where IObjectId is a key
[11:17:16 EDT(-0400)] <esm> anytime .equals(), compareTo(), or whathaveyou may be called on it
[11:17:21 EDT(-0400)] <esm> .hashcode()
[11:18:04 EDT(-0400)] <esm> I'm trying to use eclipse to see if there are classees with IObjectId as a field and I turn up zilch, but that may mean my search is going bad.
[11:18:30 EDT(-0400)] <deuce> grep and destroy
[11:19:29 EDT(-0400)] <EricDalquist> man ... I'm so torn on this
[11:19:40 EDT(-0400)] <EricDalquist> on one hand all the complexity of dealing with this is a royal pain
[11:19:42 EDT(-0400)] <deuce> coin flip?
[11:19:48 EDT(-0400)] <EricDalquist> on the other I really like strongly typed things
[11:19:52 EDT(-0400)] <EricDalquist>
[11:20:02 EDT(-0400)] <EricDalquist> rock paper scissors
[11:20:10 EDT(-0400)] <deuce> i'm with ya on that
[11:20:33 EDT(-0400)] <EricDalquist> the complexity vs strong typing or R.P.S?
[11:20:56 EDT(-0400)] <deuce> complexity vs typing
[11:22:34 EDT(-0400)] <EricDalquist> so esm, with the AbstractIdFactory ... what are your ideas for the impl and configuring it?
[11:22:44 EDT(-0400)] <EricDalquist> oh and can one of you try getting to http://www.ja-sig.org/wiki/display/JCH/Home
[11:22:53 EDT(-0400)] <esm> sorry one sec phone
[11:23:24 EDT(-0400)] <EricDalquist> k
[11:23:38 EDT(-0400)] <deuce> no likey my password
[11:23:49 EDT(-0400)] <EricDalquist> can't log in at all?
[11:23:54 EDT(-0400)] <deuce> nope
[11:23:59 EDT(-0400)] <EricDalquist> hrm, well thats a different issue
[11:24:02 EDT(-0400)] <deuce> trying to tell me somethin?
[11:24:08 EDT(-0400)] <EricDalquist>
[11:24:20 EDT(-0400)] <deuce> damn .. i need to split to work
[11:24:36 EDT(-0400)] <deuce> i'll be on a little later
[11:24:37 EDT(-0400)] <EricDalquist> np, thanks for the input and catch you later
[11:24:54 EDT(-0400)] <EricDalquist> this all gets logged to the wiki if you feel like reading what you miss
[11:25:08 EDT(-0400)] <deuce> and thanks for the portletApp goodness
[11:25:12 EDT(-0400)] <deuce> peace
[11:25:13 EDT(-0400)] <EricDalquist> yup
[11:25:18 EDT(-0400)] * deuce (n=deuce@ip70-162-119-62.ph.ph.cox.net) has left ##uportal
[11:34:52 EDT(-0400)] <EricDalquist> hey esm, let me know when you have a few to talk a bit more about ids and what we want to work on over the next 2 weeks
[11:35:26 EDT(-0400)] <esm> ok i gotta hit the head i'll brb
[11:35:34 EDT(-0400)] <esm> i'm upgrading a sun server and it is taking its time
[11:35:38 EDT(-0400)] <esm> brb
[11:36:07 EDT(-0400)] <EricDalquist> np
[11:50:13 EDT(-0400)] <esm> ok back
[11:50:19 EDT(-0400)] <EricDalquist> cool
[11:51:10 EDT(-0400)] <esm> so... blah to objectIds. I think we could spend just as much time excising objectids as refactoring them
[11:51:35 EDT(-0400)] <esm> what do you think
[11:53:12 EDT(-0400)] <EricDalquist> I guess I'd like a quick overview of plans for the AbstractIdFactory
[11:53:18 EDT(-0400)] <EricDalquist> just to make sure I understand it
[11:53:42 EDT(-0400)] <esm> Ok. Good idea. Sometimes I get lost.
[11:53:42 EDT(-0400)] <EricDalquist> like how it is configured and how it creates object instances
[11:56:06 EDT(-0400)] <EricDalquist> so it AbstractIdFactory would be used directly
[11:56:14 EDT(-0400)] <EricDalquist> using that nifty generic method
[11:56:20 EDT(-0400)] <EricDalquist> static method*
[11:56:36 EDT(-0400)] <EricDalquist> correct?
[11:57:18 EDT(-0400)] <esm> yes, AbsractIdFactory would be used directly by clients, and I think we should be able to use the generic method (I hesitate since my generic experience is slim)
[11:57:30 EDT(-0400)] <esm> AbstractIdFactory is singleton, and is instantiated by Spring
[11:57:57 EDT(-0400)] <esm> let me give you alink to the spring config file
[11:57:58 EDT(-0400)] <EricDalquist> ok ... thats a part I'm un-clear on
[11:58:02 EDT(-0400)] <esm> ok
[11:58:42 EDT(-0400)] <EricDalquist> would clients call a static method on AbstractIdFactory or would a singleton AbstractIdFactoring instacne be injected into code that needs it and a non-static method be used?
[11:59:01 EDT(-0400)] <esm> The former, was what I was thinking.
[11:59:06 EDT(-0400)] <EricDalquist> ok
[11:59:17 EDT(-0400)] <esm> we can go the other way but then we start getting more complex
[11:59:21 EDT(-0400)] <esm> I think
[11:59:34 EDT(-0400)] <EricDalquist> and the when the singleton instance is created the member method populates a static member variable with the configuration
[12:00:21 EDT(-0400)] <esm> Kind of. I was envisioning there would be a configuration object that the singleton instance uses.
[12:00:42 EDT(-0400)] <EricDalquist> ok
[12:01:15 EDT(-0400)] <esm> The configuration object is configured by Spring, and I guess is singleton as well. The configuration object is injected into the AbstractFactory
[12:01:44 EDT(-0400)] <EricDalquist> what would the configuration object consist of?
[12:03:10 EDT(-0400)] <esm> A map of id types to factories.
[12:03:26 EDT(-0400)] <esm> so
[12:03:59 EDT(-0400)] <esm> a client calls AbstractFactory.createId(IUserId.class, "id");
[12:04:04 EDT(-0400)] <EricDalquist> ok .. so we have a generic factory interface that we will need an impl of for each type of ID we want to be able to create
[12:04:11 EDT(-0400)] <esm> right!
[12:05:22 EDT(-0400)] <esm> (fisheye is being slow)
[12:05:38 EDT(-0400)] <EricDalquist> yeah
[12:05:51 EDT(-0400)] <esm> I can show you the config file for spring
[12:06:00 EDT(-0400)] <EricDalquist> I'm hoping the eventual move to the new server is sooner rather than later
[12:06:41 EDT(-0400)] <esm> here is my suggestion - I can put up a wiki page on how I did things in the original maven 2 branch, like today
[12:06:51 EDT(-0400)] <EricDalquist> ok
[12:06:56 EDT(-0400)] <esm> how the client would use the factory
[12:06:56 EDT(-0400)] <EricDalquist> that would be good
[12:06:59 EDT(-0400)] <esm> and how the factory is configured
[12:07:02 EDT(-0400)] <esm> etc.
[12:07:03 EDT(-0400)] <EricDalquist> then I can read it without bugging you
[12:07:18 EDT(-0400)] <esm> well, at least we coudl go point by point over it together
[12:07:25 EDT(-0400)] <EricDalquist> yeah
[12:07:36 EDT(-0400)] <EricDalquist> (thanks again for all your help on this stuff)
[12:07:45 EDT(-0400)] <esm> oh no problem its what I love to do
[12:07:57 EDT(-0400)] <esm> i just don't want to slow down your progress.
[12:08:05 EDT(-0400)] <EricDalquist> don't worry about that
[12:08:34 EDT(-0400)] <esm> ok
[12:08:39 EDT(-0400)] <esm> lets play what if
[12:08:47 EDT(-0400)] <EricDalquist> ok
[12:09:12 EDT(-0400)] <esm> lets say what if we leave object ids alone for now - we go with what is in maven-refactor now, and pretend that object ids are "done" for now
[12:09:32 EDT(-0400)] <esm> what would we want to do for the next two weeks prior to th emeeting?
[12:10:08 EDT(-0400)] <EricDalquist> hrm
[12:10:08 EDT(-0400)] <esm> should we decide/discuss what modules we would want to have?
[12:10:14 EDT(-0400)] <EricDalquist> yeah
[12:10:16 EDT(-0400)] <esm> well
[12:11:02 EDT(-0400)] <esm> do we need to also discuss what may be missing from the build/command line? E.g. you just added a target for duece. But maybe the command line stuff is easy...
[12:11:26 EDT(-0400)] <EricDalquist> I think that would be good to cover
[12:12:07 EDT(-0400)] <esm> I'm presuming as things stand right now with the maven/ant build that there will be mixed reactions mostly because it is a little slow.
[12:12:21 EDT(-0400)] <esm> I'm thinking that its important to make a good first impression at the dev meeting when this is introduced
[12:12:34 EDT(-0400)] <EricDalquist> yeah
[12:12:42 EDT(-0400)] <esm> I mean, do you think that too?
[12:12:52 EDT(-0400)] <esm> it seems that not too many people are in th up3 code base currently
[12:12:54 EDT(-0400)] <EricDalquist> yeah I agree that the impression is very important
[12:12:57 EDT(-0400)] <esm> ok
[12:12:59 EDT(-0400)] <EricDalquist> and that it is slow
[12:13:21 EDT(-0400)] <EricDalquist> I think something I'm going to to today (because it won't take too long) is remove the javadoc from packaging
[12:13:28 EDT(-0400)] <EricDalquist> since that is pointless and slow
[12:13:40 EDT(-0400)] <EricDalquist> I'm just going to tweak the jasig-parent pom
[12:14:04 EDT(-0400)] <EricDalquist> other ideas on making it a better experiance?
[12:14:15 EDT(-0400)] <esm> ok that sounds good. I can work on creating a profile that can be activated (by using 'mvn -Pjavadoc' or something) that can activate those goodies
[12:14:48 EDT(-0400)] <esm> hmm
[12:14:49 EDT(-0400)] <EricDalquist> ok, lets not worry about that profile for now
[12:14:52 EDT(-0400)] <esm> ok
[12:14:59 EDT(-0400)] <EricDalquist> that can be a post-dev meeting task
[12:15:23 EDT(-0400)] <esm> what about making an assembly for a quickstart
[12:15:34 EDT(-0400)] <EricDalquist> that would be good to have
[12:15:35 EDT(-0400)] <esm> you know how andrew or someone always has to build a quickstart after a release?
[12:15:59 EDT(-0400)] <esm> we could create an assembly and show people how easy buildign a quickstart can be
[12:16:09 EDT(-0400)] <EricDalquist> yeah
[12:16:11 EDT(-0400)] <esm> quickstarts would be out the same day a release came out
[12:16:44 EDT(-0400)] <esm> hmm, let me think on this some more
[12:17:26 EDT(-0400)] <esm> i think in general the bad impressions will come from slowness and additional steps needed to be taken between iterations
[12:17:29 EDT(-0400)] <esm> mvn install, etc.
[12:17:32 EDT(-0400)] <EricDalquist> yeah
[12:17:48 EDT(-0400)] <EricDalquist> thats why I added the deploy-up3war ant task
[12:17:55 EDT(-0400)] <EricDalquist> but that is still a bit slower since
[12:18:05 EDT(-0400)] <EricDalquist> we're never going to compete with how 'fast' ant was
[12:18:13 EDT(-0400)] <EricDalquist> since it would just compile and deploy the changed files
[12:18:25 EDT(-0400)] <esm> well, that is where building the maven plugin would help
[12:18:33 EDT(-0400)] <EricDalquist> I think a big part
[12:18:36 EDT(-0400)] <EricDalquist> ;oops
[12:18:47 EDT(-0400)] <EricDalquist> what do you mean wrt the plugin?
[12:19:15 EDT(-0400)] <esm> does the deploy-up3war ant task compile code?
[12:19:24 EDT(-0400)] <EricDalquist> yeah
[12:19:34 EDT(-0400)] <esm> well anyway what I mean is that maven can just compile changed files
[12:20:00 EDT(-0400)] <EricDalquist> it does an install on uportal3-impl then an install on uP3 then deploys the WAR
[12:20:07 EDT(-0400)] <esm> ah ok
[12:20:27 EDT(-0400)] <esm> maven does the work anyway.
[12:20:33 EDT(-0400)] <EricDalquist> yeah
[12:21:48 EDT(-0400)] <esm> sorry still thinking.
[12:21:55 EDT(-0400)] <EricDalquist> np
[12:22:17 EDT(-0400)] <esm> one step that takes a long time too - when building the ear - is assembling the bundled portlets.
[12:22:53 EDT(-0400)] <EricDalquist> yeah, I'm not as worried about that since people probably won't be running that task very often
[12:24:09 EDT(-0400)] <EricDalquist> there are two areas that need attension 'how do I develop uP3 (code or style) quickly' and 'how do I develop a portlet on uP3 quickly'
[12:24:17 EDT(-0400)] <EricDalquist> the second one hasn't really changed from uP2
[12:24:33 EDT(-0400)] <EricDalquist> the first one currently affects the uportal3-impl and uP3 modules
[12:25:52 EDT(-0400)] <esm> regarding the first area: you are speaking of the steps taken to make a code change and then pushing it out to your development tomcat
[12:26:01 EDT(-0400)] <EricDalquist> yup
[12:26:49 EDT(-0400)] <esm> I think at some point developers are going to need, or want, to dig beneath the abstraction.
[12:27:07 EDT(-0400)] <EricDalquist> ?
[12:27:28 EDT(-0400)] <esm> they will realize: hey, I just modified a class (or three) in the up3-impl subproject. I can just run 'mvn package' and copy the resulting jar into my Tomcat, and bounce tomcat.
[12:27:39 EDT(-0400)] <EricDalquist> ah yeah
[12:27:58 EDT(-0400)] <esm> i'm sorry, dig beneath the ant abstrction
[12:28:05 EDT(-0400)] <EricDalquist> I'd rather just be able to educate people on that way of doing things
[12:28:37 EDT(-0400)] <EricDalquist> since as we chop things up more and more you'll only really need to wait for package to run on that sub-project
[12:28:41 EDT(-0400)] <EricDalquist> er module
[12:28:45 EDT(-0400)] <esm> yeah exactly.
[12:28:54 EDT(-0400)] <EricDalquist> and just copy the artifact to tomcat and bounce tomcat
[12:29:10 EDT(-0400)] <esm> I think we can ease the transition from ant to maven but I don't think we should make it a goal to abstract maven away using ant tasks
[12:29:19 EDT(-0400)] <EricDalquist> ok
[12:29:20 EDT(-0400)] <esm> (not that I think that we are doing that)
[12:30:01 EDT(-0400)] <esm> I think the ant tasks we have right now are needed, especially for a smooth transition, but I think it will benefit everyone, including the core developers, if they understand that learning the maven way is the best way to go.
[12:30:19 EDT(-0400)] <esm> It gets tricky when you modify spring files...
[12:30:23 EDT(-0400)] <EricDalquist> yeah
[12:30:35 EDT(-0400)] <esm> this is somethign I don't nkow about spring
[12:30:48 EDT(-0400)] <esm> can it find its *.xml files on the class path?
[12:30:58 EDT(-0400)] <EricDalquist> yeah, I think it can
[12:31:06 EDT(-0400)] <EricDalquist> it uses a very nice Resource abstraction
[12:31:10 EDT(-0400)] <esm> can we create a sub-project of just the xml files?
[12:31:15 EDT(-0400)] <esm> and package them in a jar
[12:31:25 EDT(-0400)] <EricDalquist> probably
[12:31:33 EDT(-0400)] <EricDalquist> the root applictionContext.xml probably not
[12:31:46 EDT(-0400)] <EricDalquist> but that should be able to source them in via classpath:/foo.xml references
[12:32:20 EDT(-0400)] <esm> sorry one sec phone
[12:32:57 EDT(-0400)] <EricDalquist> k
[12:37:57 EDT(-0400)] <esm> ok back
[12:38:01 EDT(-0400)] <EricDalquist> ok
[12:38:21 EDT(-0400)] <EricDalquist> so ... the spring context issue is just a smaller part of the bigger issue of resource in the WAR
[12:38:29 EDT(-0400)] <esm> so packaging up the spring files as a jar lets people follow the same pattern
[12:38:31 EDT(-0400)] <esm> right
[12:38:32 EDT(-0400)] <EricDalquist> we run into the same problem with the XSL/XML
[12:38:35 EDT(-0400)] <esm> yeah I didn't think of that
[12:39:01 EDT(-0400)] <EricDalquist> the run package and copy the artifact trick works well for the modules the WAR depends on
[12:39:11 EDT(-0400)] <EricDalquist> but you really need to run install and then copy
[12:39:26 EDT(-0400)] <EricDalquist> so that when you do need to tweak the WAR module you can still just run install and copy
[12:39:39 EDT(-0400)] <esm> true, yes
[12:41:50 EDT(-0400)] <EricDalquist> so what needs to be documented wrt this whole process?
[12:42:35 EDT(-0400)] <esm> sorry ... was looking at the maven war plugin documentation to see if it can make any of this easier
[12:42:53 EDT(-0400)] <EricDalquist> any luck?
[12:43:21 EDT(-0400)] <esm> well http://maven.apache.org/plugins/maven-war-plugin/examples/war-overlay.html
[12:43:26 EDT(-0400)] <esm> some ideas but nothing yet.
[12:43:55 EDT(-0400)] <esm> i was thinging tha tsomeone could use the 'war:exploaded' goal from inside the up3 webapp
[12:44:08 EDT(-0400)] <esm> with the destination directory set to their Tomcat webapp directory
[12:44:57 EDT(-0400)] <esm> http://maven.apache.org/plugins/maven-war-plugin/exploded-mojo.html
[12:45:01 EDT(-0400)] <EricDalquist> wouldn
[12:45:12 EDT(-0400)] <EricDalquist> wouldn't that just skip the files -> WAR -> files step?
[12:45:23 EDT(-0400)] <EricDalquist> or does that skip copying the dependencies?
[12:46:42 EDT(-0400)] <esm> I think my idea was that using the 'mvn war:exploded' woudl copy over just files that had changed in the webapp, and it would include dependencies (but they would be dependencies from the repository, it woudln't obviate the need for a 'mvn install' of the dependencies)
[12:46:56 EDT(-0400)] <EricDalquist> ah
[12:47:10 EDT(-0400)] <EricDalquist> does it work that way?
[12:48:13 EDT(-0400)] <esm> I don't know but let me check
[12:48:17 EDT(-0400)] <EricDalquist> k
[12:48:36 EDT(-0400)] <esm> it will also - the war plugin that is - explode the dependant jars if you want
[12:48:50 EDT(-0400)] <esm> wait never mind strike that
[12:58:17 EDT(-0400)] <EricDalquist> so strike the whole war:exploded?
[12:58:24 EDT(-0400)] <EricDalquist> or just the dependend jar issue?
[13:01:50 EDT(-0400)] <esm> dependant jar
[13:01:57 EDT(-0400)] <esm> but i'm getting mad at the war:exploded
[13:02:06 EDT(-0400)] <EricDalquist> so the war:explode may still speed things up a bit
[13:02:16 EDT(-0400)] <EricDalquist> how would the tomcat dir be specified
[13:02:16 EDT(-0400)] <esm> yeah
[13:02:18 EDT(-0400)] <esm> mvn -X -DwebappDirectory=$TC_HOME/webapps/uP3 war:exploded
[13:02:47 EDT(-0400)] <esm> that is the command i'm running. But for some reason my command line property webappDirectory isn't overriding the default location
[13:03:08 EDT(-0400)] <esm> $TC_HOME is my CATALINA_HOME essentially
[13:03:08 EDT(-0400)] <EricDalquist> hrm
[13:03:11 EDT(-0400)] <EricDalquist> well
[13:03:33 EDT(-0400)] <EricDalquist> removing the javadoc building from the package phase halved the time to run deploy-up3war on my laptop
[13:07:11 EDT(-0400)] <esm> nice. I modified the maven-war-plugin config in the uP3/pom.xml to deploy to my webappDirectory
[13:07:17 EDT(-0400)] <esm> so it copies everything every time
[13:07:21 EDT(-0400)] <esm> but it is still pretty quick
[13:07:53 EDT(-0400)] <esm> esm@clue:~/workspace/up3-refactor/uP3$ svn diff pom.xml
[13:07:53 EDT(-0400)] <esm> Index: pom.xml
[13:07:53 EDT(-0400)] <esm> ===================================================================
[13:07:53 EDT(-0400)] <esm> — pom.xml (revision 11940)
[13:07:53 EDT(-0400)] <esm> +++ pom.xml (working copy)
[13:07:54 EDT(-0400)] <esm> @@ -78,4 +78,14 @@
[13:07:56 EDT(-0400)] <esm> </plugin>
[13:07:58 EDT(-0400)] <esm> </plugins>
[13:08:00 EDT(-0400)] <esm> </reporting>
[13:08:02 EDT(-0400)] <esm> + <build>
[13:08:04 EDT(-0400)] <esm> + <plugins>
[13:08:06 EDT(-0400)] <esm> + <plugin>
[13:08:08 EDT(-0400)] <esm> + <artifactId>maven-war-plugin</artifactId>
[13:08:10 EDT(-0400)] <esm> + <configuration>
[13:08:12 EDT(-0400)] <esm> + <webappDirectory>/home/esm/apache-tomcat-5.5.17-up3/webapps/uP3</webappDirectory>
[13:08:14 EDT(-0400)] <esm> + </configuration>
[13:08:16 EDT(-0400)] <esm> + </plugin>
[13:08:18 EDT(-0400)] <esm> + </plugins>
[13:08:20 EDT(-0400)] <esm> + </build>
[13:08:22 EDT(-0400)] <esm> </project>
[13:08:43 EDT(-0400)] <esm> then i can run 'mvn war:exploded'
[13:09:03 EDT(-0400)] <EricDalquist> too bad it doesn't work from the cli
[13:09:37 EDT(-0400)] <esm> right. the base tomcat dir can be made into a property
[13:09:51 EDT(-0400)] <esm> and/or even look at catalina hom
[13:10:05 EDT(-0400)] <esm> so you woudln't have to hard code it
[13:10:08 EDT(-0400)] <EricDalquist> hrm ... ok
[13:10:12 EDT(-0400)] <esm> I wonder if uP3 works with jetty
[13:10:14 EDT(-0400)] <esm> http://maven.apache.org/plugins/maven-war-plugin/examples/rapid-testing-jetty6-plugin.html
[13:10:34 EDT(-0400)] <EricDalquist> so what does war:explode get us vs package & copy
[13:11:03 EDT(-0400)] <esm> esm@clue:~/workspace/up3-refactor/uP3$ svn diff pom.xml
[13:11:03 EDT(-0400)] <esm> Index: pom.xml
[13:11:03 EDT(-0400)] <esm> ===================================================================
[13:11:03 EDT(-0400)] <esm> — pom.xml (revision 11940)
[13:11:03 EDT(-0400)] <esm> +++ pom.xml (working copy)
[13:11:04 EDT(-0400)] <esm> @@ -78,4 +78,14 @@
[13:11:06 EDT(-0400)] <esm> </plugin>
[13:11:08 EDT(-0400)] <esm> </plugins>
[13:11:10 EDT(-0400)] <esm> </reporting>
[13:11:12 EDT(-0400)] <esm> + <build>
[13:11:14 EDT(-0400)] <esm> + <plugins>
[13:11:16 EDT(-0400)] <esm> + <plugin>
[13:11:18 EDT(-0400)] <esm> + <artifactId>maven-war-plugin</artifactId>
[13:11:20 EDT(-0400)] <esm> + <configuration>
[13:11:22 EDT(-0400)]

[13:11:24 EDT(-0400)] <esm> + </configuration>
[13:11:26 EDT(-0400)] <esm> + </plugin>
[13:11:28 EDT(-0400)] <esm> + </plugins>
[13:11:30 EDT(-0400)] <esm> + </build>
[13:11:32 EDT(-0400)] <esm> </project>
[13:11:34 EDT(-0400)] <esm> speed
[13:11:36 EDT(-0400)] <esm> one step (explode) versus two steps
[13:11:57 EDT(-0400)] <esm> if we test uP3 with jetty we can get almost real time
[13:13:01 EDT(-0400)] <esm> i don't have much experience with jetty, but from what I've seen/used it is pretty nice.
[13:13:07 EDT(-0400)] <EricDalquist> will that jetty plugin work with a multiproject build?
[13:13:16 EDT(-0400)] <EricDalquist> I'd be very interested to see how well that works
[13:14:09 EDT(-0400)] <esm> well i'll try to give it a go
[13:14:11 EDT(-0400)] <esm> it should work
[13:14:26 EDT(-0400)] <EricDalquist> that would be great
[13:14:32 EDT(-0400)] <EricDalquist> I have to write up a help desk case here
[13:16:23 EDT(-0400)] <esm> ok have fun with that i'll let you know how this goes
[13:16:35 EDT(-0400)] <EricDalquist> thanks
[13:22:12 EDT(-0400)] <esm> ok first problem is to let Jetty know what to place into a shared classloader
[13:22:29 EDT(-0400)] <EricDalquist>
[13:22:31 EDT(-0400)] <EricDalquist> yay portlets
[13:27:47 EDT(-0400)] * deuce (n=deuce@uni1.unicon.net) has joined ##uportal
[13:36:02 EDT(-0400)] <esm> hm actually i think the probelm is that the container is a provided dep
[13:36:15 EDT(-0400)] <EricDalquist> ah yeah
[13:36:27 EDT(-0400)] <EricDalquist> the EAR pom provides it
[14:03:00 EDT(-0400)] <EricDalquist> how goes jetty?
[14:07:03 EDT(-0400)] <esm> slow - i just had lunch
[14:07:08 EDT(-0400)] <EricDalquist>
[14:07:25 EDT(-0400)] <esm> it looks like there are some options for modifying the jetty classpath
[14:07:36 EDT(-0400)] <esm> i don't know how neat it will be though
[14:07:49 EDT(-0400)] <esm> i'm taking a stab in the dark right now to see if it works
[14:11:10 EDT(-0400)] <EricDalquist> brb
[14:13:30 EDT(-0400)] <EricDalquist> back
[14:21:28 EDT(-0400)] <esm> i got it up and running, no portlets though. and I had to really munge the uP3 pom.xml
[14:21:36 EDT(-0400)] <esm> i'm going to try it in the ear project
[14:21:53 EDT(-0400)] <EricDalquist> k
[15:41:41 EDT(-0400)] * andrew_petro_ubu (n=apetro@uni1.unicon.net) has joined ##uportal
[15:58:28 EDT(-0400)] * deuce (n=deuce@uni1.unicon.net) has joined ##uportal
[15:58:45 EDT(-0400)] <EricDalquist> yay meetings
[15:58:48 EDT(-0400)] <EricDalquist> hows goes things?
[16:09:13 EDT(-0400)] <EricDalquist> anyone out there?
[16:18:07 EDT(-0400)] * deuce_ (n=deuce@uni1.unicon.net) has joined ##uportal
[16:36:25 EDT(-0400)] <andrew_petro_ubu> I'm out here
[16:36:36 EDT(-0400)] <EricDalquist> yay ... another brain to pick
[16:36:43 EDT(-0400)] <andrew_petro_ubu> "Meeting-driven Meetings", seems to be a popular development methodology
[16:36:50 EDT(-0400)] <EricDalquist> LOL
[16:36:51 EDT(-0400)] <EricDalquist> what are your thoughts on uP3's IObjectId
[16:37:03 EDT(-0400)] <andrew_petro_ubu> vague awareness of it
[16:37:13 EDT(-0400)] <andrew_petro_ubu> it's an Interface wrapped around a String, right?
[16:37:19 EDT(-0400)] <EricDalquist> so we have this issue of creating instances of them is a pain
[16:37:20 EDT(-0400)] <EricDalquist> yeah
[16:37:23 EDT(-0400)] <andrew_petro_ubu> My gut reaction is to suggest just using Strings
[16:37:26 EDT(-0400)] <EricDalquist> or an int or long or something
[16:37:26 EDT(-0400)] <andrew_petro_ubu> creating instances of which are easy
[16:37:27 EDT(-0400)] <EricDalquist> yeah
[16:37:30 EDT(-0400)] <andrew_petro_ubu> they're well understood
[16:37:45 EDT(-0400)] <EricDalquist> the only big + I see to object ids is the strongly typedness
[16:37:46 EDT(-0400)] <andrew_petro_ubu> or at least understandable
[16:37:54 EDT(-0400)] <andrew_petro_ubu> yeah
[16:38:01 EDT(-0400)] <EricDalquist> but I'm not sure how valuable that is given the complexity of this big interface heirarchy
[16:38:08 EDT(-0400)] <andrew_petro_ubu> not very, likely
[16:38:12 EDT(-0400)] <andrew_petro_ubu> they're not strongly enough typed
[16:38:25 EDT(-0400)] <andrew_petro_ubu> IObjectId is great, but all that leaves me with is, well, this is the ID of some object
[16:38:30 EDT(-0400)] <andrew_petro_ubu> what kind of object? Dunno.
[16:38:33 EDT(-0400)] <EricDalquist> well that is just the base
[16:38:42 EDT(-0400)] <andrew_petro_ubu> ah, so there's a whole hierarchy of these?
[16:38:46 EDT(-0400)] <EricDalquist> there are I*Ids for every object that has an id
[16:38:52 EDT(-0400)] <EricDalquist> IPortletApplicationDeploymentId
[16:38:57 EDT(-0400)] <EricDalquist> IPortletDeploymentId
[16:39:01 EDT(-0400)] <andrew_petro_ubu> My IThneed impl is identified by an IThneedId?
[16:39:02 EDT(-0400)] <EricDalquist> etc
[16:39:02 EDT(-0400)] <EricDalquist> etc
[16:39:11 EDT(-0400)] <EricDalquist> yup
[16:39:21 EDT(-0400)] <andrew_petro_ubu> interesting
[16:39:28 EDT(-0400)] <andrew_petro_ubu> so then the strong typedness really is buying you something
[16:39:42 EDT(-0400)] <EricDalquist> other than knowning what that ID you have is refering to?
[16:39:42 EDT(-0400)] <andrew_petro_ubu> I can't accidentally use an IThneedId as an identifier for a portlet deployment
[16:39:52 EDT(-0400)] <EricDalquist> yeah
[16:40:02 EDT(-0400)] <EricDalquist> and since we only want people to refernce IDs
[16:40:09 EDT(-0400)] <andrew_petro_ubu> not just knowing. The compiler preventing me from using it for something untoward
[16:40:17 EDT(-0400)] <EricDalquist> yeah
[16:40:21 EDT(-0400)] <andrew_petro_ubu> ok
[16:40:26 EDT(-0400)] <andrew_petro_ubu> let's look at the other end of the problem
[16:40:30 EDT(-0400)] <andrew_petro_ubu> what makes them a pain to create?
[16:40:34 EDT(-0400)] <EricDalquist> well
[16:40:40 EDT(-0400)] <EricDalquist> what impl do you use to create them?
[16:40:46 EDT(-0400)] <EricDalquist> do we bother with a factory?
[16:40:50 EDT(-0400)] <EricDalquist> or do we treat it like a Map
[16:40:57 EDT(-0400)] <EricDalquist> and say ... well just use whatever impl you want
[16:41:04 EDT(-0400)] <andrew_petro_ubu> well
[16:41:09 EDT(-0400)] <andrew_petro_ubu> maybe they should all be concrete
[16:41:15 EDT(-0400)] <EricDalquist> but only 'use' the interface
[16:41:16 EDT(-0400)] <andrew_petro_ubu> and really be just the world's simplest wrappers around Strings
[16:41:24 EDT(-0400)] <EricDalquist> true
[16:41:24 EDT(-0400)] <andrew_petro_ubu> what is the interface buying us?
[16:41:33 EDT(-0400)] <andrew_petro_ubu> interfaces are great, but are these truly multiply realizable?
[16:41:37 EDT(-0400)] <andrew_petro_ubu> or are they just dumb IDs?
[16:42:03 EDT(-0400)] <andrew_petro_ubu> the interface might be doing some damage here
[16:42:05 EDT(-0400)] <EricDalquist> really just dumb ids
[16:42:16 EDT(-0400)] <EricDalquist> strongly typed strings/longs really
[16:42:26 EDT(-0400)] <andrew_petro_ubu> since it would be tragic if my ThneedImpl's IDs didn't work with your ThingDependingOnIThneeds
[16:42:46 EDT(-0400)] <EricDalquist> yeah
[16:43:03 EDT(-0400)] <EricDalquist> hrm ... good thoughts
[16:43:11 EDT(-0400)] <andrew_petro_ubu> What are the intended semantics around these IDs?
[16:43:27 EDT(-0400)] <andrew_petro_ubu> Do I only get them through a carefully controlled path such that I can only get valid ones?
[16:43:29 EDT(-0400)] <andrew_petro_ubu> what makes them valid?
[16:43:36 EDT(-0400)] <andrew_petro_ubu> Or am I allowed to res them up out of thin air
[16:43:41 EDT(-0400)] <EricDalquist> right now there are factories
[16:43:53 EDT(-0400)] <EricDalquist> like a PortletIdFactory which has create*Id methods
[16:44:02 EDT(-0400)] <EricDalquist> that take the appropriate int/long/string
[16:44:16 EDT(-0400)] <EricDalquist> that could easily be encapsulated in the constructor
[16:44:31 EDT(-0400)] <EricDalquist> really you can create them however you want
[16:44:37 EDT(-0400)] <andrew_petro_ubu> Thneed thneed = thneedRegistry.gimmeAThneed( new ThneedId(id_gotten_from_who_knows_where) );
[16:44:46 EDT(-0400)] <EricDalquist> yup
[16:44:49 EDT(-0400)] <andrew_petro_ubu> ok
[16:44:58 EDT(-0400)] <andrew_petro_ubu> I'd look at making them concrete
[16:45:04 EDT(-0400)] <EricDalquist> really only the DAOs/registries should only ever be creating ids
[16:45:05 EDT(-0400)] <andrew_petro_ubu> ditching the I*Id interfaces as not helping
[16:45:18 EDT(-0400)] <andrew_petro_ubu> what does creating an ID mean?
[16:45:29 EDT(-0400)] <andrew_petro_ubu> the semantics are important here
[16:45:34 EDT(-0400)] <EricDalquist> new ThneedId(foo)
[16:45:35 EDT(-0400)] <andrew_petro_ubu> there are two broad approaches
[16:45:39 EDT(-0400)] <EricDalquist> would be creating an Id
[16:45:41 EDT(-0400)] <andrew_petro_ubu> one is that I can just create my ID
[16:45:45 EDT(-0400)] <andrew_petro_ubu> instantiate
[16:45:49 EDT(-0400)] <andrew_petro_ubu> I can just instantiate my ID
[16:45:52 EDT(-0400)] <andrew_petro_ubu> and in fact I gotta do this
[16:46:00 EDT(-0400)] <andrew_petro_ubu> since that's how I have an ID to then use to query a registry
[16:46:03 EDT(-0400)] <andrew_petro_ubu> that's one broad approach
[16:46:04 EDT(-0400)] <EricDalquist> (btw I have to jet in like 1 minute) I'll be back on in 15
[16:46:08 EDT(-0400)] <EricDalquist> and I'll read the logs
[16:46:18 EDT(-0400)] <andrew_petro_ubu> it has some fun downsides, like I can create myself a bogus ID
[16:46:26 EDT(-0400)] <andrew_petro_ubu> and so bogus IDs can be running around in the system
[16:46:41 EDT(-0400)] <andrew_petro_ubu> but it has some nice upsides of simplicity
[16:47:02 EDT(-0400)] <andrew_petro_ubu> the other direction to go is to insist that folks get their ID instances from manager objects
[16:47:15 EDT(-0400)] <andrew_petro_ubu> and so in theory I can never have a bogus ID instance running around
[16:47:47 EDT(-0400)] <andrew_petro_ubu> it's hard to make that guarantee no matter how careful you are, so it's probably better to go with the first approach, embrace messiness, and just resolve to check and handle appropriately the presentation of bad IDs to any given method
[16:48:02 EDT(-0400)] <andrew_petro_ubu> since really you've gotta do those checks anyway
[16:50:35 EDT(-0400)] <andrew_petro_ubu> I've got a meeting or three myself. Good luck with your IDs. Simpler is better. I often come back to the example of Kent Beck's TDD book, where he says he starts with Strings to represent any given concept and moves beyond String when there's some good reason. I'd get rid of the extraneous interfaces and reserve them for plausibly multiply realizable or aspectable concepts – IDs don't seem to make the grade
[17:14:32 EDT(-0400)] * EricDalquist (n=EricDalq@76.201.151.65) has joined ##uportal
[17:18:00 EDT(-0400)] <EricDalquist> oi
[17:36:38 EDT(-0400)] <EricDalquist> thanks for the input andrew, the more views I get on this the clearer it is getting
[17:54:56 EDT(-0400)] <esm> oh man what a long day
[17:55:18 EDT(-0400)] <EricDalquist> yah
[17:55:30 EDT(-0400)] <esm> so i didnt have a whol elot of luck configuring jetty with multiple webapps.
[17:55:37 EDT(-0400)] <esm> but I'm going to give it another college try
[17:55:49 EDT(-0400)] <EricDalquist> ok
[17:55:56 EDT(-0400)] <EricDalquist> don't get too caught up in it
[17:55:59 EDT(-0400)] <esm> yeah
[17:56:06 EDT(-0400)] <EricDalquist> just removing the package-javadoc call cut out a lot of time
[17:56:12 EDT(-0400)] <esm> that is my achilles heel
[17:56:25 EDT(-0400)] <esm> well, i probably have multiple. but thats one of them
[17:56:33 EDT(-0400)] <EricDalquist> mine too
[19:36:53 EDT(-0400)] * EricDalquist (n=EricDalq@76.201.151.65) has joined ##uportal
[20:51:40 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-204-94-59.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[21:34:30 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-204-94-59.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[22:28:13 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-204-94-59.dsl.mdsnwi.sbcglobal.net) has joined ##uportal