uPortal IRC Logs-2012-05-18

[11:15:41 CDT(-0500)] <drewwills> testing that REST API invoking tool now

[11:38:39 CDT(-0500)] <EricDalquist> any luck drewwills?

[11:44:56 CDT(-0500)] <drewwills> yes, chasing down the loose ends

[11:44:59 CDT(-0500)] <drewwills> shaping up

[11:45:16 CDT(-0500)] <drewwills> e.g. learning how to get a req dispatcher for another context (tongue)

[11:45:19 CDT(-0500)] <drewwills> no biggie

[11:46:48 CDT(-0500)] <drewwills> fair amount of String manipulation that feels wrong to hand-roll... probably a lib that could get me 90% there... I'll have to chase that down at some point

[11:47:49 CDT(-0500)] <EricDalquist> doing what for the string manip?

[11:52:50 CDT(-0500)]

<drewwills> contrived example: '/uPortal/api/people/

Unknown macro: {username}

.json?

Unknown macro: {includeAttribute}

' + [username:admin, showAttribute:

Unknown macro: {mail, displayName}

] needs to become... someTuple.contextName=/uPortal+someTuple.uri=/api/people/admin.json?showAttribute=mail&showAttribute=displayName

[11:53:04 CDT(-0500)] <drewwills> and also have the inputs URLEncoded

[11:55:32 CDT(-0500)] <EricDalquist> ah

[11:55:50 CDT(-0500)] <EricDalquist> go steal uPortal/uportal-war/src/main/java/org/jasig/portal/url/UrlStringBuilder.java

[12:02:09 CDT(-0500)] <drewwills> uP is already x-context correct? I don't need to alter any tomcat xml?

[12:02:19 CDT(-0500)] <EricDalquist> right

[12:02:29 CDT(-0500)] <EricDalquist> the portlet will need to have a meta-inf/context.xml though

[12:02:34 CDT(-0500)] <EricDalquist> to enable cross context from the portlet

[12:02:43 CDT(-0500)] <drewwills> and I don't need to tweak any tomcat xml on the portlet side to find the uP context, correct?

[12:02:49 CDT(-0500)] <drewwills> doh

[12:02:57 CDT(-0500)] <drewwills> i typed too slow

[12:03:05 CDT(-0500)] <EricDalquist> (smile)

[12:03:06 CDT(-0500)] <EricDalquist> <Context crossContext="true">

[12:03:06 CDT(-0500)] <EricDalquist> </Con

[12:03:24 CDT(-0500)] <EricDalquist> add that (well valid) to src/main/webapp/META-INF/context.xml

[12:05:00 CDT(-0500)] <drewwills> ++DLM Fragment Manager interface

[12:33:33 CDT(-0500)] <JoeMoore> Is anyone available to look at a problem with importing a fragment definition which references a PAGS group in 4.0.5?

[12:36:55 CDT(-0500)] <EricDalquist> I can peak

[12:38:33 CDT(-0500)] <drewwills> me too

[12:40:27 CDT(-0500)] <JoeMoore> excellent. I had just stepped out. I'll pastebin what's needed.

[12:41:35 CDT(-0500)] <JoeMoore> Background. A few days ago, Eric helped me get a pristine 4.0.5.

[12:42:03 CDT(-0500)] <JoeMoore> I have applied just enough changes to hook into our LDAP and provide an external URL

[12:42:23 CDT(-0500)] <JoeMoore> I then nuked the database and loaded the PAGS definition which I will pastebin

[12:42:40 CDT(-0500)] <JoeMoore> I'm still running hsql

[12:47:56 CDT(-0500)] <JoeMoore> PAGSGroupStoreConfig.xml http://pastebin.com/ERvhXhX6

[12:48:27 CDT(-0500)] <drewwills> frag def xml?

[12:48:38 CDT(-0500)] <JoeMoore> Its coming (smile)

[12:48:48 CDT(-0500)] <drewwills> lol cool

[12:49:46 CDT(-0500)] <JoeMoore> I isolated one frag def, and have been trying to work with it

