Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

...

[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)]

Wiki Markup
 &lt;EricDalquist&gt;   &lt;constructor-arg value=&#034;#{servletContext}&#034;/&gt;

[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
 &lt;drewwills&gt; how would you know which context you want to invoke at &#034;bean time?&#034;  and how would you get a reference to a different context w/ value=&#034;#{servletContext}&#034;

[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