[Design of JBoss Remoting, Unified Invokers] - Re: Remoting 2: Servlet Invoker
by ron.sigal＠jboss.com
While you were off finding G-d, I got invoker-test to pass. :)
There's one change in servlet-invoker-service.xml:
| <?xml version="1.0" encoding="UTF-8"?>
|
| <server>
|
| <mbean code="org.jboss.remoting.transport.Connector" name="jboss.remoting:service=connector,transport=servlet"
| display-name="Servlet transport Connector">
| <attribute name="InvokerLocator">servlet://${jboss.bind.address}:8080/servlet-invoker/ServerInvokerServlet</attribute>
| <attribute name="Configuration">
| <handlers>
| <handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler>
| </handlers>
| </attribute>
| </mbean>
|
| </server>
|
In particular, I changed the MBean name from "jboss.remoting:service=invoker,transport=servlet" to "jboss.remoting:service=connector,transport=servlet". That's the source of the "Unable to find operation processRequest(javax.servlet.http.HttpServletRequest,[B,javax.servlet.http.HttpServletResponse)" problem. ServerInvokerServlet found the "jboss.remoting:service=invoker,transport=servlet" it was looking for, but what it was finding was an org.jboss.remoting.transport.Connector instead of the ServletServerInvoker created by the Connector.
Also, I changed web.xml:
| <web-app>
| <servlet>
| <servlet-name>ServerInvokerServlet</servlet-name>
| <description>The ServerInvokerServlet receives requests via HTTP
| protocol from within a web container and passes it onto the
| ServletServerInvoker for processing.
| </description>
| <servlet-class>org.jboss.remoting.transport.servlet.web.ServerInvokerServlet</servlet-class>
| <!--init-param>
| <param-name>invokerName</param-name>
| <param-value>jboss.remoting:service=invoker,transport=servlet</param-value>
| <description>The servlet server invoker</description>
| </init-param-->
| <init-param>
| <param-name>locatorUrl</param-name>
| <param-value>servlet://${jboss.bind.address}:8080/servlet-invoker/ServerInvokerServlet</param-value>
| <description>The servlet server invoker</description>
| </init-param>
| <load-on-startup>1</load-on-startup>
| </servlet>
| <servlet-mapping>
| <servlet-name>ServerInvokerServlet</servlet-name>
| <url-pattern>/ServerInvokerServlet/*</url-pattern>
| </servlet-mapping>
| </web-app>
|
so that it searches for the ServletServerInvoker by InvokerLocator instead of MBean name. Strictly speaking, that shouldn't be necessary, as long as the correct MBean name is supplied.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201602#4201602
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201602
17 years, 2 months
[Design of EJB 3.0] - Re: PU Injection across JARs (unrelated DeploymentUnits)
by ALRubinger
An update.
Looks like the dependency issue I illustrated before is handled by the resolver; I must have misread something while debugging/testing. The concept works.
Carlo has taken the prototype done in my patch and applied InterApplicationPersistenceUnitDependencyResolver in r82833.
However, this introduces regression in org.jboss.ejb3.test.persistenceunits.unit.MultipleEarTestCase.testBadEar.
The case is defined by https://jira.jboss.org/jira/browse/JBAS-5043, and shows that InterApplicationPersistenceUnitDependencyResolver is a JBoss-specific extension which is in violation w/ spec:
"EJB3 Persistence Specification 6.2.2" wrote : When referencing a persistence unit using the unitName annotation element or persistence-unit-name deployment descriptor element, the visibility scope of the persistence unit is determined by its point of definition. A persistence unit that is defined at the level of an EJB-JAR, WAR, or application client jar is scoped to that EJB-JAR, WAR, or application jar respectively and is visible to the components defined in that jar or war. A persistence unit that is defined at the level of the EAR is generally visible to all components in the application.
So "org.jboss.ejb3.test.hbm.unit.EntityUnitTestCase.testAll" is testing a spec violation.
We can:
If we really want to test both cases, we can extract one out into a JBoss-specific test with its own server configs to explicitly set the appropriate PU Resolver. Or we could just Unit Test the cases.
Which resolver do we want to use as a default? "hbm" and the "persistenceunits.testBadEar" cases are mutually-exclusive.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201600#4201600
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201600
17 years, 2 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: servlet transport implementation
by trustin
Sorry for the late response. I was busy with releasing Netty 3.1.0.ALPHA3. :-)
"ataylor" wrote : A ServletContextListener will create a ClientBootstrap on startup. This will be configured via properties, probably read in from a config file with some sensible defaults. This will be added as an attribute to the ServletTransport. It would be cool if netty had an invm client bootstrap to use however in the absence of this it will be a normal socket connection. Trustin, currently would there be any way of doing this invm?
What does 'invm' transport refer to here? Do you want Netty to add in-vm transport, or do you want Netty can talk to the in-vm transport that JBM uses internally? The only interfaces that you need to implement is 'ChannelFactory' and 'Channel', so it's not a big deal to implement a bridge between JBM invm transport and Netty. ClientBootstrap should work with any ChannelFactory implementation.
"ataylor" wrote : An HttpSessionListener will be used to create a connection for each session. Since netty doesn't support cookies at the minute we will have to manually check the headers to pull out the session id and add it as a parameter for all further requests.
I think Netty needs to provide a cookie encoder / decoder as we did for query strings.
"ataylor" wrote : Also at this point we'll set the pipeline factory before creating the connection. a seperate instance of a 'ServletChannelHandler will be set for each connection. Both the Channel and the ServletChannelhandler will be added to the session as attributes.
|
| The ServletChannelHandler will work 2 ways. On MessageReceived it will either 1) store the received buffers to be returned by the next http request (polling) or 2) write directly to the ServletOutputStream (streaming).
|
| The Servlet itself will decode the http request body and forward it via the channel previously set on the session. It will then set the appropriate headers on the response and return as the body any awaiting responses if using the polling method.
I understood how it works, but out of curiosity, why does the Servlet need to talk to JBM via Netty? Isn't it just enough for the Servlet to talk to JBM directly? Perhaps I am missing out something.
"ataylor" wrote : From a client side we'll be able to reuse most of what we already have. maybe just a few changes for using sessions and for streaming.
|
| Trustin, how would you like me to package the servlet classes etc. Also i'll include some sample web.xml configurations etc so where should i put these?
It could be distributed as a separate WAR, hence we could create a subproject under svn.jboss.org/repos/netty/subproject/servlet (or some cool name :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201594#4201594
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201594
17 years, 2 months