3:22 p.m.
I was chatting with Ales about his issues trying to incorporate a
seam-int module into a deployment, such that every deployment (which
bundles seam) would get a copy of those classes added to it.
So I thought I'd cover some options for a general approach to solving
this issue.
First, it is important to note that such content should NOT be made into
a static module. Modules are only for JARs which only have a single
instance in the app server.
I think a good possible approach would be to define a resource root in a
(different) module which contains the JAR file itself as an opaque
resource, and then reference that resource when constructing the deployer.
In this example I'll have a fictional module called
"org.jboss.ales.deployer".
The module.xml for this module should look something like this:
<module xmlns="urn:jboss:module:1.0"
name="org.jboss.ales.deployer">
<resources>
<resource-root path="bundled"/>
<!-- Insert resources here -->
</resources>
<dependencies>
<module name="org.jboss.as.controller"/>
<module name="org.jboss.as.server"/>
...other modules here...
</dependencies>
</module>
Then we deposit the nested seam-int JAR into the "bundled" subdirectory
of our module through some sort of build.xml modification, taking care
to use a predictable name for the JAR (as opposed to the long Maven name).
Having done this, code from the org.jboss.ales.deployer module can now
reliably acquire this file path:
File jarFile = new File(getClass().getResource("/seam-int.jar").toURI());
The File can then make its way to the deployment as a resource root,
thus creating a copy of the content in each deployment which our
deployer wishes to add it to.
Questions/comments?
--
- DML
3:57 p.m.
So we finally found the use case for copy content. It sounds all good to me.
On 6/2/11 3:22 PM, David M. Lloyd wrote:
I was chatting with Ales about his issues trying to incorporate a
seam-int module into a deployment, such that every deployment (which
bundles seam) would get a copy of those classes added to it.
So I thought I'd cover some options for a general approach to solving
this issue.
First, it is important to note that such content should NOT be made into
a static module. Modules are only for JARs which only have a single
instance in the app server.
I think a good possible approach would be to define a resource root in a
(different) module which contains the JAR file itself as an opaque
resource, and then reference that resource when constructing the deployer.
In this example I'll have a fictional module called
"org.jboss.ales.deployer".
The module.xml for this module should look something like this:
<module xmlns="urn:jboss:module:1.0"
name="org.jboss.ales.deployer">
<resources>
<resource-root path="bundled"/>
<!-- Insert resources here -->
</resources>
<dependencies>
<module name="org.jboss.as.controller"/>
<module name="org.jboss.as.server"/>
...other modules here...
</dependencies>
</module>
Then we deposit the nested seam-int JAR into the "bundled" subdirectory
of our module through some sort of build.xml modification, taking care
to use a predictable name for the JAR (as opposed to the long Maven name).
Having done this, code from the org.jboss.ales.deployer module can now
reliably acquire this file path:
File jarFile = new File(getClass().getResource("/seam-int.jar").toURI());
The File can then make its way to the deployment as a resource root,
thus creating a copy of the content in each deployment which our
deployer wishes to add it to.
Questions/comments?
--
Jason T. Greene
JBoss, a division of Red Hat
4:41 p.m.
OK, i think i see what you mean and how to do it.
I'll try to finish my Seam-int tomorrow.
Any suggestion how to change build.xml to create this bundled/ inside ales.deployer :)
module?
So we finally found the use case for copy content. It sounds all good
to me.
On 6/2/11 3:22 PM, David M. Lloyd wrote:
> I was chatting with Ales about his issues trying to incorporate a
> seam-int module into a deployment, such that every deployment (which
> bundles seam) would get a copy of those classes added to it.
>
> So I thought I'd cover some options for a general approach to solving
> this issue.
>
> First, it is important to note that such content should NOT be made into
> a static module. Modules are only for JARs which only have a single
> instance in the app server.
>
> I think a good possible approach would be to define a resource root in a
> (different) module which contains the JAR file itself as an opaque
> resource, and then reference that resource when constructing the deployer.
>
> In this example I'll have a fictional module called
> "org.jboss.ales.deployer".
>
> The module.xml for this module should look something like this:
>
> <module xmlns="urn:jboss:module:1.0"
name="org.jboss.ales.deployer">
>
> <resources>
> <resource-root path="bundled"/>
> <!-- Insert resources here -->
> </resources>
>
> <dependencies>
> <module name="org.jboss.as.controller"/>
> <module name="org.jboss.as.server"/>
> ...other modules here...
> </dependencies>
> </module>
>
> Then we deposit the nested seam-int JAR into the "bundled" subdirectory
> of our module through some sort of build.xml modification, taking care
> to use a predictable name for the JAR (as opposed to the long Maven name).
>
> Having done this, code from the org.jboss.ales.deployer module can now
> reliably acquire this file path:
>
> File jarFile = new File(getClass().getResource("/seam-int.jar").toURI());
>
> The File can then make its way to the deployment as a resource root,
> thus creating a copy of the content in each deployment which our
> deployer wishes to add it to.
>
> Questions/comments?
--
Jason T. Greene
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
7:35 a.m.
OK, I have this implemented.
But I now get this
14:15:27,001 ERROR
[org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/jboss-seam-jpa]] (MSC
service thread 1-3) Exception sending context initialized event to listener instance of
class org.jboss.seam.servlet.SeamListener: java.lang.IllegalArgumentException: Null path
at org.jboss.vfs.VFS.getChild(VFS.java:207) [jboss-vfs-3.0.0.GA.jar:3.0.0.GA]
at org.jboss.vfs.VFS.getChild(VFS.java:193) [jboss-vfs-3.0.0.GA.jar:3.0.0.GA]
at org.jboss.vfs.VFS.getChild(VFS.java:174) [jboss-vfs-3.0.0.GA.jar:3.0.0.GA]
at org.jboss.seam.integration.jbossas.vfs.VFSScanner.getRoot(VFSScanner.java:64)
[jboss-seam-int.jar:6.0.0.GA]
at org.jboss.seam.integration.jbossas.vfs.VFSScanner.scanResources(VFSScanner.java:151)
[jboss-seam-int.jar:6.0.0.GA]
at
org.jboss.seam.deployment.StandardDeploymentStrategy.scan(StandardDeploymentStrategy.java:105)
[jboss-seam.jar:6.0.0.GA]
at org.jboss.seam.init.Initialization.create(Initialization.java:122)
[jboss-seam.jar:6.0.0.GA]
at org.jboss.seam.servlet.SeamListener.contextInitialized(SeamListener.java:34)
[jboss-seam.jar:6.0.0.GA]
Where I don't see how URI::getPath is null.
http://anonsvn.jboss.org/repos/jbossas/projects/jboss-seam-int/tags/6.0.0...
This is how the URL is gained:
Enumeration<URL> urlEnum =
getDeploymentStrategy().getClassLoader().getResources(resourceName);
while (urlEnum.hasMoreElements())
{
URL url = urlEnum.nextElement();
VirtualFile root = getRoot(url, resourceName.lastIndexOf('/') >
0 ? 2 : 1);
and the call to VFS::getChild
protected VirtualFile getRoot(URL url, int parentDepth) throws IOException
{
log.trace("Root url: " + url);
VirtualFile top;
try {
top = VFS.getChild(url);
Any idea where this null path comes from?
Or how to avoid / fix it?
-Ales
On Jun 2, 2011, at 10:22 PM, David M. Lloyd wrote:
I was chatting with Ales about his issues trying to incorporate a
seam-int module into a deployment, such that every deployment (which
bundles seam) would get a copy of those classes added to it.
So I thought I'd cover some options for a general approach to solving
this issue.
First, it is important to note that such content should NOT be made into
a static module. Modules are only for JARs which only have a single
instance in the app server.
I think a good possible approach would be to define a resource root in a
(different) module which contains the JAR file itself as an opaque
resource, and then reference that resource when constructing the deployer.
In this example I'll have a fictional module called
"org.jboss.ales.deployer".
The module.xml for this module should look something like this:
<module xmlns="urn:jboss:module:1.0"
name="org.jboss.ales.deployer">
<resources>
<resource-root path="bundled"/>
<!-- Insert resources here -->
</resources>
<dependencies>
<module name="org.jboss.as.controller"/>
<module name="org.jboss.as.server"/>
...other modules here...
</dependencies>
</module>
Then we deposit the nested seam-int JAR into the "bundled" subdirectory
of our module through some sort of build.xml modification, taking care
to use a predictable name for the JAR (as opposed to the long Maven name).
Having done this, code from the org.jboss.ales.deployer module can now
reliably acquire this file path:
File jarFile = new File(getClass().getResource("/seam-int.jar").toURI());
The File can then make its way to the deployment as a resource root,
thus creating a copy of the content in each deployment which our
deployer wishes to add it to.
Questions/comments?
--
- DML
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
4922
days inactive
4923
days old
3 comments
3 participants
participants (3)
-
Ales Justin -
David M. Lloyd -
Jason T. Greene