...
[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)] Wiki Markup <EricDalquist> <constructor-arg value="#{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)] Wiki Markup <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="#{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 
[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