[12:50:47 CDT(-0500)] <JoeMoore> http://pastebin.com/E6AfEu1b I wanted to make sure I had a later version

[12:50:53 CDT(-0500)] <JoeMoore> I've tried many (smile)

[12:51:35 CDT(-0500)] <JoeMoore> Next will come the log from the import

[12:51:59 CDT(-0500)] <drewwills> nice use of RegexTester btw

[12:52:46 CDT(-0500)] <JoeMoore> As long as it works--it did with 3.x

[12:53:25 CDT(-0500)] <JoeMoore> Good stuff: http://pastebin.com/fnFhLhjJ

[12:54:22 CDT(-0500)] <drewwills> EricDalquist just got a valid, correct response from the x-context rest invoker for first time (smile)

[12:54:27 CDT(-0500)] <EricDalquist> yay!

[12:55:30 CDT(-0500)] <EricDalquist> huh

[12:55:35 CDT(-0500)] <EricDalquist> that all looks right JoeMoore

[12:55:47 CDT(-0500)] <JoeMoore> I thought so, also!

[12:55:54 CDT(-0500)] <JoeMoore> That's why I'm here

[12:56:05 CDT(-0500)] <EricDalquist> the code is doing

[12:56:05 CDT(-0500)] <EricDalquist> groups = GroupService.searchForGroups(groupName,

[12:56:05 CDT(-0500)] <EricDalquist> IGroupConstants.IS, org.jasig.portal.security.IPerson.class);

[12:56:44 CDT(-0500)] <EricDalquist> my first thought would be to try starting the portal with a simpler dlm config

[12:56:47 CDT(-0500)] <JoeMoore> Will pastebin screen shot? If not, what to use?

[12:56:48 CDT(-0500)] <EricDalquist> and browse the groups tree

[12:56:50 CDT(-0500)] <EricDalquist> in group manager

[12:57:06 CDT(-0500)] <drewwills> is there possibly any earlier error? like maybe in the shell? something that went wrong before it even tried to import a file of that type?

[12:57:13 CDT(-0500)] <JoeMoore> Thats what I was going to screenshot because I've done that

[12:57:38 CDT(-0500)] <EricDalquist> and you see the group in the tree?

[12:57:41 CDT(-0500)] <JoeMoore> I imported this frag by itself

[12:57:51 CDT(-0500)] <JoeMoore> Yup to @Eric

[12:58:20 CDT(-0500)] <JoeMoore> to drew, I'll post the data-import.txt

[12:58:37 CDT(-0500)] <drewwills> ok joe... but any chance there was an error as the import/export tech "came up?" – before it looked for the file you specified?

[12:58:43 CDT(-0500)] <drewwills> cool

[12:58:57 CDT(-0500)] <JoeMoore> Im not going to bother pastebin--its 2 lines, here it is

[12:59:04 CDT(-0500)] <JoeMoore> <fragment-definition script="classpath://org/jasig/portal/io/import-fragment-definition_v3-1.crn">,1

[12:59:11 CDT(-0500)] <JoeMoore> FAIL,file [d:\temp\dbexpimp\junk\RH_SBH_frag.fragment-definition],1236.47ms

[12:59:29 CDT(-0500)] <EricDalquist> can you do "ant data-import -Dfile=.... > import.log" and pastebin that file?

[12:59:30 CDT(-0500)] <JoeMoore> I pointed data-import to a directory with one file, the frag

[12:59:50 CDT(-0500)] <JoeMoore> Yup. It will take a minute or two on the slow machine (smile)

[13:00:08 CDT(-0500)] <EricDalquist> yeah I wish that was faster too (sad)

[13:00:57 CDT(-0500)] <JoeMoore> This server has a total of 2G assigned to it in a virtual environment, I can't blame the process! It just doesn't have enough resources.

[13:01:07 CDT(-0500)] <EricDalquist> no, its slow

[13:01:14 CDT(-0500)] <EricDalquist> it bootstraps more than it needs to

[13:01:21 CDT(-0500)] <EricDalquist> but its not simple to unravel

[13:06:35 CDT(-0500)] <JoeMoore> Its running. Depending on what this does, I could also run it from the interface. I don't remember if I tried that or not.

