I just (re-)submitted the initial parts of the
J2EE 1.4/WS4EE 1.0 implementation.
Fortunately, these are not exactly along
the rolledback prototype, but a rearchitectured,
this time more profound approach (that, especially,
has only a very loooooose and configurable coupling
of the interacting WS4EE, EJB and WAR deployers)
Some core components in server/system had to be
that purpose (which I tested as good as I could, but
certainly require some reviewing by Scott, Bill and
- org.jboss.deployment.JBossEntityResolver now also
caches new J2EE1.4 schemas (in conjunction with
subclass including the WS4EE1.0 schemas).
- org/jboss/metadata contains now additional
J2EE1.4 xsds, such as ejb_2_1.xsd. The jboss_3_2.dtd
has been patched such that a single container
configuration can support multiple invoker bindings
- etc/conf/standardjboss.xml binds an additional
proxy factory (provided by the jboss-net.sar)
under name "session-webservice-invoker". There is an
additional "Webservice-Enabled Session Bean"
which publishes both "standard-rmi-invoker" and
- org.jboss.metadata.ConfigurationMetaData and
BeanMetaData have been extended appropriately.
- org.jboss.ejb.EntityEnterpriseContext sometimes
needs access to the default proxy factory which is
the first one in the container config.
- org.jboss.metadata.XMLFileLoader has been made
namespace-aware (because of the xsd-based
descriptors), ApplicationMetaData will accept those
"doctype-null" documents when running in ejb2.1
SessionMetaData now references a new type of
interface, named "service-endpoint" and will
refer to the new standard container configuration
in the case of ws-enabled session beans.
collects information about a new type of method
belonging to that interface.
- org.jboss.invocation.InvocationType introduces this
method type "SERVICE_ENDPOINT" that is treated in
container equivalent to "LOCAL" and "REMOTE".
- org.jboss.ejb.SessionContainer factors out
highly redundant code from Stateless- and
StatefulSessionContainer (sorry, could not resist. It
for refactoring - If I messed something up, you may
me!). It caters now for the additional
have a reasonable way of providing session-based
stateful web-services - this is beyond the spec).
- org.jboss.ejb.Container will accept invocations on
InvocationType.SERVICE_ENDPOINT and route them
usual invoke() chain. Similarly,
org.jboss.ejb.plugins.AbstractTxInterceptor had such
case analysis that has been extended.
- org.jboss.ejb.EJBDeployer will generate additional
subdeployments when detecting a META-
in a jar. This is a temporary solution that will vanish
when we decide to go the "one-unit-multiple-
approach in MainDeployer. Until then, this is a feasible
workaround that allows the loose cooupling
This, by itself, will operate as usual in the J2EE<1.4
and give you some CNFE for the new proxy factory
in the J2EE1.4 case when using the "default" server
When using the "all" configuration (or by copying the
jboss-net.sar folder over to "default"), the following
happens (at least in the case of simple WS->EJB
we focused on):
- org.jboss.net.ws4ee.server.WS4EEDeployer gets hold
EJBDeployer subdeployment and registers its meta-
- org.jboss.net.ws4ee.server.EJBProxyFactoryImpl will
instantiated when the web-service enabled ejb
is created. It will then contact the corresponding
WebServiceModule through JMX and registers the
for the ejb-linked web services.
- WS4EEDeployer will transform the WS4EE1.0 meta-
a proper axis wsdd. Each EJB webservice endpoint will
represented herein by a
- The EJBInvokerProvider will contact the
through JMX and hence get an immediate reference to
container for invocation purposes using the new
InvocationType.SERVICE_ENDPOINT and to the
wsdl document for describing itself.
Many thanks to Thomas Diesler for jump-starting this
We two will now turn to more advanced things
like wsdl-location patching,
additional mapping meta-data, handler integration and
service stub generation and binding, uddi publication, ...
Michael Krause is going to do the WS->WAR part.
Log in to post a comment.