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
[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/ .json? ' + [username:admin, showAttribute: ] 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>
[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
[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
[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
[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
[13:00:08 CDT(-0500)] <EricDalquist> yeah I wish that was faster too
[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!
[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
[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
[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 )
[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
[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
[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 (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
[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="# "/>
[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="# "
[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
[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()"
[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