[13:07:48 CDT(-0500)] <JoeMoore> http://pastebin.com/WgYcYkdk

[13:08:14 CDT(-0500)] <EricDalquist> oi

[13:08:21 CDT(-0500)] <EricDalquist> that isn't helpful at all! (sad)

[13:09:36 CDT(-0500)] <JoeMoore> How about a dbinfo? I didn't know how much of what it was telling me was truly bad or not. Remember, I can nuke this db at will.

[13:10:14 CDT(-0500)] <EricDalquist> I don't think it is a db issue

[13:10:19 CDT(-0500)] <JoeMoore> OK

[13:10:25 CDT(-0500)] <EricDalquist> I'm not really sure what I think it is

[13:10:30 CDT(-0500)] <EricDalquist> but somehow it isn't finding that grouo

[13:10:48 CDT(-0500)] <EricDalquist> this may be insane but ...

[13:10:59 CDT(-0500)] <JoeMoore> Good. At least I didn't miss something obvious. I tried the short name of the group as well as the human readable name.

[13:11:10 CDT(-0500)] <JoeMoore> Hows the easiest way to post a screen shot?

[13:11:21 CDT(-0500)] <EricDalquist> I'm not really sure :/

[13:11:25 CDT(-0500)] <EricDalquist> can you go into "uportal-war/src/main/resources/command-line.log4j.properties"

[13:11:43 CDT(-0500)] <JoeMoore> I want to prove to both of us that the group name is spelled right and showing up in the hierarchy (smile)

[13:11:54 CDT(-0500)] <EricDalquist> change "log4j.category.org.jasig.portal=INFO, R" to "log4j.category.org.jasig.portal=TRACE, R"

[13:12:07 CDT(-0500)] <EricDalquist> just email it directly to me

[13:12:15 CDT(-0500)] <EricDalquist> once you make that change re-run the import

[13:12:19 CDT(-0500)] <JoeMoore> Sure.

[13:12:22 CDT(-0500)] <EricDalquist> with the redirect into a file again

[13:12:28 CDT(-0500)] <EricDalquist> lets see if anything useful gets logged

[13:14:45 CDT(-0500)] <JoeMoore> Running

[13:18:46 CDT(-0500)] <JoeMoore> I sent the screen shot to Erics doit... address

[13:19:10 CDT(-0500)] <EricDalquist> looks good

[13:19:41 CDT(-0500)] <JoeMoore> You can see from the breadcrumbs (or the PAGS file if you traced it down) that its 2 levels removed from everyone. Maybe that is related?

[13:20:30 CDT(-0500)] <JoeMoore> import with extra trace still running ...

[13:20:49 CDT(-0500)] <JoeMoore> refilling my coffee... (~20 sec)

[13:45:48 CDT(-0500)] <JoeMoore> Well, given the choice I'd much rather have it use the normal name than the short name (smile)

[13:45:55 CDT(-0500)] <EricDalquist> right

[13:46:35 CDT(-0500)] <JoeMoore> Tomcat is restarting

[13:46:47 CDT(-0500)] <JoeMoore> Do you want me to first try the interface or the command line?

[13:47:05 CDT(-0500)] <EricDalquist> up to you

[13:47:10 CDT(-0500)] <JoeMoore> Of course I changed the group name in the frag definition as well.

[13:47:17 CDT(-0500)] <EricDalquist> note that you can do the cli import without deploying

[13:47:19 CDT(-0500)] <EricDalquist> or restarting tomcat

[13:47:35 CDT(-0500)] <JoeMoore> Interface is quicker but I've never figured out where the log is (I've not looked, either (smile))

[13:47:44 CDT(-0500)] <EricDalquist> you can make a config/change and just run "ant import-data"

[13:47:49 CDT(-0500)] <EricDalquist> it should be in tomcat/logs/uPortal.log

[13:48:07 CDT(-0500)] <JoeMoore> That makes me question myself.

[13:48:22 CDT(-0500)] <EricDalquist> her

[13:48:23 CDT(-0500)] <EricDalquist> er

