1 2 Previous Next 16 Replies Latest reply on Feb 8, 2012 12:19 PM by jfuerth

    Errai and portlet deployment?

    david.grigglestone

      Anyone successfully deployed an Errai based app via a portlet?

       

      In my case I'm using Liferay6.1.0/Tomcat7.0.23.

       

      I tried just taking the stock demo and converting to a portlet, but just see messages from the Tomcat console like:

       

      02:36:59,282 INFO  [PortalImpl:4873] Current URL /out.3576-9263.erraiBus generates exception: null

      02:36:59,625 INFO  [PortalImpl:4873] Current URL /in.3576-9263.erraiBus?z=0 generates exception: null

      02:37:19,654 INFO  [PortalImpl:4873] Current URL /out.3576-9263.erraiBus generates exception: null

      02:37:39,665 INFO  [PortalImpl:4873] Current URL /out.3576-9263.erraiBus generates exception: null

       

      Guess I'll try the 2.0-SNAPSHOT tomorrow, but it would be good to know if someone has actually got it working and any tweaks that were needed.

        • 1. Re: Errai and portlet deployment?
          david.grigglestone

          I built Errai 2.0 and tried same, but see similar (with I guess some additional tracing in):

           

          03:32:17,298 INFO  [PortalImpl:4873] Current URL /out.50694-4048.erraiBus generates exception: null

          03:32:17,537 INFO  [PortalImpl:4873] Current URL /in.50694-4048.erraiBus?z=0 generates exception: null

          INFO [ServerMessageBusImpl] [experimental] buffer status [freebytes: 134217728 (100.0%) tail rng: 0; actv tails: 0]

          INFO [ServerMessageBusImpl] [experimental] buffer status [freebytes: 134217728 (100.0%) tail rng: 0; actv tails: 0]

          INFO [ServerMessageBusImpl] [experimental] buffer status [freebytes: 134217728 (100.0%) tail rng: 0; actv tails: 0]

          INFO [ServerMessageBusImpl] [experimental] buffer status [freebytes: 134217728 (100.0%) tail rng: 0; actv tails: 0]

          INFO [ServerMessageBusImpl] [experimental] buffer status [freebytes: 134217728 (100.0%) tail rng: 0; actv tails: 0]

          INFO [ServerMessageBusImpl] [experimental] buffer status [freebytes: 134217728 (100.0%) tail rng: 0; actv tails: 0]

           

          So no success with deployment of the standard stockDemo example as a portlet yet. Might I suggest it would be reasonable to have one of the samples with a deployment option of a portlet so at least there is a baseline of something that is known to work?

           

          Again I'd like to ask the wider Errai user community if anyone has deployed an Errai application as a portlet?

          • 2. Re: Errai and portlet deployment?
            jfuerth

            Hi David,

             

            As far as we know, you are breaking new ground here. We haven't seen any discussion around deploying Errai as a portlet.

             

            The fact that you're seeing those buffer status logging messages means that Errai Bus was at least able to bootstrap and create the threads that it needed. Without the accompanying stack trace on the " [PortalImpl:4873] Current URL /out.50694-4048.erraiBus generates exception: null" messages, though, it's hard to say exactly what kind of failure we're up against.

             

            Jonathan

            • 3. Re: Errai and portlet deployment?
              david.grigglestone

              okay .. we have a starting point   

               

              So my first question would be is it the intent of Errai to be able support use in a portal environment? I can't see why it wouldn't be a goal given the wide use of portals.

               

              Additionally given the nice message-based programming model that includes internal client use, I could see using Errai over other IPC mechanisms.

               

              I'd certainly be willing to help with diagnosis in the above case if you can guide me into how to get a more complete stack trace.

               

              - David

              • 4. Re: Errai and portlet deployment?
                jfuerth

                Hi David,

                 

                Making Errai work in a portlet environment sounds like a good goal to me. To be frank, I don't have any experience developing portlets, so I'm not sure exactly how a portlet container differs from a plain servlet container.

                 

                But I'll take your word for it that it's a good goal to have, and I'd be quite happy to work with you and get Errai functioning in a portlet environment.

                 

                Since we don't even know what kind of exception we're up against, I'd recommend you start by searching your portlet implementation for the message " generates exception: ". Hopefully there is some logging code in there already that's just disabled by the default logging configuration. If not, see if you can either set a breakpoint there in a debugger, or better yet, modify the code to print more information about the exception... and send a patch upstream.

                 

                -Jonathan

                • 5. Re: Errai and portlet deployment?
                  david.grigglestone

                  I've started by posting something on Liferay's forum. My search of their sources (not sure I've covered everything yet) has not found "generates exception" yet.

                   

                  I have yet to try out on JBoss portal yet .. that would be a good way to narrow the scope.

                   

                  I'll post progress when I can get to it next week.

                   

                  thanks, David

                  • 6. Re: Errai and portlet deployment?
                    david.grigglestone

                    fyi .. have got as far as finding that Liferay appears to be trying to intercept and map URLs .. I don't understand why it would touch Errai URLs or how to configure Liferay for different behavior (if indeed that is possible).

                     

                    Here is the thread on the Liferay forum: http://www.liferay.com/community/forums/-/message_boards/message/12230798

                    • 7. Re: Errai and portlet deployment?
                      jfuerth

                      Hi David,

                       

                      I downloaded Liferay and had a look at the web.xml in ROOT.war. It looks like the "InvokerFilter" is mapped to every request (mapping is "/*") four times. And from the stack trace you posted in the Liferay forum, it also appears that the exception happens within the context of (one execution of) the invoker filter.

                       

                      Probably the most straightforward workaround would be to give Errai the first chance at these requests. There is no need for any Liferay involvement in the *.erraiBus requests.

                       

                      I'd suggest a modified version of Errai's DefaultBlockingServlet that can act as a Servlet Filter. Map it to /* and put it in web.xml before any of the invoker filter mappings. Have it handle the request directly if the request path ends with .erraiBus; otherwise, just invoke the next item in the filter chain.

                       

                      If you want a hand with this task, let me know. It's something we would probably want to include in the main Errai distribution.

                       

                      -Jonathan

                      • 8. Re: Errai and portlet deployment?
                        jfuerth

                        Okay, I've modified DefaultBlockingServlet so it can be used either as a Servlet or as a Filter. This change should become available in the next errai-bus 2.0-SNAPSHOT release.

                         

                        To configure DefaultBlockingServlet to handle *.erraiBus requests ahead of other filters in web.xml will solve the problem, replace the current Errai servlet declaration and servlet mapping with the following:

                         

                        <filter>

                           <filter-name>ErraiServlet</filter-name>

                           <filter-class>org.jboss.errai.bus.server.servlet.DefaultBlockingServlet</filter-class>

                        </filter>

                         

                        <filter-mapping>

                           <filter-name>ErraiServlet</filter-name>

                           <url-pattern>*.erraiBus</url-pattern>

                        </filter-mapping>

                         

                        Make sure this comes before all other <filter-mapping> elements in the web.xml.

                         

                        This should resolve the problem you've described. I just hope there's not another issue lurking in the darkness behind this one.

                         

                        -Jonathan

                        • 9. Re: Errai and portlet deployment?
                          david.grigglestone

                          fyi .. did some very initial testing and was still seeing similar issues .. hopefully I can spend more time at the end of this week to give you specif details

                           

                          at this stage I can say I still see messages with Errai URLs that have a suffice of ?z=<n> .. also I have to research the <url-pattern> .. I don't think its a regex, but rather a trailing wildcard (maybe you know otherwise?)

                           

                          - David

                          • 10. Re: Errai and portlet deployment?
                            jfuerth

                            Hi David,

                             

                            The url-pattern is not a regex. In fact, the pattern matching is very limited. It is always matched against the request's context relative path, excluding the query and fragment parts, (more on that later), and it can only take one of three forms:

                             

                            1. An exact path, eg. "/path/to/my/stuff" matches:
                              1. http://yourdomain.com/contextname/path/to/my/stuff
                              2. http://yourdomain.com/contextname/path/to/my/stuff#fragment
                              3. http://yourdomain.com/contextname/path/to/my/stuff?q=moo
                              4. http://yourdomain.com/contextname/path/to/my/stuff?q=moo#fragment
                            2. A path prefix, eg. "/path/*" matches all of the following (even with query or fragment parts, as illustrated above):
                              1. http://yourdomain.com/contextname/path/1/2/3
                              2. http://yourdomain.com/contextname/path/1
                              3. http://yourdomain.com/contextname/path/
                            3. A filename suffix ("extension") mapping, eg. "*.erraiBus" matches all of the following (even with query or fragment parts, as illustrated above):
                              1. http://yourdomain.com/contextname/path/1/2/3.erraiBus
                              2. http://yourdomain.com/contextname/path/1.erraiBus
                              3. http://yourdomain.com/contextname/foo.erraiBus

                             

                            The context name is defined in a vendor-dependent way. In practice it's usually taken from the name of your .war file, and every Java EE web server has its own configuration file syntax for overriding that default. It's possible to have a context with no name, which the servlet spec calls "the root context." By convention, the special name ROOT.war is normally deployed with an empty context name. This isn't official spec, but every server I've worked with follows that convention.

                             

                            If you've pasted the filter definition and "*.erraiBus" mapping into your Liferay web.xml before all the other filter mappings, you should no longer be getting the same error. As long as the Errai filter comes first, it will prevent the Liferay filter from seeing Errai Bus requests.

                             

                            I look forward to seeing more information about the (hopefully new!) error when you have the opportunity to take another look.

                             

                            -Jonathan

                            • 11. Re: Errai and portlet deployment?
                              jfuerth

                              By the way, the servlet spec is actually quite easy to read. I find it clearer and easier to follow than the docs for any given Java Web Server. The server docs all seem to be written with the assumption that you've already committed the Servlet spec to memory.

                               

                              http://download.oracle.com/otndocs/jcp/servlet-3.0-fr-eval-oth-JSpec/

                               

                              Makes for riveting bedtime reading.

                               

                              I just tried grabbing the Portlet specification (JSR 168) but it's apparently unavailable. I've inquired about this. I'll get back to you with a link when I know more.

                               

                              -Jonathan

                              • 12. Re: Errai and portlet deployment?
                                david.grigglestone

                                The good news is that I have the StockDemo running as a portlet.

                                 

                                The not so good news is that I have not worked out exactly what needs to be deployed to ROOT and what should live in the StockDemo war (META-INF/lib) .. e.g.

                                 

                                23:10:15,701 INFO  [ErraiMarshalling:113] searching for marshaller class: org.jboss.errai.marshalling.server.impl.ServerMarshallingFactoryImpl

                                23:10:15,703 WARN  [ErraiMarshalling:247] *** MULTIPLE VERSIONS OF org.jboss.errai.marshalling.server.impl.ServerMarshallingFactoryImpl FOUND IN CLASSPATH: Attempted to guess the newest one based on file dates. But you should clean your output directories

                                23:10:15,703 WARN  [ErraiMarshalling:247]  Ambiguous version -> /home/davidg/JSF/liferay-portal-6.1.0-ce-ga1.tomcat/tomcat-7.0.23/webapps/ROOT/WEB-INF/classes/org/jboss/errai/marshalling/server/impl/ServerMarshallingFactoryImpl.class

                                23:10:15,703 WARN  [ErraiMarshalling:247]  Ambiguous version -> /home/davidg/JSF/liferay-portal-6.1.0-ce-ga1.tomcat/tomcat-7.0.23/webapps/ROOT/WEB-INF/classes/org/jboss/errai/marshalling/server/impl/ServerMarshallingFactoryImpl.class

                                 

                                Will work on this some more next week (unless Jonathan has any particular guidence) .. but it does look like several steps forward.

                                • 13. Re: Errai and portlet deployment?
                                  cbrock

                                  This looks like a non-fatal error that is worthy of ignoring until we clean up our error detection on this issue.

                                  • 14. Re: Errai and portlet deployment?
                                    david.grigglestone

                                    So it looks like to get it working in Liferay I have to put most of of the StockDemo config/classes/lib in ROOT/WEB-INF .. as soon as I start moving org.errai.samples.stockdemo... classes out I start to get class not found symtoms.

                                     

                                    Since the Errai filter needs to be specified in ROOT (coz thats where Liferay filters are specified), it means the filter code needs to be there too .. but is there anyway the app code (StockDemo) can still reside in its own .war .. or will that mean restructuring Errai code?

                                     

                                    Is an alternative to Jon's changes, to leave the original servlet code alone and create a separate standalone filter that simply stops the request being fed to the liferay filters?

                                     

                                    Am I way off base?

                                     

                                    UPDATE: YES WAY OFF BASE!

                                    1 2 Previous Next