Ah ok, I understand now (my fault).
I had been assuming that VFS was doing its own copy of the artifact and that
the removal (or update) of the original file was only used as an indicator of
an undeploy (or redeploy) to be done (then followed by a removal of the copy).
But, yeah, if it does
Ok, thanks (message crossover...).
I am going to try what JIRA suggest.
Gilles.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4192997#4192997
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4192997
Yes, it worked.
Thanks :-)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4192998#4192998
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4192998
___
jboss-user mailing list
Ah! I forgot to precise. For this test I am using JBoss 5 RC 2.
Thanks again for your help.
Gilles.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4192996#4192996
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4192996
At the moment I must admit I haven't defined any dependencies metadata as
everything is self contained in a single small jar file. Do I still need to
define them? (admittedly I kind of relied on the JAR structure deployer to
define the default CL going with a JAR...)
The sample is a simple
For info.
Having though about the problem, I agree with JIRA if the situation is the case
where components start threads and they still go on (creating new objects)
after the stop method on the main POJO has ended.
But in my example, the stop method returns only once all threads involved in
Hello,
I just noticed an interesting problem with the bean lifecycle method stop().
It seems that once we are in the stop method the classloader is not available
anymore...
Currently in my stop method, the code build an array from a list doing the
following bit:
handlers =
Hello,
If my understanding is correct MC has a notion of application context (which is
the ControllerContext or something like that if I am not mistaken?).
Now what I wonder is: is JBoss JNDI aware of this context?
Ideally I would like a deployer to be able to add entries to the application
Ok, I think I found out why changing the domain on the ClassLoaderMetaData
didn't propagate to the created classloader. It is due to the fact the code
uses the Module.domain attribute rather than the Module.metadata.domain.
All the other information seems to propagate fine.
I will try to
Yes, I saw the code you refer to. But that's what got me puzzled:
I suspect you are refering to the fact that, if there is no ClassLoaderFactory,
then it will automatically create one (as VFSTopLevelClassLoaderSystemDeployer
is a decendant of AbstractClassLoaderDeployer).
But still, before the
I am using JBoss AS 5 beta 3 (so MC beta 9) with the changes in the bootstrap
config that activates the MC classloading mechanism.
I tried to have the AS 5 beta 3 running with the trunk version of MC but it
failed on startup...
I will try at some point against a trunk of MC (although I will
Ok, Thanks :-)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4129125#4129125
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4129125
___
jboss-user mailing list
Ok, I just tried against JBoss AS 5 beta 4 and admittedly I am still having the
same problem...
I also just realized that it must be some default classloader mechanism that
must create the BaseClassLoader because in fact the
VFSTopLevelClassLoaderSystemDeployer that has been deployed for the
Ok, so is JBoss 5 beta 4 a reasonable test environment for this issue?
Or should I try and fit in it the latest MC trunk in it? (I mean, I can try but
I am not sure I will succeed: I had a few issues when I tried that a few days
ago with the trunk and AS 5 beta 3).
View the original post :
What makes me wonder if VFSTopLevelClassLoaderSystemDeployer is called is
because it declares that it needs a ClassLoaderFactory as input.
anonymous wrote :
| [DeployersImpl] Added deployer [EMAIL PROTECTED] for stage ClassLoader
| [EMAIL PROTECTED],
anonymous wrote :
| Where do you see it getting created?
| Since it's the AbstractTopLevelClassLoaderSystemDeployer that does this in
AS5 -- VFSTopLevelClassLoaderSystemDeployer, and its stage is CLASSLOADER.
|
Ok, so I suspect the problem I am getting is the fact that the
Ok, here is the code for TestDescribeDeployer:
| package protomcf.test.deployer;
|
| import java.util.List;
|
| import org.jboss.deployers.spi.DeploymentException;
| import org.jboss.deployers.spi.deployer.DeploymentStages;
| import
Ok, don't bother replying to my question yet: I am currently looking at
WarClassLoaderDeployer and it looks like it will hold the answers to my
questions.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4128756#4128756
Reply to the post :
I have a few questions the concerning the DESCRIBE and CLASSLOADER deployer
stages.
I understand the principle that DESCRIBE is used to declare/define the
dependencies whilst the CLASSLOADER stage is related to the classloader itself.
I have noticed that the classloader instance
Sorry, last question for today.
I am doing further testing with the deployers and I have noticed that the
ClassLoaderMetaData info does not seem to be used (or fully used?) yet by the
subsystem that triggers the creation of the classloader.
In my describe stage I try to change the domain (to
Hello,
Looking at the JBoss MC source code I can see that a describe deployer can
add capabilities information before the classloader gets
created(ClassLoaderMetaData.setCapabilities()), thus allowing dependency
resolution for a unit being deployed.
Now, I wonder about the deployer
But this seems to confirm that if I don't specify any input then the deployer
is always called (rather than never).
So far I was always doing a setAllInputs(true) but that probably was not
necessary...
Thanks again.
Gilles.
View the original post :
Arghh... My bad. I completly forgot to notice that the log.debug command was
after the if that was checking the presence of the LoaderRepositoryConfig...
Sorry...
But thanks for your useful help.
Gilles.
View the original post :
Hello, I am trying to understand JBoss MC and there is a thing on deployer
sequencing that I don't understand:
When JBoss MC is used in the context of JBoss AS I can see that the
HackClassloaderMetaDataDeployer class is only being triggered by the deployment
of console-mgr.sar. Now I must
As far as I can see it is only triggered once (looking at the log file) for a
default jboss run (includes an EJB 3 bean and a few other test deployers).
In fact I am trying to understand the exact relationships and rules existing
between the classloader that seem to be created by the structure
Hello,
I am looking at how I could have an external client passing security
credentials to the JBoss server (for example situation where I attempt to use
an EJB). Usually the solution would be to pass the credentials to the
InitialContext or use ClientLoginModule.
However, I can't pass these
Ok, Thanks for your comments, it did help me in finding out what happened.
Yes, the xercesImpl.jar isn't properly loaded and the reason was because I
launched the application from Ant, and Ant uses its own XML parser, which was
conflicting the ones used by JBoss MC.
When I manually start it
Hello,
I have been trying to start JBoss MC using a variant of the bootstrap code as
described for MC 1. The code is a little long to post but here is a key extract
(although I will post the code if it can help):
deployer = new BeanXMLDeployer(getKernel());
KernelDeployment deployment =
Note: I am using the JBoss MC 2 from subversion obtained on the 2nd of April
2007 (SVN 61987).
Gilles.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4034049#4034049
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4034049
The 3rd-party folder seems to have been removed when MC 2 was moved to Maven.
So I couldn't directly try your suggestion.
I just tried with the files coming from the 3rd party folder of jbossmc2_beta3
(the last tagged version before the move to Maven) but to no avail...
I get the same error...
30 matches
Mail list logo