[13:48:29 CDT(-0500)] <JoeMoore> I'm sure I've done at least one full deploy with this version of PAGS...

[13:48:30 CDT(-0500)] <EricDalquist> "ant data-import"

[13:48:37 CDT(-0500)] <JoeMoore> Ah, I feel better!

[13:50:01 CDT(-0500)] <JoeMoore> Portal is up. I just followed the bread crumbs, and the (PAGS) is gone. First I'll try the interface.

[13:51:13 CDT(-0500)] <JoeMoore> Of course, the interface doesn't give any feedback, I'm sure that's on your todo list (smile)

[13:51:54 CDT(-0500)] <EricDalquist> yeah

[13:52:01 CDT(-0500)] <EricDalquist> there is a set of tickets for improving that portlet

[13:52:37 CDT(-0500)] <JoeMoore> Where can I find the log?

[13:54:25 CDT(-0500)] <JoeMoore> Or conversely, where can I see if the fragment defintition showed up? It doesn't have a layout attached yet.

[13:54:40 CDT(-0500)] <EricDalquist> tomcat/logs/uPortal.log

[13:55:03 CDT(-0500)] <JoeMoore> However, it does show up now in Fragment Administration!

[13:56:29 CDT(-0500)] <JoeMoore> So I see you don't need to define the layout any further. It seems I needed to do that in 3.x

[13:56:34 CDT(-0500)] <JoeMoore> That's great!!!

[13:56:56 CDT(-0500)] <EricDalquist> can you do a cli import

[13:56:58 CDT(-0500)] <EricDalquist> just to verify?

[13:57:04 CDT(-0500)] <JoeMoore> Will do.

[14:00:09 CDT(-0500)] <JoeMoore> It's running again.

[14:03:06 CDT(-0500)] <JoeMoore> Hrmmm. Still failed.

[14:03:16 CDT(-0500)] <JoeMoore> Do you want to see the guts?

[14:03:17 CDT(-0500)] <EricDalquist> same error?

[14:03:31 CDT(-0500)] <JoeMoore> The jury is out.

[14:05:18 CDT(-0500)] <JoeMoore> https://gist.github.com/ede134a8f2f8da39f7ac

[14:07:08 CDT(-0500)] <JoeMoore> Now I'll look at the tomcat log and see if I can find the import errors if there were any

[14:07:28 CDT(-0500)] <EricDalquist> what about the log in D:\Data\Git\git\uPortal4\target\data-import-reports

[14:08:20 CDT(-0500)] <JoeMoore> https://gist.github.com/a32926b03cd5bca94a49

[14:08:33 CDT(-0500)] <EricDalquist> so same issue

[14:08:53 CDT(-0500)] <EricDalquist> I'm at a loss JoeMoore (sad)

[14:08:58 CDT(-0500)] <EricDalquist> short of debugging the code

[14:09:03 CDT(-0500)] <EricDalquist> or adding a bunch of logging

[14:09:06 CDT(-0500)] <EricDalquist> I'm not sure what to do

[14:09:15 CDT(-0500)] <JoeMoore> Your in the drivers seat.

[14:10:05 CDT(-0500)] <JoeMoore> I'll go back and do over but I really don't think it showed up in the fragment administration until we removed the parenthesis. I could be wrong.

[14:10:08 CDT(-0500)] <EricDalquist> heh ... well I can't really do much more from here

[14:11:24 CDT(-0500)] <JoeMoore> Let me know if you think of some magical logging statements. I may pull that group down so it comes right off of PAGS Root and see if that makes any difference. Not an acceptable workaround.

[14:11:59 CDT(-0500)] <EricDalquist> that's an idea ... try changing the dlm config to point to the pags root grou[

[14:12:08 CDT(-0500)] <EricDalquist> note that you do not have to redeploy when you make these changes

[14:12:12 CDT(-0500)] <EricDalquist> just make the change

[14:12:24 CDT(-0500)] <EricDalquist> then run "ant data-import -Dfile=path/to/file"

[14:12:26 CDT(-0500)] <JoeMoore> You lost me...

[14:12:37 CDT(-0500)] <EricDalquist> so go into your DLM fragment config file

