[Design of JBoss Web Services] - Re: WS4EE and AS5
by alessio.soldano＠jboss.com
I've taken a look at the failing tests (with JACC server conf). I confirm that on AS5 trunk jbossws currently generates JBossWebMetaData and attaches it to the deployment unit.
| 2008-08-20 12:07:01,625 DEBUG [org.jboss.web.tomcat.service.deployers.TomcatDeployer] (RMI TCP Connection(5)-127.0.0.1) Begin deploy, org.jboss.metadata.web.jboss.JBossWebMetaData@1f
| 2008-08-20 12:07:01,625 DEBUG [org.jboss.web.tomcat.service.deployers.TomcatDeployer] (RMI TCP Connection(5)-127.0.0.1) Unpacking war to: /home/alessio/dati/jboss-5.0-src/build/output/jboss-5.0.0.CR2/server/jacc/tmp/deploy/ws4ee-jbws309.jar23188-exp.war
|
| ...
|
| 2008-08-20 12:07:01,674 DEBUG [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (RMI TCP Connection(5)-127.0.0.1) Linked java:comp/UserTransaction to JNDI name: UserTransaction
| 2008-08-20 12:07:01,674 DEBUG [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (RMI TCP Connection(5)-127.0.0.1) linkSecurityDomain
| 2008-08-20 12:07:01,674 DEBUG [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (RMI TCP Connection(5)-127.0.0.1) Linking security/securityMgr to JNDI name: java:/jaas/JBossWS
| 2008-08-20 12:07:01,675 DEBUG [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (RMI TCP Connection(5)-127.0.0.1) injectionContainer enabled and processing beginning
|
| ...
|
| 2008-08-20 12:07:02,755 DEBUG [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (RMI TCP Connection(5)-127.0.0.1) Initialized: {WebApplication: /home/alessio/dati/jboss-5.0-src/build/output/jboss-5.0.0.CR2/server/jacc/tmp/deploy/ws4ee-jbws309.jar23188-exp.war/, URL: file:/home/alessio/dati/jboss-5.0-src/build/output/jboss-5.0.0.CR2/server/jacc/tmp/deploy/ws4ee-jbws309.jar23188-exp.war/, classLoader: BaseClassLoader@2abdb{vfszip:/home/alessio/dati/jboss-5.0-src/testsuite/output/lib/ws4ee-jbws309.jar}:175067} jboss.web:j2eeType=WebModule,name=//localhost/ws4ee-jbws309,J2EEApplication=none,J2EEServer=none
|
In the 3 failing tests the call is not authorized by the JBossAuthorizationContext, but looking at the messages that go on the wire, I see an HTTP/1.1 200 OK coming back as a reply to the POST request with the SOAP message. I think that's why an exception is not raised on client side and the tests fail with the "Security exception expected" message and the "Premature end of file" complaint. The jbossws endpoint servlet is not called.
Please note that it seems to me the calls are rejected in the same way even when using the right principal/credential.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171460#4171460
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171460
17 years, 7 months
[Design the new POJO MicroContainer] - Re: vfsmemory url problem
by alesj
"alesj" wrote : I think the real problem is in InMemoryClassesDeployer.
| It's the way we create classes VirtualFile.
|
| | public void deploy(VFSDeploymentUnit unit) throws DeploymentException
| | {
| | try
| | {
| | URL dynamicClassRoot = new URL("vfsmemory", new GUID().toString(), "");
| | MemoryFileFactory.createRoot(dynamicClassRoot);
| | URL classesURL = new URL(dynamicClassRoot, "classes");
| | VirtualFile classes = MemoryFileFactory.createDirectory(classesURL);
| | unit.addAttachment(DYNAMIC_CLASS_URL_KEY, dynamicClassRoot);
| | unit.addAttachment(DYNAMIC_CLASS_KEY, classes);
| | unit.prependClassPath(classes);
| | log.debug("Dynamic class root for " + unit.getName() + " is " + dynamicClassRoot);
| |
| It should be a root.
|
This would do the trick
| public void deploy(VFSDeploymentUnit unit) throws DeploymentException
| {
| try
| {
| URL dynamicClassRoot = new URL("vfsmemory", new GUID() + "/classes", "");
| VirtualFile classes = MemoryFileFactory.createRoot(dynamicClassRoot).getRoot();
| unit.addAttachment(DYNAMIC_CLASS_URL_KEY, dynamicClassRoot);
| unit.addAttachment(DYNAMIC_CLASS_KEY, classes);
| unit.prependClassPath(classes);
| log.debug("Dynamic class root for " + unit.getName() + " is " + dynamicClassRoot);
|
Dunno why would we want to have classes as a child to guid root?
The only thing that I see useful is that we might group different
in-memory deployment's contents under the same guid 'group' root.
e.g. currently we have 'classes', we might have some other grouping notion
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171450#4171450
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171450
17 years, 7 months
[Design the new POJO MicroContainer] - Re: vfsmemory url problem
by alesj
"alesj" wrote : And even if you got past this,
| it's still wrong, since /classes/ part is then never used.
| MemoryContextFactory.java:
|
| | public VFSContext createRoot(URL url)
| | {
| | try
| | {
| | String rootName = url.getHost();
| | MemoryContext ctx = registry.get(rootName);
| | if (ctx == null)
| | {
| | String urlPath = url.getPath();
| | if (urlPath != null && urlPath.length() > 0)
| | throw new IllegalArgumentException("Root can not contain '/' - " + urlPath);
| |
| | URL ctxURL = new URL("vfsmemory://" + rootName);
| | ctx = new MemoryContext(ctxURL);
| | registry.put(rootName, ctx);
| | }
| | return ctx;
| |
|
I reverted this url path check move.
| public VFSContext createRoot(URL url)
| {
| try
| {
| String urlPath = url.getPath();
| if (urlPath != null && urlPath.length() > 0)
| throw new IllegalArgumentException("Root url cannot contain path - " + urlPath);
|
It's illegal to pass in url with path,
when you need root.
Since with the previous code,
you wouldn't get what you expected - /classes/ get ignored,
hence pointing to the wrong VirtualFile,
if this url was used as VFS.getRoot().
But now I get vfslink test failures - due to wrong assumption.
So, Marko, these tests need fixing.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171445#4171445
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171445
17 years, 7 months
[Design the new POJO MicroContainer] - Re: vfsmemory url problem
by alesj
I think the real problem is in InMemoryClassesDeployer.
It's the way we create classes VirtualFile.
| public void deploy(VFSDeploymentUnit unit) throws DeploymentException
| {
| try
| {
| URL dynamicClassRoot = new URL("vfsmemory", new GUID().toString(), "");
| MemoryFileFactory.createRoot(dynamicClassRoot);
| URL classesURL = new URL(dynamicClassRoot, "classes");
| VirtualFile classes = MemoryFileFactory.createDirectory(classesURL);
| unit.addAttachment(DYNAMIC_CLASS_URL_KEY, dynamicClassRoot);
| unit.addAttachment(DYNAMIC_CLASS_KEY, classes);
| unit.prependClassPath(classes);
| log.debug("Dynamic class root for " + unit.getName() + " is " + dynamicClassRoot);
|
It should be a root.
Otherwise I don't see how we can handle VFS::getRoot call on
a vfs's in-memory url that's not a root - as in our case.
We could create new vfs in-memory context for a given non-root url,
but that would mean memory leakage, since we would have no handle
to delete that context from memory.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171442#4171442
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171442
17 years, 7 months