Thank you for the report !
It was actually JBJCA-204, JBJCA-205 and JBJCA-206 that made the deployment
fail. These issues are now fixed.
Something for our deployment verifier once we get started on that task
(JBJCA-201).
I will invite you to get involved in the embedded scenario. Currently the
Vicky, I looked over our patch - if you could update it in the area where error
conditions happens - f.ex. F.ex. if the user has specified an incorrect class
name, the driver hasn't been deployed to the lib/ directory, if the method
doesn't exist on the class and so on.
Lets focus on getting th
tapina, its https://jira.jboss.org/jira/browse/JBAS-4871.
Please, update.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236989#4236989
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236989
Only if you want to discuss and help with the implementation of the
functionality - otherwise just keep an eye on the JIRA.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235488#4235488
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting
The same - but allTheInBootLib IS all the stuff in lib which is >
DEFAULT_BOOT_LIBRARY_LIBS.
I only have a single lib/ directory where the entire container is located.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4233991#4233991
Reply to the post :
http://
anonymous wrote :
| We don't. :) We boot library list is of the AS Main, not bootstrap. It can
be removed from its explicit form if we change the build to only put stuff in
$JBOSS_HOME/lib which should be part of the boot CL.
|
My point is here - why do we have to define a DEFAULT_BOOT_LIB
Yeah, and do we want to create that hard dependency between the MC and VFS ?
Another question is if bootstrap/MC should make assumptions about CLs. I think
having to define a DEFAULT_BOOT_LIBRARY_LIST is something we should think about.
View the original post :
http://www.jboss.org/index.html?m
anonymous wrote :
| So for users of MCServer who need VFS, you've gotta do something similar.
But a better solution is for some initvfs.xml to come along early in the
bootstrap chain, install an MC Bean which will init VFS, and then all should be
good.
|
That is the solution I use currentl
I get the following trace:
| Caused by: java.net.MalformedURLException: unknown protocol: vfsfile
| at java.net.URL.(URL.java:574)
| at java.net.URL.(URL.java:464)
| at java.net.URL.(URL.java:413)
| at
org.jboss.virtual.plugins.context.file.FileHandler.(
David, show me the documentation for
|
|
and why it would be needed when building a container based on MC.
Or should I just scan your projects and look for MC beans ?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230912#4230912
Reply to the post
There are two level of users here.
1) End users
2) Other developers inside JBoss
End users should hopefully never see the jboss-beans.xml files - but that is
the case today unless you plan to fix that.
The foundation of our projects should be the MC, but if there isn't any
documentation for th
Since a lot of hooking our services together have moved to the -jboss-beans.xml
we need a way of documenting those beans, so other projects can get a quicker
overview of what's available.
Of course the beans should provide sane defaults for many of the properties,
but there are a lot of cases w
Just for the record - the original trace I got was
https://jira.jboss.org/jira/browse/JBVFS-112
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230559#4230559
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230559
__
I use Linux, so it is problem on all platforms I guess...
And I havn't seen this with 4.2.4.GA...
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230453#4230453
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230453
Here is another one:
| 09:01:10,998 INFO [TomcatDeployment] deploy, ctxPath=/jboss-profiler
| 09:01:11,308 INFO [config] Initializing Mojarra (1.2_12-b01-FCS) for
context '/jboss-profiler'
| 09:01:22,503 INFO [TomcatDeployment] undeploy, ctxPath=/jboss-profiler
| 09:01:22,582 ERROR [W
Users shouldn't have to worry about the scanPeriod parameter - a deployment
should be an atomic operation.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230446#4230446
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=423
I get stack traces when I hot-deploy on AS 5.x (currently rev88714 using
VFS-2.1.1.GA).
Sample application is the web ui for JBoss Profiler 2 - a .WAR file around 6MB
- deployment is done in non-exploded format. The stack traces can be easy
triggered if the deployments are done in a tight loop.
I have created https://jira.jboss.org/jira/browse/JBJCA-94 as a placeholder for
reauthentication support for the JBJCA project.
If you want to discuss the design and implementation of the functionality feel
free to drop by the JCA developer forum. Patches is of course most welcomed :)
View the
Ok, back working on this again.
The question is how to best implement test cases for the deployer chain.
In the end the project should boot in standalone mode with a deploy/ directory
where the .rar files are located. So defining a bootstrap.xml file should be
first on the list.
Is the bootstr
I took a look at the test case in question.
The success/failure has a lot to do with timing (which should be fixed) and the
parameters used for the setup. The JTS setup shows > 10x longer running period
than the JTA counterpart.
So I would say that the *StressTestCase should be excluded for now
anonymous wrote : This should just plug-in into AnnotationEnvironment.
| See
| (Filtered)AnnotationEnvironmentDeployer in JBossAS's
metadata-deployer-jboss-beans.xml.
Do you have an example somewhere ? I'm not running in the AS -- this is for the
standalone JCA container directly on the MC
I'm currently looking into implementing the new resource adapter deployers for
JCA 1.6 (JBJCA-35).
The chain must be able to handle the following
1) ra.xml
2) jboss-ra.xml
3) JCA 1.6 annotated classes
from within a .RAR archive.
1) and 3) are specified by the JCA specification and 2) is our sp
Please, try with the Branch_4_2 SVN branch, since there have been updates in
this area post AS-4.2.2.GA.
You can find the instructions on the JBoss wiki for checkout and building.
If the problem persist - update this post.
View the original post :
http://www.jboss.com/index.html?module=bb&op=v
23 matches
Mail list logo