[14:12:52 CDT(-0500)] <EricDalquist> instead of having it reference the Brown Hall group

[14:12:58 CDT(-0500)] <JoeMoore> Are you saying the same thing in 14:12 that I said in 14:11?

[14:13:09 CDT(-0500)] <EricDalquist> have it reference the PAGS Root group

[14:13:41 CDT(-0500)] <JoeMoore> Oh, OK. That makes sense.

[14:13:53 CDT(-0500)] <EricDalquist> and don't bother with deploy-war

[14:13:55 CDT(-0500)] <EricDalquist> or tomcat at all

[14:14:13 CDT(-0500)] <EricDalquist> just do: "ant data-import -Dfile=path/to/file"

[14:14:40 CDT(-0500)] <EricDalquist> also you might want to go into command-line.log4j.properties and change the org.jasig.portal category back to INFO

[14:14:44 CDT(-0500)] <EricDalquist> so you don't get so much spam

[14:14:51 CDT(-0500)] <JoeMoore> Should I walk the tree with fragment definitions from root to brown hall and leave the DLM properties alone?

[14:15:04 CDT(-0500)] <EricDalquist> yes

[14:15:15 CDT(-0500)] <EricDalquist> update your fragment definition to reference PAGS Root

[14:15:21 CDT(-0500)] <EricDalquist> if that works go to the next node in the tree

[14:15:22 CDT(-0500)] <EricDalquist> etc

[14:15:28 CDT(-0500)] <JoeMoore> Could the problem be creating a leaf without a branch (so to speak?)

[14:15:36 CDT(-0500)] <EricDalquist> no idea

[14:15:43 CDT(-0500)] <EricDalquist> I don't see anything weird in your pags config

[14:16:31 CDT(-0500)] <JoeMoore> OK, well I'll try walking down the tree and see if that takes care of it. That makes the most sense to me. If that's the case, a few documentation changes should take care of it because I cant see a downside of...

[14:16:35 CDT(-0500)] <drewwills> first pass of REST API Invoker: https://github.com/Jasig/portlet-utils/commit/e1402917529432e63124f58b4e179fbaf5e5f974

[14:16:54 CDT(-0500)] <JoeMoore> having a fragment definition for each PAGS node.

[14:17:07 CDT(-0500)] <JoeMoore> Over and out. Thanks bunches!!!!

[14:17:12 CDT(-0500)] <EricDalquist> yup

[14:17:13 CDT(-0500)] <EricDalquist> good luck

[14:22:17 CDT(-0500)] <EricDalquist> I love github

[14:22:25 CDT(-0500)] <EricDalquist> being able to comment inline in commits is so handy

[14:26:46 CDT(-0500)] <drewwills> yes... very nice

[14:29:22 CDT(-0500)] <EricDalquist> looks good

[14:29:34 CDT(-0500)] <EricDalquist> the only real big functional issue is this one: https://github.com/Jasig/portlet-utils/commit/e1402917529432e63124f58b4e179fbaf5e5f974#L4R170

[14:29:55 CDT(-0500)] <EricDalquist> you could end up with stuff like headers from the portal's rest api response on your app's response

[14:30:11 CDT(-0500)] <EricDalquist> or illegal state exceptions when trying to write out headers to an already committed response

[14:42:16 CDT(-0500)] <drewwills> yes thats a very important adjustment needed

[14:42:54 CDT(-0500)] <drewwills> I'm on PTO today (tongue) (can't you tell?) I'll hit at least that bit monday

[14:43:09 CDT(-0500)] <drewwills> unless someone does it before I get there

[14:44:40 CDT(-0500)] <EricDalquist> no problem

[14:44:44 CDT(-0500)] <EricDalquist> you're the one using (wink)

[14:44:52 CDT(-0500)] <EricDalquist> also you have to use a HttpServletResponseWrapper

[14:45:33 CDT(-0500)] <EricDalquist> the servlet spec explicitly disallows passing a user defined HttpServletRequest impl that doesn't extend from HttpServletResponseWrapper to any methods

[14:45:43 CDT(-0500)] <EricDalquist> so you get to have a giant wrapper class

