-
1. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?
adrian.brock Sep 27, 2006 9:23 AM (in response to bill.burke)This is wrong. You need to use the classpath to find out what to scan.
e.g. scanning the root of a war will pickup a
myway.war/something.class files that are not part of the classpath,
instead they are contents to be served over the web.
It is for this reason that I don't want to expose the full DeploymentContext
via the DeploymentUnit. Because people will do things that don't
correspond to the full model.
I'd suggest something like making a combination helper out of the:
org.jboss.deployers.plugins.deployers.helpers.ClassPathVisitor
and
org.jboss.virtual.plugins.vfs.helpers.SuffixMatchFilter
since this could be a common pattern?
Then add a
void visitClassPath(VirtualFileVisitor)
to the deployment unit. -
2. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?
adrian.brock Sep 27, 2006 9:27 AM (in response to bill.burke)Note: The notion of things like an abstract ClassPath and MetaDataLocation
is fundamental to the aspectized deployers being able to work
with varied style/structure of deployments.
Some of which we haven't even invented yet :-) -
3. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?
bill.burke Sep 27, 2006 10:10 AM (in response to bill.burke)can you please describe how DeploymentContext.getClassPath() is formed?
-
4. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?
bill.burke Sep 27, 2006 10:12 AM (in response to bill.burke)I don't think getClassPath will work. I'm not sure that manifest entries are supposed to be scanned as well.
-
5. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?
bill.burke Sep 27, 2006 12:33 PM (in response to bill.burke)e.g. scanning the root of a war will pickup a
myway.war/something.class files that are not part of the classpath,
instead they are contents to be served over the web.
Are the JARs within WEB-INF/lib DeploymentUnits in the new kernel? If so, then WEB-INF/classes also needs to be a separate DeploymentUnit.
Persistence Units are scoped when deployed within a WAR or EJB-JAR. Also the gay '#' syntax can be used to navigate to PUs within different components deployed within an EAR. -
6. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?
adrian.brock Sep 27, 2006 12:57 PM (in response to bill.burke)"bill.burke@jboss.com" wrote:
Are the JARs within WEB-INF/lib DeploymentUnits in the new kernel? If so, then WEB-INF/classes also needs to be a separate DeploymentUnit.
No. The deployment unit is the war.
WEB-INF/lib and WEB-INF/classes form part of the ClassPath. -
7. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?
adrian.brock Sep 27, 2006 12:59 PM (in response to bill.burke)"bill.burke@jboss.com" wrote:
I don't think getClassPath will work. I'm not sure that manifest entries are supposed to be scanned as well.
If that is the case, then we'll need a more refined notion
of classpath that differentiates internal elements from
imported elements.
We probably need this anyway for the OSGI style classloader
that Scott started? -
8. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?
adrian.brock Sep 27, 2006 1:09 PM (in response to bill.burke)"bill.burke@jboss.com" wrote:
Persistence Units are scoped when deployed within a WAR or EJB-JAR. Also the gay '#' syntax can be used to navigate to PUs within different components deployed within an EAR.
Yes navigation of the whole deployment (top level + children)
is an api that needs adding to the DeploymentUnit.
I *hacked* it for the rar, so it can generate the myear.ear#myrar.rar
but this needs fixing!!!
The "gay" # syntax is actually part of the URI specification.
http://www.ietf.org/rfc/rfc2396.txt
file:///some/path/some.ear#some.jar
It's clearly no use for nested jars within nested jars.
The VFS uses a more logical/obvious name :-)
file:///some/path/some.ear/some.jar -
9. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?
bill.burke Sep 27, 2006 3:35 PM (in response to bill.burke)"adrian@jboss.org" wrote:
"bill.burke@jboss.com" wrote:
Are the JARs within WEB-INF/lib DeploymentUnits in the new kernel? If so, then WEB-INF/classes also needs to be a separate DeploymentUnit.
No. The deployment unit is the war.
WEB-INF/lib and WEB-INF/classes form part of the ClassPath.
As far as Class-path manifest goes, I think we are screwed either way. For auto-scanning of the PU you will want to scan only the classpath manifest of one particular jar in web-inf/lib.
Another problem I see is again, what abput META-INF/persistence.xml? In a war, it could be in multiple JARs in web-inf/lib. I need to be able to look at the JAR as a completely contained unit. So whether or not Class-path manifest should be scanned, I still need to know what exact JARS are in WEB-INF/lib excluding classpath manifest entries so that I can find the META-INF/persistence.xml for each of these jars.
Also, what about an EJB-JAR within an EAR? Is the EJB-JAR a DeploymentUnit I assume? If it is a DeploymentUnit does its ClassPath contain EAR/lib jars? If so this is really bad as again, I need to treat the EJB-JAR as its own unit. -
10. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?
adrian.brock Sep 28, 2006 5:19 AM (in response to bill.burke)"bill.burke@jboss.com" wrote:
As far as Class-path manifest goes, I think we are screwed either way. For auto-scanning of the PU you will want to scan only the classpath manifest of one particular jar in web-inf/lib.
You make it sound like the jars in WEB-INF/lib should be separate
deployment units?
Also, what about an EJB-JAR within an EAR? Is the EJB-JAR a DeploymentUnit I assume? If it is a DeploymentUnit does its ClassPath contain EAR/lib jars? If so this is really bad as again, I need to treat the EJB-JAR as its own unit.
Each deployment unit has its own classpath.
That way it is possible to implement one classloader per
deployment unit or what is done now, a classloader
for the whole deployment by consolidating the classpath with
that visitor I mentioned before.
Feel free to extend the model to whatever fine granularity you
require.
e.g. making each jar in WEB-INF/lib its own deployment unit
e.g.2. separating the classpath into internal/external (manifest)
components
This api is not final until we understand what
the real deployers need.
to do -
11. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?
bill.burke Sep 28, 2006 10:24 AM (in response to bill.burke)Yeah, I don't think doing deployments based on ClassPath is the way to go. For instance, in an embedded jboss environment (Java SE) every component has the same classpath.
-
12. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?
bill.burke Sep 28, 2006 10:26 AM (in response to bill.burke)Come to think of it Classpath is more of an abstract thing. We need to know structure and deploy based on a structure.
-
13. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?
adrian.brock Sep 28, 2006 10:35 AM (in response to bill.burke)"bill.burke@jboss.com" wrote:
Come to think of it Classpath is more of an abstract thing. We need to know structure and deploy based on a structure.
Which is exactly what the structure deployers do.
They create the classpath from structure.
Exists:
Is this a jar? Well the classpath is the root
Is this a war? Then the classpath is WEB-INF/classes and WEB-INF/lib/*.jar
Doesn't exist:
Is this a j2se system classloader, then the classpath is the
paths from the system property. Or more likely each
path element is made into a deployment unit so you could even
add an ear to the classpath. ;-) -
14. Re: Why is DeploymentUnit.getDeploymentContext() deprecated?
bill.burke Sep 28, 2006 11:25 AM (in response to bill.burke)No, what i'm saying is that certain deployers need to deploy based on a concrete structure, not a classpath. Or in other words, the lines are too blurry for some deployers to be driven by classpath.
This is why for EARS and WARS I think their lib/ and classes/ directories need to be treated as child DeploymentUnits.