JBossDeveloper

Nice colours. ;-)

I don't see how this is a deployment or classloader issue?

If it is going in the wrong tomcat context then you've obviously not setup your
JBossWebMetaData correctly.

But since you don't show that, and it would be an issue for the Web/Tomcat developers
forum if you don't understand its metadata, I can't really help (again).

And like I said before. Passing the thread context classloader is almost certainly wrong
(but not related to your problem).
That is a wrapper classloader created by Tomcat for other purposes, e.g.
determining which ENC to use in jndi java:comp/env lookups.
You need to drill down through its parents to find the RealClassLoader.

"scott.stark@jboss.org" wrote:
You need to make a copy of the JBossWebMetaData and use setContextRoot("jaxws-endpoint").

"scott.stark@jboss.org" wrote:
We also need this usecase in the jbossas testsuite as an illustration of proper dynamic deployment creation.

There is some JBWS309UnitTestCase sitting in the AS test suite that can be used. It is originally part of the JACC test run. But it does not work correctly as I have seen the webapp deployed by JBossWS having no metadata created etc.

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=137352

Is this affecting our current tck regressions? Even though the predetermined object bucket is not the right one to be using, I don't think it should prevent the this code from working provided the context root is set correctly.

The org.jboss.wsf.spi.deployment.Deployment spi does not make the distinction between predetermined vs transient attachments so it does not look like an spi issue that should be fixed for CR1.

"scott.stark@jboss.org" wrote:
Even though the predetermined object bucket is not the right one to be using,

If you want it to parse xml then pass in a StructureMetaData that says
where that should come from.

"adrian@jboss.org" wrote:

That's exactly what it is for. It says I have predetermined what the
metadata is, so don't override it with whatever else you find, e.g. by parsing xml

"adrian@jboss.org" wrote:

If it is going in the wrong tomcat context then you've obviously not setup your
JBossWebMetaData correctly.

"adrian@jboss.org" wrote:

And like I said before. Passing the thread context classloader is almost certainly wrong

"scott.stark@jboss.org" wrote:

"adrian@jboss.org" wrote:

That's exactly what it is for. It says I have predetermined what the
metadata is, so don't override it with whatever else you find, e.g. by parsing xml

Agreed, but my point is that its not clear the webservices deployment layer is in the position to make this distinction.

Its taking JBossWebMetaData from an existing deployment according to the code shown, so I'm trying to understand how this is a separate deployment, especially if in the past it was simply updating web.xml/jboss-web.xml descriptors.

"richard.opalka@jboss.com" wrote:
BTW, how would you deal with the classloader issue Adrian?

ClassLoader cl = ...;
ClassLoader parent = cl.getParent();
while (cl instanceof org.jboss.classloading.spi.RealClassLoader == false && parent != null)
 cl = parent;

"richard.opalka@jboss.com" wrote:

"adrian@jboss.org" wrote:

If it is going in the wrong tomcat context then you've obviously not setup your
JBossWebMetaData correctly.

We call JBossWebMetaData.setContextRoot("jaxws-endpoint") for sure :(

"adrian@jboss.org" wrote:

And like I said before. Passing the thread context classloader is almost certainly wrong

Could you review this piece of code, please?
jbossas/trunk/webservices/src/main/org/jboss/wsf/container/jboss50/transport/EndpointAPIHttpTransport.java
and provide us constructive feedback e.g. what's fundamentally wrong there?

 // Get the context root for this deployment
 String contextRoot = dep.getService().getContextRoot();

"scott.stark@jboss.org" wrote:
Its taking JBossWebMetaData from an existing deployment according to the code shown, so I'm trying to understand how this is a separate deployment, especially if in the past it was simply updating web.xml/jboss-web.xml descriptors.

A quick look at the web deployers leads to a likely candidate
(since you're creating the endpoint from a servlet init).

package org.jboss.web.tomcat.service.deployers;

public class JBossContextConfig extends ContextConfig
{
 public static ThreadLocal<JBossWebMetaData> metaDataLocal = new ThreadLocal<JBossWebMetaData>();
 public static ThreadLocal<JBossWebMetaData> metaDataShared = new ThreadLocal<JBossWebMetaData>();

...

"adrian@jboss.org" wrote:
This is a task that you can do just as well as I can.