[14:53:31 CDT(-0500)] <drewwills> that's too bad... if we could use a completely custom ServletResponse it would have the additional benefit of allowing us to remove the response as a parameter on the method call

[14:54:34 CDT(-0500)] <drewwills> i suppose adding ServletContext as a parameter makes the most sense, though it stinks that a ton of invocations will look like: invoke(req.getSession().getServletContext(), req, res, ...);

[14:55:00 CDT(-0500)] <EricDalquist> yes but you don't do req.getSession.getServletContext

[14:55:06 CDT(-0500)] <EricDalquist> in spring you implement ServletContextAware

[14:55:09 CDT(-0500)] <drewwills> i might in a client

[14:55:11 CDT(-0500)] <EricDalquist> and have it injected in your class

[14:55:14 CDT(-0500)] <EricDalquist> right

[14:55:21 CDT(-0500)] <drewwills> if you're a controller

[14:55:24 CDT(-0500)] <EricDalquist> yup

[14:55:37 CDT(-0500)] <EricDalquist> class MyController implements ServletContextAware {

[14:55:38 CDT(-0500)] <EricDalquist> }

[14:55:47 CDT(-0500)] <EricDalquist> adds a setServletContext(ServletContext) method

[14:55:51 CDT(-0500)] <EricDalquist> which spring calls at app init

[14:56:28 CDT(-0500)] <EricDalquist> or what may be even easier is to have the rest API impl take ServletContext as a constructor arg

[14:56:33 CDT(-0500)] <EricDalquist> and wire it up in the spring XML

[14:56:55 CDT(-0500)] <drewwills> i might be implementing an interface like this one: https://github.com/Jasig/email-preview/blob/master/src/main/java/org/jasig/portlet/emailpreview/dao/IEmailAccountService.java

[14:57:08 CDT(-0500)] <drewwills> with a method like: public EmailMessage getMessage(PortletRequest req, int messageNum);

[14:57:22 CDT(-0500)] <drewwills> (except maybe imagine it's a servetrequest)

[14:58:39 CDT(-0500)] <EricDalquist> ok

[15:00:26 CDT(-0500)] <EricDalquist> so how are you handling the creation of SimpleCrossContextRestApiInvoker

[15:00:35 CDT(-0500)] <EricDalquist> is it a spring bean?

[15:03:48 CDT(-0500)] <EricDalquist> if so ... and you're using spring3 you could do something like this:

[15:04:14 CDT(-0500)] <EricDalquist> <bean class="SimpleCrossContextRestApiInvoker">

[15:04:14 CDT(-0500)]

<EricDalquist> <constructor-arg value="#

Unknown macro: {servletContext}

"/>

[15:04:14 CDT(-0500)] <EricDalquist> </bean>

[15:07:27 CDT(-0500)] <drewwills> yes I was figuring it would be a spring bean, though partly because I was guessing there would eventually be dependencies or config I would want to bake into it from the xml... though I didn't have any yet

[15:07:42 CDT(-0500)] <drewwills> so the <bean> you describe could be part of that

[15:07:49 CDT(-0500)] <EricDalquist> yeah in that case I'd just make the ServletContext a constructor argument

[15:08:00 CDT(-0500)] <EricDalquist> since it should be known at that point

[15:08:06 CDT(-0500)] <EricDalquist> and it keeps the runtime API simpler

[15:08:17 CDT(-0500)] <drewwills> welll... 1 sec

[15:09:11 CDT(-0500)]

<drewwills> how would you know which context you want to invoke at "bean time?" and how would you get a reference to a different context w/ value="#

Unknown macro: {servletContext}

"

[15:09:26 CDT(-0500)] <EricDalquist> no that is the caller's servletcontext

[15:09:31 CDT(-0500)] <drewwills> or do you mean 2 props/args

[15:09:57 CDT(-0500)] <EricDalquist> so looking at line 152: https://github.com/Jasig/portlet-utils/commit/e1402917529432e63124f58b4e179fbaf5e5f974#L4R152

[15:10:01 CDT(-0500)] <drewwills> sure... then how do i know which context to call? string arg?

[15:10:43 CDT(-0500)] <EricDalquist> um ... how are you getting the servlet context to call right now?

[15:10:46 CDT(-0500)] <EricDalquist> I missed that bit (smile)

[15:10:49 CDT(-0500)] <EricDalquist> looking ...

[15:10:54 CDT(-0500)] <drewwills> parsing the string

[15:11:01 CDT(-0500)] <drewwills> /uPortal/api/...

[15:11:16 CDT(-0500)] <drewwills> lol, yes i can continue to do that

[15:11:21 CDT(-0500)] <EricDalquist> right

[15:11:32 CDT(-0500)] <EricDalquist> so this isn't a solution to that part of the code

[15:11:34 CDT(-0500)] <drewwills> i thought this whole thread of discussion was about not having to parse that

[15:11:36 CDT(-0500)] <EricDalquist> no

[15:11:52 CDT(-0500)] <EricDalquist> it is about not doing "req.getSession().getServletContext()" (smile)

[15:12:04 CDT(-0500)] <EricDalquist> since the webapp has that value at init time

[15:12:16 CDT(-0500)] <drewwills> ok – well we can do it for that

[15:12:20 CDT(-0500)] <EricDalquist> as for the parsing out of "/uPortal"

[15:12:33 CDT(-0500)] <EricDalquist> that would probably be best as a property placeholder for now

[15:12:43 CDT(-0500)] <EricDalquist> if we really publish this as an API for portlets

[15:12:53 CDT(-0500)] <EricDalquist> we'll look at providing the portal's context path as a portlet request property

[15:13:19 CDT(-0500)] <EricDalquist> so you could do:

[15:13:19 CDT(-0500)] <EricDalquist> String portalContextPath = portletRequest.getProperty("org.jasig.portal.context_path")

[15:13:32 CDT(-0500)] <drewwills> i think that would be helpful

[15:13:40 CDT(-0500)] <EricDalquist> yeah that is very easy to do

[15:14:00 CDT(-0500)] <drewwills> but doesn't that just help me construct a string like "/uPortal/api/...?"

[15:14:47 CDT(-0500)] <drewwills> I wasn't thinking to make the code in the ApiInvokerImpl uP context specific... doesn't seem like it needs to be

[15:15:12 CDT(-0500)] <EricDalquist> so your client controller should be doing:

[15:15:12 CDT(-0500)] <EricDalquist> invoke(req, res, "/api/person", params)

[15:15:54 CDT(-0500)] <EricDalquist> then your SimpleCrossContextRestApiInvoker (lets assume portlet req/res) does:

[15:16:05 CDT(-0500)] <drewwills> that would be uP specific i think, unless i did <property name="contextName">/uPortal</property>

[15:16:54 CDT(-0500)] <drewwills> (on the SimpleCrossContextRestApiInvoker wiring)

[15:17:01 CDT(-0500)] <EricDalquist> right

[15:17:04 CDT(-0500)] <EricDalquist> it depends on your goals

[15:17:10 CDT(-0500)] <EricDalquist> easy of config or portability

[15:17:17 CDT(-0500)] <EricDalquist> and if you want it callable just from portlets

[15:17:19 CDT(-0500)] <EricDalquist> or from servlets too

[15:17:34 CDT(-0500)] <EricDalquist> if you're talking portlets and easy of config

[15:17:47 CDT(-0500)] <drewwills> yeah let's see how it goes... with time comes greater clarity

[15:18:33 CDT(-0500)] <EricDalquist> your invoker impl does:

[15:18:33 CDT(-0500)] <EricDalquist> String portalContext = req.getProperty("org.jasig.portal.context_path");

[15:18:33 CDT(-0500)] <EricDalquist> ServletContext portalContext = injectedAppContext.getConext(portalContext);

[15:18:33 CDT(-0500)] <EricDalquist> RequestDispatcher rd = portalContext.getRequestDispatcher(uri);

[15:19:01 CDT(-0500)] <EricDalquist> where injectedAppContext is the ServletContext of the caller app injected via the constructor

[15:21:30 CDT(-0500)] <drewwills> roger