[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1_06 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_06-b01) Java HotSpot(TM) Server VM (build 1.3.1_06-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [mkdir] Created dir: /home/jboss/jbossci/jboss-all/aop/output/lib [jar] Building jar: /home/jboss/jbossci/jboss-all/aop/output/lib/jboss-aop.jar == == == Finished 'most' in module 'aop'. == == _module-aop-most: [copy] Copying 1 file to /home/jboss/jbossci/jboss-all/build/output/testbuild/lib [copy] Copying 1 file to /home/jboss/jbossci/jboss-all/build/output/testbuild/lib == == == Executing 'most' in module 'cache'... == == configure-modules: Overriding previous definition of reference to jboss.naming.classpath compile-mbean-sources: [mkdir] Created dir: /home/jboss/jbossci/jboss-all/cache/output/gen/classes /home/jboss/jbossci/jboss-all/cache/src/main not found. at org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner(AbstractFileSet.java:369) at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:61) at org.apache.tools.ant.Task.perform(Task.java:319) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:336) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.jboss.tools.buildmagic.task.Ant.execute(Ant.java:261) at org.jboss.tools.buildmagic.task.module.ExecuteModules$1.run(ExecuteModules.java:329) at org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModule(ExecuteModules.java:342) at org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(ExecuteModules.java:217) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:166) at org.apache.tools.ant.Task.perform(Task.java:319) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:336) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.Project.executeTargets(Project.java:1250) at org.apache.tools.ant.Main.runBuild(Main.java:610) at org.apache.tools.ant.Main.start(Main.java:196) at org.apache.tools.ant.Main.main(Main.java:235) BUILD FAILED file:/home/jboss/jbossci/jboss-all/cache/build.xml:117: Unexpected error Total time: 41 seconds --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS= = JAVA VERSION DETAILS java version 1.4.1_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01) Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [mkdir] Created dir: /home/jboss/jbossci/jboss-all/aop/output/lib [jar] Building jar: /home/jboss/jbossci/jboss-all/aop/output/lib/jboss-aop.jar == == == Finished 'most' in module 'aop'. == == _module-aop-most: [copy] Copying 1 file to /home/jboss/jbossci/jboss-all/build/output/testbuild/lib [copy] Copying 1 file to /home/jboss/jbossci/jboss-all/build/output/testbuild/lib == == == Executing 'most' in module 'cache'... == == configure-modules: Overriding previous definition of reference to jboss.naming.classpath compile-mbean-sources: [mkdir] Created dir: /home/jboss/jbossci/jboss-all/cache/output/gen/classes /home/jboss/jbossci/jboss-all/cache/src/main not found. at org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner(AbstractFileSet.java:369) at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:61) at org.apache.tools.ant.Task.perform(Task.java:319) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:336) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.jboss.tools.buildmagic.task.Ant.execute(Ant.java:261) at org.jboss.tools.buildmagic.task.module.ExecuteModules$1.run(ExecuteModules.java:329) at org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModule(ExecuteModules.java:342) at org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(ExecuteModules.java:217) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:166) at org.apache.tools.ant.Task.perform(Task.java:319) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:336) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.Project.executeTargets(Project.java:1250) at org.apache.tools.ant.Main.runBuild(Main.java:610) at org.apache.tools.ant.Main.start(Main.java:196) at org.apache.tools.ant.Main.main(Main.java:235) BUILD FAILED file:/home/jboss/jbossci/jboss-all/cache/build.xml:117: Unexpected error Total time: 46 seconds --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] HEAD build problem with foe-deployer tests
I think there is still a problem with the recently re-enabled foe deployer tests. I can't build the testsuite on a clean checkout: [ejbdoclet] Generating weblogic-cmp-rdbms-jar.xml. [ejbdoclet] org.xml.sax.SAXParseException: Element weblogic-rdbms-bean does not allow field-map here. [ejbdoclet] at org.apache.crimson.parser.Parser2.error(Parser2.java:3160) [ejbdoclet] at org.apache.crimson.parser.ValidatingParser$ChildrenValidator.consume(ValidatingParser.java:349) [ejbdoclet] at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1 --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: HEAD build problem with foe-deployer tests
Hello David, I'm working on it. Probably, I'll disable it again. Sorry for troubles. alex Sunday, December 15, 2002, 3:53:02 PM, you wrote: DJ I think there is still a problem with the recently re-enabled foe deployer DJ tests. I can't build the testsuite on a clean checkout: DJ [ejbdoclet] Generating weblogic-cmp-rdbms-jar.xml. DJ [ejbdoclet] org.xml.sax.SAXParseException: Element weblogic-rdbms-bean DJ does not allow field-map here. DJ [ejbdoclet] at org.apache.crimson.parser.Parser2.error(Parser2.java:3160) DJ [ejbdoclet] at org.apache.crimson.parser.ValidatingParser$ChildrenValidator.consume(ValidatingParser.java:349) DJ [ejbdoclet] at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1 -- Best regards, Alex Loubyansky --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] deployment scripts + extending Configuration of JBossSXon the fly
David Jencks wrote: Hi Anatoly, I think your discussion has 2 parts that are to me pretty much completely unrelated: 1. you want to be able to write deployment scripts using jelly 2. you want to be able to deploy bits of security stuff with your packages. You are correct, the two pieces are pretty much unrelated, it is just that I realized a need for (1) after having stumbled upon (2) which (within the current security framework) might need (1) just be able to point Deployer to a URL which contains a deployable unit with all its plumbing/security aspects configurable by a script contained in the unit itself. As for 2, I need to look into this also for resource adapter deployment. I don't see how it is related to the need for scripting: it seems to me that either I don't understand how the xml login stuff works or it needs extension. (so far I know little about it). I guess it is Scott who should know :) Making the security stuff accept say mbeans with additional rather than replacement security info is surely a more appropriate fix than introducing scripting for this reason alone. I am not proposing introducing scripting just for that purpose. I think, scripting is an extremely useful tool that can solve my simple problem but can make other people's lives easier as well. Lets talk about (1) some more. We already have the jboss mbean service lifecycle, with the create, start, stop, destroy methods called during deployment and undeployment. If I understand your proposal correctly, the same effect of your jelly script could be obtained by writing some java code in the mbean start method say to invoke the same methods on the same mbeans as in the jelly script. Is this correct or did I miss something? You are correct that most things can be accomplished from within the MBean during the lifecycle methods. But not all the things that are currently done from within the lifecycle methods, imho, belong in there. I think, we can learn something from EJBs, namely, that the plumbing should be externalized and taken care by someone else, not EJB itself. (By plumbing I mean setup of the appropriate references to other beans/resources, basically the context in which the bean operates). Let me give you an example. If you take a look at JBossMQ org.jboss.mq.security.SecurityManager (3.0.4). Conceptually, what it does is some form of MQ-specific security checks which are actually delegated to the JBoss security domain. Practically speaking, the MQ SecurityManager MBean is only interested in knowing the reference to the JBoss SecurityDomain it is attached to, nothing more, no need to know where to look it up, how, etc. I would say, all this SecurityManager needs is a pair of MBean methods: setSecurityDomain(), getSecurityDomain(). It should be responsibility of the Deployer to attach MQ's SecurityManager to appropriate SecurityDomain at deployment time. IMHO this begs for scripting. All references to other MBeans should be completely externalized and settable, say, at deploy time through scripting. This way it is infinitely easier to change connections w/o having to modify the lookup logic, names or whatever else is coded in the lifecycle methods. This should, in fact be a mandatody design pattern. Do you know how many MBeans reference the TransactionManager? How many of them have java:/TransactionManager hardcoded for lookup. What if I want to run 2 instances of TransactionManager (this may or may not be crazy but why not?) and under different JNDI names than java:/TransactionManager? I am not proposing getting rid of lifecycle methods. Could be that some of the things done inside lifecycle methods should remain there and never be externalized. In fact, if you look at most of the mbeans I write, you see that in the start method they are often invoking methods on other mbeans. This is usually needed to set up the context in which they operate. Precisely the job of scripting. Usually your bean knows what it needs to operate. Setting up the context should be external to the business logic! This is how everything is done: servlets, ejbs. It seems that MBeans should not be any different. Scripting is just the way to achieve this, not the only one, but I guess one of the simplest. So, it seems to me that the main point in favor of jelly scripting has to be greater convenience and flexibility. Can you provide a specific example showing an example of this where the configuration has to be instance specific, so it is not appropriate to put in the start method of the java class, or is just much easier to write externally? Another bonus of going with Jelly is, as I mentioned in the original e-mail, is the fact that with care, current *-service.xml's can remain the same -- full backward compatibility and quite infinite extensibility. There are, in fact, tags in Jelly that do JSTL (emulate standard jsp tag libs). You gain lots of stuff for free and just
Re: [JBoss-dev] Re: HEAD build problem with foe-deployer tests
I ended up with disabling WebLogic DDs validation, thus relying on XDoclet to generate correct DDs. If someone knows the reason why it happens on first run. Please, let me know. Thanks, alex Sunday, December 15, 2002, 4:12:39 PM, you wrote: AL Hello David, AL I'm working on it. Probably, I'll disable it again. AL Sorry for troubles. AL alex AL Sunday, December 15, 2002, 3:53:02 PM, you wrote: DJ I think there is still a problem with the recently re-enabled foe deployer DJ tests. I can't build the testsuite on a clean checkout: DJ [ejbdoclet] Generating weblogic-cmp-rdbms-jar.xml. DJ [ejbdoclet] org.xml.sax.SAXParseException: Element weblogic-rdbms-bean DJ does not allow field-map here. DJ [ejbdoclet] at org.apache.crimson.parser.Parser2.error(Parser2.java:3160) DJ [ejbdoclet] at org.apache.crimson.parser.ValidatingParser$ChildrenValidator.consume(ValidatingParser.java:349) DJ [ejbdoclet] at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1 -- Best regards, Alex Loubyansky --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1_06 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_06-b01) Java HotSpot(TM) Server VM (build 1.3.1_06-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [mkdir] Created dir: /home/jboss/jbossci/jboss-all/aop/output/lib [jar] Building jar: /home/jboss/jbossci/jboss-all/aop/output/lib/jboss-aop.jar == == == Finished 'most' in module 'aop'. == == _module-aop-most: [copy] Copying 1 file to /home/jboss/jbossci/jboss-all/build/output/testbuild/lib [copy] Copying 1 file to /home/jboss/jbossci/jboss-all/build/output/testbuild/lib == == == Executing 'most' in module 'cache'... == == configure-modules: Overriding previous definition of reference to jboss.naming.classpath compile-mbean-sources: [mkdir] Created dir: /home/jboss/jbossci/jboss-all/cache/output/gen/classes /home/jboss/jbossci/jboss-all/cache/src/main not found. at org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner(AbstractFileSet.java:369) at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:61) at org.apache.tools.ant.Task.perform(Task.java:319) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:336) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.jboss.tools.buildmagic.task.Ant.execute(Ant.java:261) at org.jboss.tools.buildmagic.task.module.ExecuteModules$1.run(ExecuteModules.java:329) at org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModule(ExecuteModules.java:342) at org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(ExecuteModules.java:217) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:166) at org.apache.tools.ant.Task.perform(Task.java:319) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:336) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.Project.executeTargets(Project.java:1250) at org.apache.tools.ant.Main.runBuild(Main.java:610) at org.apache.tools.ant.Main.start(Main.java:196) at org.apache.tools.ant.Main.main(Main.java:235) BUILD FAILED file:/home/jboss/jbossci/jboss-all/cache/build.xml:117: Unexpected error Total time: 43 seconds --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
I have requested a clean checkout several times and these are still being generate. It appears the 1.4.1_01 compile is still checking out the old jboss-all alias rather than jboss-head. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, December 15, 2002 2:34 AM Subject: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed = ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS= = JAVA VERSION DETAILS java version 1.4.1_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01) Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [mkdir] Created dir: /home/jboss/jbossci/jboss-all/aop/output/lib [jar] Building jar: /home/jboss/jbossci/jboss-all/aop/output/lib/jboss-aop.jar == == == Finished 'most' in module 'aop'. == == _module-aop-most: [copy] Copying 1 file to /home/jboss/jbossci/jboss-all/build/output/testbuild/lib [copy] Copying 1 file to /home/jboss/jbossci/jboss-all/build/output/testbuild/lib == == == Executing 'most' in module 'cache'... == == configure-modules: Overriding previous definition of reference to jboss.naming.classpath compile-mbean-sources: [mkdir] Created dir: /home/jboss/jbossci/jboss-all/cache/output/gen/classes /home/jboss/jbossci/jboss-all/cache/src/main not found. at org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner(AbstractFileSet.java:369) at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:61) at org.apache.tools.ant.Task.perform(Task.java:319) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:336) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.jboss.tools.buildmagic.task.Ant.execute(Ant.java:261) at org.jboss.tools.buildmagic.task.module.ExecuteModules$1.run(ExecuteModules.java:329) at org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModule(ExecuteModules.java:342) at org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(ExecuteModules.java:217) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:166) at org.apache.tools.ant.Task.perform(Task.java:319) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:336) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.Project.executeTargets(Project.java:1250) at org.apache.tools.ant.Main.runBuild(Main.java:610) at org.apache.tools.ant.Main.start(Main.java:196) at org.apache.tools.ant.Main.main(Main.java:235) BUILD FAILED file:/home/jboss/jbossci/jboss-all/cache/build.xml:117: Unexpected error Total time: 46 seconds --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] deployment scripts + extending Configuration of JBossSX on the fly
Well, the use case driving this is simply a problem with how JBossMQ integrates
with the security framework. Its a hardcoded property of its security manager
rather than an attribute of the service. If the latter was the case then you could
reference a unique configuration.
The security config can be part of any deployment using the same approach
as that shown in the org.jboss.test.security.service.SecurityConfig and the
associated security unit tests. I'll be moving this out of the test package into the
general security framework in the near future.
So let's not cloud the discussion of why scripting of deployment descriptors
is needed based on an improper integration of a service. Most of what you
are talking about is similar to the binding service in the varia module:
org.jboss.services.binding.ServiceBindingManager. Investigate how this
can be extended to incorporate what you need.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Anatoly Akkerman [EMAIL PROTECTED]
To: JBoss-Dev [EMAIL PROTECTED]
Sent: Saturday, December 14, 2002 8:17 PM
Subject: [JBoss-dev] deployment scripts + extending Configuration of JBossSX on the fly
Hello, Jbossers
It seems that for the benefit of the wider audience I'll start with the
deployment scripting idea. For those interested in what drove me to the
idea, see below in the security part (I am sure people will have their
own use-cases for this stuff, I remember discussions from before)
For my project I need to be able not only to deploy/undeploy services on
the fly but, sometimes this is insufficient, I also need to stich them
together after deploy, unstich before undeploy, say by invoking a bunch
of methods on a bunch of MBeans.
This is clearly a deployment issue, perhaps, there is a need to move
from 'Slackware'-style packaging to 'Debian'-style packaging for
components (or at least, add extensions people can use). To explain the
analogy:
Slackware used plain old tgz's for its packages which one would just
untar and that's it. This works for simple things but when the system
grows and packages become more dependent on other packages and
versioning info, etc., this does not cut it anymore.
Debian uses a sophisticated package format with a whole bunch of stuff
packed into the package, like dependency information, pre-/post-
-installation/-configuration/-removal scripts that can modify/unmodify
various config files, etc. Obviously, in the simplest form a .deb can be
do as little as a .tgz does.
The simplest scripting tool which would be suitable for quick jobs like
the one I need, would be something based on Apache Jelly.
Let's say, the *-service.xml is not really a descriptor (though it
appears as such, we don't need to change old descriptors either) but,
say the JBoss DeployerMBean, instead of treating it as plain XML
interprets it as a Jelly script. JBoss provides a standard JBoss tag
library that interprets the tags for the *-service.xml, say, mbean tag
deploys the MBean specified by the tag's attributes and configures it
appropriately. So, a simple deployment descriptor would not notice any
difference. But, say you add another attributed to the mbean tag, say,
'referenceVar' which specifies the name of the variable under which the
object name of the newly created bean will be stored in the JellyContext
in which this script is running. Then, one can simply add a scripting
section at the end of *-service.xml which manipulates the initialized
variables, e.g. through custom jelly tags locate and invoke methods on
MBeans specified by variables from the JellyContext:
mbean code=xxx name=yyy refVar=mbeanX/
jmxinvoke targetObj=${mbeanX} method=${methodDesc} args=${args} /
where jmxinvoke is a custom Jelly tag which takes a target object name,
method description object and arguments array and does the invocation.
Obviously this is very similar to the jsp tags, which is exactly the
point of Jelly. So, with properly defined tags for invocation, exception
handling, etc, one can do simple meta-programming of MBeans during
deployment.
At the end, the DeployerMBean which processes this script, checks for
exceptions coming from the script execution and deals with them
according to the convention: calls the cleanup section of the script or
whatever. (By clean-up section I mean that the *-service.xml can be made
of sections which the deployer 'executes' depending on whether previous
stages succeed/fail)
This is the end of deployment issue/proposal. Now the security question.
Here is the problem setting:
I need to be able to have deploy any JBoss service, possibly multiple
instances, simultaneously on the same server. For that I have an
infrastructure for reconfiguring JBoss descriptors of services. For
example, for JBossMQ, I make sure that all MBeans that comprise
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS= = JAVA VERSION DETAILS java version 1.4.1_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01) Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [mkdir] Created dir: /home/jboss/jbossci/jboss-all/aop/output/lib [jar] Building jar: /home/jboss/jbossci/jboss-all/aop/output/lib/jboss-aop.jar == == == Finished 'most' in module 'aop'. == == _module-aop-most: [copy] Copying 1 file to /home/jboss/jbossci/jboss-all/build/output/testbuild/lib [copy] Copying 1 file to /home/jboss/jbossci/jboss-all/build/output/testbuild/lib == == == Executing 'most' in module 'cache'... == == configure-modules: Overriding previous definition of reference to jboss.naming.classpath compile-mbean-sources: [mkdir] Created dir: /home/jboss/jbossci/jboss-all/cache/output/gen/classes /home/jboss/jbossci/jboss-all/cache/src/main not found. at org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner(AbstractFileSet.java:369) at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:61) at org.apache.tools.ant.Task.perform(Task.java:319) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:336) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.jboss.tools.buildmagic.task.Ant.execute(Ant.java:261) at org.jboss.tools.buildmagic.task.module.ExecuteModules$1.run(ExecuteModules.java:329) at org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModule(ExecuteModules.java:342) at org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(ExecuteModules.java:217) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:166) at org.apache.tools.ant.Task.perform(Task.java:319) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:336) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.Project.executeTargets(Project.java:1250) at org.apache.tools.ant.Main.runBuild(Main.java:610) at org.apache.tools.ant.Main.start(Main.java:196) at org.apache.tools.ant.Main.main(Main.java:235) BUILD FAILED file:/home/jboss/jbossci/jboss-all/cache/build.xml:117: Unexpected error Total time: 45 seconds --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] little things JnYb
Title: READ THIS SIMPLE SYSTEMTM BEST SERVICE, BEST PRICES, GUARANTEED RESULTS! DIAL 1-512-497-4718 I make $1000's or more everyday What's the secret you ask...? It's simple, SIMPLE SYSTEM! All you need to do is reach the masses and your product or service will make you money. I supply you with everything you need to do just that! I supply email addresses , bulk hosting, bulk pop3 email accounts, bulk mail sending services, opt-in-leads, html ad design, leads, automated systems, lead generating systems, business/advertising consulting, and filter checks... are you getting through? Within just hours you will notice the incredible results from the SIMPLE SYSTEM! I can do all the work for you while you do nothing at all or I can set you up to send your own mail (OVER 20 MILLION PER DAY!) OUR PACKAGE RATES: (ALL PRODUCTS SOLD INDIVIDUALLY AS WELL) SIMPLE SYSTEM STARTER PACKAGE SIMPLE SYSTEM PRO PACKAGE 2 WEEKS BULK HOSTING 2 WEEKS BULK HOSTING BULK POP3 EMAIL ACCOUNT BULK POP3 EMAIL ACCOUNT 2 MILLION VERIFIED EMAIL ADDRESSES 20 MILLION VERIFIED EMAIL ADDRESSES 2 MILLION EMAILS DELIVERED 20 MILLION EMAILS DELIVERED HTML AD DESIGN- INCLUDES FORM HTML AD DESIGN- INCLUDES FORM FREE-SETUP $1000 BI-WEEKLY NO MINIMUM FREE-SETUP $2500 BI-WEEKLY NO MIMUM SAVE OVER $550.00 SAVE OVER $2750.00 WE HAVE OVER 300 MILLION VERIFIED EMAILS! WE FULLY-GUARANTEE YOUR SATISFACTION! UNCONDITIONAL REPLACEMENT POLICY! WE WILL BEAT ANY PRICE! _ SIMPLE SYSTEM is a permission based marketing company with a strict NO-SPAM policy. We want to provide you with only the best offers that either earn or save you lot's of money! If your tired of all the junk mail you've been receiving than let us make a difference. We will share your email address with know one! If you do not wish to participate in our monthly give-a-ways and email promotions, simply click reply, and send an email with remove101 in the subject line. iPi
Re: [JBoss-dev] deployment scripts + extending Configuration of JBossSXon the fly
Scott M Stark wrote:
Well, the use case driving this is simply a problem with how JBossMQ integrates
with the security framework. Its a hardcoded property of its security manager
rather than an attribute of the service. If the latter was the case then you could
reference a unique configuration.
Wholeheartedly agree that this piece of MQ is poorly written.
The security config can be part of any deployment using the same approach
as that shown in the org.jboss.test.security.service.SecurityConfig and the
associated security unit tests. I'll be moving this out of the test package into the
general security framework in the near future.
I've taken a look at the SecurityConfig. All it does is create an
XMLLoginConfig MBean and then push it to the top of the stack of
Configurations. So, basically it does its own custom scripting. It
solves the problem but isn't it an overkill to create an MBean whose
function is only to instantiate another MBean and register it with the
third? This is pure metaprogramming.
I still have a security question, though:
If I understand correctly, the entire Configuration gets replaced by the
one that currently sits on the stack? Can I just add a particular piece,
say, only application-policy for 'jbossmq-instanceid1234' while all
other policies remain in place? Can I later remove any named application
policy w/o affecting the rest? Stack seems to be a very limited data
structure, I cannot add jbossmq-id1, jbossmq-id2 and then remove
them in the _same_ (not stack-based) order.
Is there any technical limitation for doing what I need? Am I misreading
something? Please, correct me if I am wrong.
So let's not cloud the discussion of why scripting of deployment descriptors
is needed based on an improper integration of a service. Most of what you
are talking about is similar to the binding service in the varia module:
org.jboss.services.binding.ServiceBindingManager. Investigate how this
can be extended to incorporate what you need.
I've taken a look at the ServiceBindingManager. It is somewhat similar
to what I need but not exactly. In fact, it could have been a lot
simpler (w/o requiring one to write a special delegate class that is
responsible for changing configuration) by using the scripting facility
itself. Here is how it could be done when *-service.xml is interpreted
as a script:
Deployer loads a configuration for a service (similar to ServiceConfig)
which can be simply a property sheet.
It initializes variables in the JellyContext with values from the
ServiceConfig
Let's say the ServiceConfig for this bean has the following properties,
so we simply set variables in JellyContext with the appropriate names:
FooService.Name = myDomain:service=Foo-1
FooService.ref1 = otherDomain:service=someName
FooService.jndiName = java:/Foo-1
FooService.propX = someValue
Deployer loads the foo-service.xml and executes it (it sets the taglib
to the deployTagLib).
foo-service.xml should have references to appropriate variables, like:
mbean name=${FooService.Name} class=so.and.soClass
depends optional-attribute-name=ref1${FooService.ref1}/depends
attribute name=JndiName${FooService.jndiName}/attribute
attribute name=propX${FooService.propX}/attribute
/mbean
mbean tag creates the MBean with the given name and class (expression
${FooService.Name} is evaluated in the JellyContext and value of
myDomain:service=Foo-1 gets filled in.
the mbean evaluates its body (which means that depend and
attribute tags get executed.
depends tag ensures that the dependency is present
attribute tag locates closes surrounding mbean, gets its mbean and
sets the attributed to the appropriate value.
Now, if you wanted to reset certain attributes on an already existing
mbean, you would run _the same_ foo-service.xml but using a
reconfigureTagLib which binds the mbean tag to tag implementation that
looks up the mbean instead of creating it.
Ain't it simpler?
Scott Stark
Chief Technology Officer
JBoss Group, LLC
--
-
Anatoly Akkerman
Computer Science Dept.
Courant Institute of Mathematical Sciences, NYU
715 Broadway, #719 Tel: 212 998-3493
New York, NY 10003 Fax: 212 995-4123
-
---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-654181 ] Inaccurate deployment error message
Bugs item #654181, was opened at 2002-12-15 20:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=654181group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Jarl Petter Kvalsvik (ttjarl) Assigned to: Nobody/Anonymous (nobody) Summary: Inaccurate deployment error message Initial Comment: org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCRelationM etaData throws a DeploymentException with the errormessage Atleast one role of a foreign-key mapped relationship must have key fields when primkey-field is missing in ejb-jar.xml. The errormessage suggests that something is wrong with jbosscmp-jdbc.xml (missing key fields), but it should also make a hint that the primkey-field in ejb- jar.xml file could be missing. Os: Windows 2000 JDK: Sun VM 1.3.1 Sun VM 1.4.1 JBoss: 3.0.4 with Tomcat 4.1.12 How to reproduce: Remove the primkey-field from a valid ejb-jar.xml file containing CMPs with one-to-many relationship(s). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=654181group_id=22866 --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] deployment scripts + extending Configuration of JBossSX on the fly
- Original Message -
From: Anatoly Akkerman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, December 15, 2002 10:57 AM
Subject: Re: [JBoss-dev] deployment scripts + extending Configuration of JBossSX on
the fly
I've taken a look at the SecurityConfig. All it does is create an
XMLLoginConfig MBean and then push it to the top of the stack of
Configurations. So, basically it does its own custom scripting. It
solves the problem but isn't it an overkill to create an MBean whose
function is only to instantiate another MBean and register it with the
third? This is pure metaprogramming.
This is no different than deploying a new DataSource with a deployment and
as such I don't see it as pure metaprogramming, whatever that is.
I still have a security question, though:
If I understand correctly, the entire Configuration gets replaced by the
one that currently sits on the stack? Can I just add a particular piece,
say, only application-policy for 'jbossmq-instanceid1234' while all
other policies remain in place? Can I later remove any named application
policy w/o affecting the rest? Stack seems to be a very limited data
structure, I cannot add jbossmq-id1, jbossmq-id2 and then remove
them in the _same_ (not stack-based) order.
Is there any technical limitation for doing what I need? Am I misreading
something? Please, correct me if I am wrong.
Yes, the stack as used right now is too global. There needs to be a stack
per security domain. Pushing a config into a non-existent domain is equivalent
to adding a config for the doamin. Pushing a config into an existing domain
either overrides or augments the configuration. This change will be made
when I move the dynamic config service out of the testsuite.
I've taken a look at the ServiceBindingManager. It is somewhat similar
to what I need but not exactly. In fact, it could have been a lot
simpler (w/o requiring one to write a special delegate class that is
responsible for changing configuration) by using the scripting facility
itself. Here is how it could be done when *-service.xml is interpreted
as a script:
Deployer loads a configuration for a service (similar to ServiceConfig)
which can be simply a property sheet.
It initializes variables in the JellyContext with values from the
ServiceConfig
Let's say the ServiceConfig for this bean has the following properties,
so we simply set variables in JellyContext with the appropriate names:
FooService.Name = myDomain:service=Foo-1
FooService.ref1 = otherDomain:service=someName
FooService.jndiName = java:/Foo-1
FooService.propX = someValue
Deployer loads the foo-service.xml and executes it (it sets the taglib
to the deployTagLib).
foo-service.xml should have references to appropriate variables, like:
mbean name=${FooService.Name} class=so.and.soClass
depends optional-attribute-name=ref1${FooService.ref1}/depends
attribute name=JndiName${FooService.jndiName}/attribute
attribute name=propX${FooService.propX}/attribute
/mbean
mbean tag creates the MBean with the given name and class (expression
${FooService.Name} is evaluated in the JellyContext and value of
myDomain:service=Foo-1 gets filled in.
the mbean evaluates its body (which means that depend and
attribute tags get executed.
depends tag ensures that the dependency is present
attribute tag locates closes surrounding mbean, gets its mbean and
sets the attributed to the appropriate value.
Now, if you wanted to reset certain attributes on an already existing
mbean, you would run _the same_ foo-service.xml but using a
reconfigureTagLib which binds the mbean tag to tag implementation that
looks up the mbean instead of creating it.
Ain't it simpler?
Its not obviously simpler, and I don't see how this would be able to handle the
transform of an attribute which itself is an xml fragment requiring the equivalent of
XSLT to make the change. This also does not allow one to modify existing
configurations. You have to first change the base configuration to be written
with the scripting language.
Let's see a prototype to weigh the advantages and disadvantages. All we need to
do is add the ability to externalize the bootstrap deployment services and we
can switch between alternate view of deployment processing.
---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-head daily clean failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1_06 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_06-b01) Java HotSpot(TM) Server VM (build 1.3.1_06-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE build.sh: build.sh: No such file or directory --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS= = JAVA VERSION DETAILS java version 1.4.1_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01) Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [mkdir] Created dir: /home/jboss/jbossci/jboss-head/aop/output/lib [jar] Building jar: /home/jboss/jbossci/jboss-head/aop/output/lib/jboss-aop.jar == == == Finished 'most' in module 'aop'. == == _module-aop-most: [copy] Copying 1 file to /home/jboss/jbossci/jboss-head/build/output/testbuild/lib [copy] Copying 1 file to /home/jboss/jbossci/jboss-head/build/output/testbuild/lib == == == Executing 'most' in module 'cache'... == == configure-modules: Overriding previous definition of reference to jboss.naming.classpath compile-mbean-sources: [mkdir] Created dir: /home/jboss/jbossci/jboss-head/cache/output/gen/classes /home/jboss/jbossci/jboss-head/cache/src/main not found. at org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner(AbstractFileSet.java:369) at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:61) at org.apache.tools.ant.Task.perform(Task.java:319) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:336) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.jboss.tools.buildmagic.task.Ant.execute(Ant.java:261) at org.jboss.tools.buildmagic.task.module.ExecuteModules$1.run(ExecuteModules.java:329) at org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModule(ExecuteModules.java:342) at org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(ExecuteModules.java:217) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:166) at org.apache.tools.ant.Task.perform(Task.java:319) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:336) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.Project.executeTargets(Project.java:1250) at org.apache.tools.ant.Main.runBuild(Main.java:610) at org.apache.tools.ant.Main.start(Main.java:196) at org.apache.tools.ant.Main.main(Main.java:235) BUILD FAILED file:/home/jboss/jbossci/jboss-head/cache/build.xml:117: Unexpected error Total time: 48 seconds --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
Hi, This crap code is definitely from jboss-head (not jboss-all). It compiles fine with jdk1.3 - but fails with jdk1.4. Regards, Chris --- [EMAIL PROTECTED] wrote: = ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS= = JAVA VERSION DETAILS java version 1.4.1_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01) Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [mkdir] Created dir: /home/jboss/jbossci/jboss-head/aop/output/lib [jar] Building jar: /home/jboss/jbossci/jboss-head/aop/output/lib/jboss-aop.jar == == == Finished 'most' in module 'aop'. == == _module-aop-most: [copy] Copying 1 file to /home/jboss/jbossci/jboss-head/build/output/testbuild/lib [copy] Copying 1 file to /home/jboss/jbossci/jboss-head/build/output/testbuild/lib == == == Executing 'most' in module 'cache'... == == configure-modules: Overriding previous definition of reference to jboss.naming.classpath compile-mbean-sources: [mkdir] Created dir: /home/jboss/jbossci/jboss-head/cache/output/gen/classes /home/jboss/jbossci/jboss-head/cache/src/main not found. at org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner(AbstractFileSet.java:369) at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:61) at org.apache.tools.ant.Task.perform(Task.java:319) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:336) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.jboss.tools.buildmagic.task.Ant.execute(Ant.java:261) at org.jboss.tools.buildmagic.task.module.ExecuteModules$1.run(ExecuteModules.java:329) at org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModule(ExecuteModules.java:342) at org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(ExecuteModules.java:217) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:166) at org.apache.tools.ant.Task.perform(Task.java:319) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:336) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.Project.executeTargets(Project.java:1250) at org.apache.tools.ant.Main.runBuild(Main.java:610) at org.apache.tools.ant.Main.start(Main.java:196) at org.apache.tools.ant.Main.main(Main.java:235) BUILD FAILED file:/home/jboss/jbossci/jboss-head/cache/build.xml:117: Unexpected error Total time: 48 seconds --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development = __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
A clean checkout of jboss-head is compiling for me under JDK1.4.1_01 on win2k and RedHat 8.0 and RedHat 7.3. The issue has to be a conflict with the way the JDK/Ant are running in your environment. Neither environment has ANT_HOME set. What does a build with the -verbose flag passed in show immeadiately before the failure? Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Chris Kimpton [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, December 15, 2002 2:06 PM Subject: Re: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed Hi, This crap code is definitely from jboss-head (not jboss-all). It compiles fine with jdk1.3 - but fails with jdk1.4. Regards, Chris --- [EMAIL PROTECTED] wrote: = ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS= = JAVA VERSION DETAILS java version 1.4.1_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01) Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [mkdir] Created dir: /home/jboss/jbossci/jboss-head/aop/output/lib [jar] Building jar: /home/jboss/jbossci/jboss-head/aop/output/lib/jboss-aop.jar == == == Finished 'most' in module 'aop'. == == _module-aop-most: [copy] Copying 1 file to /home/jboss/jbossci/jboss-head/build/output/testbuild/lib [copy] Copying 1 file to /home/jboss/jbossci/jboss-head/build/output/testbuild/lib == == == Executing 'most' in module 'cache'... == == configure-modules: Overriding previous definition of reference to jboss.naming.classpath compile-mbean-sources: [mkdir] Created dir: /home/jboss/jbossci/jboss-head/cache/output/gen/classes /home/jboss/jbossci/jboss-head/cache/src/main not found. at org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner(AbstractFileSet.java:369) at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:61) at org.apache.tools.ant.Task.perform(Task.java:319) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:336) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.jboss.tools.buildmagic.task.Ant.execute(Ant.java:261) at org.jboss.tools.buildmagic.task.module.ExecuteModules$1.run(ExecuteModules.java:329) at org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModule(ExecuteModules.java:342) at org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(ExecuteModules.java:217) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:166) at org.apache.tools.ant.Task.perform(Task.java:319) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:336) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.Project.executeTargets(Project.java:1250) at org.apache.tools.ant.Main.runBuild(Main.java:610) at org.apache.tools.ant.Main.start(Main.java:196) at org.apache.tools.ant.Main.main(Main.java:235) BUILD FAILED file:/home/jboss/jbossci/jboss-head/cache/build.xml:117: Unexpected error Total time: 48 seconds --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] InitialContext ctx = new InitialContext(); in RMIConnectorImpl
Hi guys, I run in a problem with RMIConnectorImpl in the jmx/connector/rmi package. When I use the RMIConnetor in project I get a exception: javax.naming.NoInitialContextException: Cannot instantiate class: org.jnp.interfaces.NamingContextFactory. Root exception is java.lang.ClassNotFoundException: org.jnp.interfaces.NamingContextFactory That happens at line 578: InitialContext ctx = new InitialContext(); When I replace this lines with: NamingContextFactory f = new NamingContextFactory(); Context ctx = f.getInitialContext(System.getProperties()); Thank it looks like it working fine for me. Can somebody give me a hint, what I can do, instead create a custom jmx-connector package? Something like assign the RMIConnectorImpl my own Context? Thanks Stefan --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 15-December-2002
JBoss daily test results SUMMARY Number of tests run: 1001 Successful tests: 991 Errors:9 Failures: 1 [time of test: 2002-12-15.15-31 GMT] [java.version: 1.3.1] [java.vendor: Apple Computer, Inc.] [java.vm.version: 1.3.1_03-69] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Mac OS X] [os.arch: ppc] [os.version: 10.2.2] See http://users.jboss.org/~starksm/Branch_3_0/2002-12-15.15-31 for details of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: CircularityUnitTestCase Test: testPackageProtected(org.jboss.test.classloader.test.CircularityUnitTestCase) Type:error Exception: javax.management.MBeanException Message: Exception in MBean operation 'testPackageProtected()' - Suite: RollBackUnitTestCase Test: testAsynchDurableTopicReceiveRollBack(org.jboss.test.jbossmq.test.RollBackUnitTestCase) Type:error Exception: java.lang.NullPointerException Message: - Suite: LocalWrapperCleanupUnitTestCase Test: testAutoCommitOffInRemoteUserTx(org.jboss.test.jca.test.LocalWrapperCleanupUnitTestCase) Type:error Exception: java.rmi.ServerException Message: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: EJBException:; nested exception is: javax.ejb.EJBException: Row committed, autocommit still on! - Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: jboss.test:name=missingclasstest is not registered.; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: SimpleUnitTestCase Test:testHaInvoker(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.naming.CommunicationException Message: Receive timed out - Suite: SimpleUnitTestCase Test:testHaParitionName(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.naming.CommunicationException Message: Receive timed out - Suite: SimpleUnitTestCase Test:testSecureHttpInvoker(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.security.auth.login.LoginException Message: Missing users.properties file. - Suite: SimpleUnitTestCase Test:testLoginInitialContext(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.naming.AuthenticationException Message: Failed to login using protocol=testLoginInitialContext - Suite: BeanStressTestCase Test:testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: expected a client deadlock for AB BA - Suite: ContextCLTestCase Test: testInvokeNeedingTCL(org.jboss.test.jbossmx.implementation.server.ContextCLTestCase) Type:error Exception: javax.management.RuntimeMBeanException Message: RuntimeException in MBean operation 'registerClassLoader(,org.jboss.mx.loading.UnifiedClassLoader)' - --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
Chris, I will dedicate time to do a grep and peplace your .sh /peter PS: and also dub U as the first to get Rewarded ! ; söndagen den 15 december 2002 kl 19.33 skrev [EMAIL PROTECTED]: = ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS= = JAVA VERSION DETAILS java version 1.4.1_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01) Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [mkdir] Created dir: /home/jboss/jbossci/jboss-all/aop/output/lib [jar] Building jar: /home/jboss/jbossci/jboss-all/aop/output/lib/jboss-aop.jar == == == Finished 'most' in module 'aop'. == == _module-aop-most: [copy] Copying 1 file to /home/jboss/jbossci/jboss-all/build/output/testbuild/lib [copy] Copying 1 file to /home/jboss/jbossci/jboss-all/build/output/testbuild/lib == == == Executing 'most' in module 'cache'... == == configure-modules: Overriding previous definition of reference to jboss.naming.classpath compile-mbean-sources: [mkdir] Created dir: /home/jboss/jbossci/jboss-all/cache/output/gen/classes /home/jboss/jbossci/jboss-all/cache/src/main not found. at org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner(Abstract FileSet.java:369) at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:61) at org.apache.tools.ant.Task.perform(Task.java:319) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:336) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.jboss.tools.buildmagic.task.Ant.execute(Ant.java:261) at org.jboss.tools.buildmagic.task.module.ExecuteModules$1.run(ExecuteModu les.java:329) at org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModule(Exe cuteModules.java:342) at org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(ExecuteMo dules.java:217) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:166) at org.apache.tools.ant.Task.perform(Task.java:319) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:336) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.Project.executeTargets(Project.java:1250) at org.apache.tools.ant.Main.runBuild(Main.java:610) at org.apache.tools.ant.Main.start(Main.java:196) at org.apache.tools.ant.Main.main(Main.java:235) BUILD FAILED file:/home/jboss/jbossci/jboss-all/cache/build.xml:117: Unexpected error Total time: 45 seconds --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
I had this same error on winxp, jdk1.4.1. Manually creating the directory allowed the build to finish. I thought it had something to do with an empty directory in the cache project -- is there supposed to be code in the cache/src/main directory? There are only other empty directories on the cvsview pages at sourceforge. I am using tortoiseCVS to check out. The log says it is using: cvs -q update -d -P CVSROOT=:pserver:[EMAIL PROTECTED]:/cvsroot/jboss I thought the -d flag for update was meant to force empty directory check-outs, so I am still not sure what is going on. Later, fawce -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Scott M Stark Sent: Sunday, December 15, 2002 6:22 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed A clean checkout of jboss-head is compiling for me under JDK1.4.1_01 on win2k and RedHat 8.0 and RedHat 7.3. The issue has to be a conflict with the way the JDK/Ant are running in your environment. Neither environment has ANT_HOME set. What does a build with the -verbose flag passed in show immeadiately before the failure? Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Chris Kimpton [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, December 15, 2002 2:06 PM Subject: Re: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed Hi, This crap code is definitely from jboss-head (not jboss-all). It compiles fine with jdk1.3 - but fails with jdk1.4. Regards, Chris --- [EMAIL PROTECTED] wrote: = ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS= = JAVA VERSION DETAILS java version 1.4.1_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01) Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [mkdir] Created dir: /home/jboss/jbossci/jboss-head/aop/output/lib [jar] Building jar: /home/jboss/jbossci/jboss-head/aop/output/lib/jboss-aop.jar == == == Finished 'most' in module 'aop'. == == _module-aop-most: [copy] Copying 1 file to /home/jboss/jbossci/jboss-head/build/output/testbuild/lib [copy] Copying 1 file to /home/jboss/jbossci/jboss-head/build/output/testbuild/lib == == == Executing 'most' in module 'cache'... == == configure-modules: Overriding previous definition of reference to jboss.naming.classpath compile-mbean-sources: [mkdir] Created dir: /home/jboss/jbossci/jboss-head/cache/output/gen/classes /home/jboss/jbossci/jboss-head/cache/src/main not found. at org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner(AbstractF ileSet.java:369) at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:61) at org.apache.tools.ant.Task.perform(Task.java:319) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:336) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.jboss.tools.buildmagic.task.Ant.execute(Ant.java:261) at org.jboss.tools.buildmagic.task.module.ExecuteModules$1.run(ExecuteModul es.java:329) at org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModule(Exec uteModules.java:342) at org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(ExecuteMod ules.java:217) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:166) at org.apache.tools.ant.Task.perform(Task.java:319) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:336) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.Project.executeTargets(Project.java:1250) at org.apache.tools.ant.Main.runBuild(Main.java:610) at org.apache.tools.ant.Main.start(Main.java:196) at org.apache.tools.ant.Main.main(Main.java:235) BUILD FAILED file:/home/jboss/jbossci/jboss-head/cache/build.xml:117: Unexpected error Total time: 48 seconds --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is
Re: [JBoss-dev] InitialContext ctx = new InitialContext(); in RMIConnectorImpl
Hi Stefan You just have to add the appropriate JAR file from the /client directory to you classpath that contains org.jnp.interfaces.NamingContextFactory which is left to the reader. Andy - Original Message - From: Stefan Groschupf [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, December 15, 2002 3:45 PM Subject: [JBoss-dev] InitialContext ctx = new InitialContext(); in RMIConnectorImpl Hi guys, I run in a problem with RMIConnectorImpl in the jmx/connector/rmi package. When I use the RMIConnetor in project I get a exception: javax.naming.NoInitialContextException: Cannot instantiate class: org.jnp.interfaces.NamingContextFactory. Root exception is java.lang.ClassNotFoundException: org.jnp.interfaces.NamingContextFactory That happens at line 578: InitialContext ctx = new InitialContext(); When I replace this lines with: NamingContextFactory f = new NamingContextFactory(); Context ctx = f.getInitialContext(System.getProperties()); Thank it looks like it working fine for me. Can somebody give me a hint, what I can do, instead create a custom jmx-connector package? Something like assign the RMIConnectorImpl my own Context? Thanks Stefan --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-654332 ] jsp:plugin name=x value=%=val%
Bugs item #654332, was opened at 2002-12-15 19:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=654332group_id=22866 Category: JBossWeb Group: v4.0 Status: Open Resolution: None Priority: 5 Submitted By: jeff dickenson (dickensonj) Assigned to: Nobody/Anonymous (nobody) Summary: jsp:plugin name=x value=%=val% Initial Comment: OS = Win2000 JDK Version 1.4.1 JBoss 3.0.4 with Tomcat 4.1.12 Issue: JSP calling java class The code generated for the following jsp:params block inside a jsp:plugin element: jsp:params jsp:param name=scp value=%= scp % / jsp:param name=demoMode value=%= demoMode % / jsp:param name=wsdlURL value=%= wsdlURL % / jsp:param name=wsProxy value=%= wsProxy % / /jsp:params does not use the *value* of the four variables but instead has 'value= scp', i.e. the *name* of the variable without double quotes. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=654332group_id=22866 --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-575966 ] JCA - commit failure not reported
Bugs item #575966, was opened at 2002-07-01 13:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=575966group_id=22866 Category: JBossTX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Paul Adams (padams) Assigned to: David Jencks (d_jencks) Summary: JCA - commit failure not reported Initial Comment: JBoss: 3.0 integrated with tomcat JDK: 1.4.0 OS: Win2K Connector deployed with LocalTransaction support. Failure to commit a transaction is not reported to the client. Logged stack trace below: 08:52:28,927 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257, GlobalId=padams//0, BranchQual=] errorCode=XA_UNKNOWN(0) javax.transaction.xa.XAException: could not commit local txjavax.resource.ResourceExceptio n: Server.InternalServerError:failure to commit at org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalConnectionEv entListener.commit(LocalTxConnectionManager.java:563) at org.jboss.tm.TxCapsule.commitResources(TxCapsule.java:1656) at org.jboss.tm.TxCapsule.commit(TxCapsule.java:357) at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:74) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.jav a:190) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166) at org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:380 ) at org.jboss.ejb.Container.invoke(Container.java:705) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:362) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.ja va:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:536) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=575966group_id=22866 --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-651476 ] scope in BaseManagedConnectionFactory
Bugs item #651476, was opened at 2002-12-10 15:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=651476group_id=22866 Category: JBossCX Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Bernd Zeitler (frito) Assigned to: David Jencks (d_jencks) Summary: scope in BaseManagedConnectionFactory Initial Comment: The method scope for getConnectionProperties(Subject, ConnectionRequestInfo) is protected but must be public or at least package scope because BaseWrapperManagedConnection tries to access the method of its member mcf which can be (or is) a BaseManagedConnectionFactory. javac should fail to compile, but build clean most doesn't even complain. When JBoss tries to access the method, the following error is produced: 15:35:26,176 WARN [ServiceController] Problem starting service jboss.mq:service=PersistenceManager java.lang.IllegalAccessError: tried to access method org.jboss.resource.adapter.jdbc.BaseWrapperManagedC onnectionFactory.getConnectionProperties (Ljavax/security/auth/Subject;Ljavax/resource/spi/Connec tionRequestInfo;)Ljava/util/Properties; from class org.jboss.resource.adapter.jdbc.BaseWrapperManagedC onnection at org.jboss.resource.adapter.jdbc.BaseWrapperManagedC onnection.checkIdentity (BaseWrapperManagedConnection.java:296) at org.jboss.resource.adapter.jdbc.BaseWrapperManagedC onnection.getConnection (BaseWrapperManagedConnection.java:189) at org.jboss.resource.connectionmanager.BaseConnection Manager2.allocateConnection (BaseConnectionManager2.java:596) at org.jboss.resource.connectionmanager.BaseConnection Manager2$ConnectionManagerProxy.allocateConnection (BaseConnectionManager2.java:885) at org.jboss.resource.adapter.jdbc.WrapperDataSource.get Connection(WrapperDataSource.java:102) at org.jboss.mq.pm.jdbc2.PersistenceManager.resolveAllUn commitedTXs(PersistenceManager.java:212) at org.jboss.mq.pm.jdbc2.PersistenceManager.startService (PersistenceManager.java:1089) at org.jboss.system.ServiceMBeanSupport.start (ServiceMBeanSupport.java:197) at sun.reflect.GeneratedMethodAccessor42.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invok e(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:549) at org.jboss.system.ServiceController$ServiceProxy.invoke (ServiceController.java:962) at $Proxy9.start(Unknown Source) at org.jboss.system.ServiceController.start (ServiceController.java:388) at org.jboss.system.ServiceController.start (ServiceController.java:404) at sun.reflect.GeneratedMethodAccessor11.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invok e(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:549) at org.jboss.util.jmx.MBeanProxy.invoke (MBeanProxy.java:174) at $Proxy5.start(Unknown Source) at org.jboss.deployment.SARDeployer.start (SARDeployer.java:307) at org.jboss.deployment.MainDeployer.start (MainDeployer.java:818) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:630) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:594) at sun.reflect.GeneratedMethodAccessor30.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invok e(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:549) at org.jboss.util.jmx.MBeanProxy.invoke (MBeanProxy.java:174) at $Proxy7.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner. deploy(URLDeploymentScanner.java:400) at org.jboss.deployment.scanner.URLDeploymentScanner. scanDirectory(URLDeploymentScanner.java:619) at org.jboss.deployment.scanner.URLDeploymentScanner. scan(URLDeploymentScanner.java:472) at org.jboss.deployment.scanner.AbstractDeploymentScan ner$ScannerThread.doScan (AbstractDeploymentScanner.java:195) at org.jboss.deployment.scanner.AbstractDeploymentScan ner.startService(AbstractDeploymentScanner.java:268) at org.jboss.system.ServiceMBeanSupport.start (ServiceMBeanSupport.java:197) at sun.reflect.GeneratedMethodAccessor12.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke
[JBoss-dev] [ jboss-Bugs-648631 ] Wrapped JDBC driver deployment fails
Bugs item #648631, was opened at 2002-12-04 21:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=648631group_id=22866 Category: JBossCX Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Patrick Murphy (murphyp1) Assigned to: David Jencks (d_jencks) Summary: Wrapped JDBC driver deployment fails Initial Comment: When deploying a wrapped JDBC driver with a opta-xa- service.xml file, the RARDeployment fails with a org.jboss.deployment.DeploymentException: expected one config-property-value tag exception. I am using the default configuration and have placed the Opta2000.jar file in the lib directory. I am attaching the opta-xa-service.xml file that I have written. The JBoss Release ID: JBoss [WonderLand] 3.2.0RC1 (build: CVSTag=JBoss_3_2_0_beta2 date=200212021314) running on Windows2000 with Java VM: Java HotSpot (TM) Client VM 1.4.1_01-b01,Sun Microsystems Inc. The exception trace is: 2002-12-04 15:43:09,000 INFO [org.jboss.deployment.MainDeployer] Starting deployment of package: file:/C:/bin/jboss/server/default/deploy/opta-xa- service.xml 2002-12-04 15:43:09,000 INFO [org.jboss.deployment.SARDeployer] looking for nested deployments in : file:/C:/bin/jboss/server/default/deploy/opta-xa- service.xml 2002-12-04 15:43:09,031 DEBUG [org.jboss.resource.connectionmanager.RARDeployment ] setManagedConnectionFactoryProperties 2002-12-04 15:43:09,046 INFO [org.jboss.resource.connectionmanager.RARDeployment ] Creating 2002-12-04 15:43:09,046 INFO [org.jboss.resource.connectionmanager.RARDeployment ] Created 2002-12-04 15:43:09,046 INFO [org.jboss.resource.connectionmanager.JBossManagedC onnectionPool] Creating 2002-12-04 15:43:09,046 INFO [org.jboss.resource.connectionmanager.JBossManagedC onnectionPool] Created 2002-12-04 15:43:09,046 INFO [org.jboss.resource.connectionmanager.XATxConnection Manager] Creating 2002-12-04 15:43:09,046 INFO [org.jboss.resource.connectionmanager.XATxConnection Manager] Created 2002-12-04 15:43:09,062 INFO [org.jboss.resource.connectionmanager.RARDeployment ] Starting 2002-12-04 15:43:09,062 DEBUG [org.jboss.resource.connectionmanager.RARDeployment ] setManagedConnectionFactoryClass org.jboss.resource.adapter.jdbc.xa.XAManagedConnecti onFactory 2002-12-04 15:43:09,062 DEBUG [org.jboss.resource.connectionmanager.RARDeployment ] setMcfProperties oldRarDeployment.ResourceAdapterElement 2002-12-04 15:43:09,078 DEBUG [org.jboss.resource.connectionmanager.RARDeployment ] config-property-name=UserName 2002-12-04 15:43:09,078 ERROR [org.jboss.resource.connectionmanager.RARDeployment ] Starting failed org.jboss.deployment.DeploymentException: expected one config-property-value tag at org.jboss.metadata.MetaData.getUniqueChild (MetaData.java:95) at org.jboss.resource.connectionmanager.RARDeployment. setMcfProperties(RARDeployment.java:697) at org.jboss.resource.connectionmanager.RARDeployment. startService(RARDeployment.java:549) at org.jboss.system.ServiceMBeanSupport.start (ServiceMBeanSupport.java:197) at sun.reflect.GeneratedMethodAccessor34.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invok e(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:549) at org.jboss.system.ServiceController$ServiceProxy.invoke (ServiceController.java:953) at $Proxy9.start(Unknown Source) at org.jboss.system.ServiceController.start (ServiceController.java:388) at sun.reflect.GeneratedMethodAccessor10.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invok e(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:549) at org.jboss.util.jmx.MBeanProxy.invoke (MBeanProxy.java:174) at $Proxy5.start(Unknown Source) at org.jboss.deployment.SARDeployer.start (SARDeployer.java:307) at org.jboss.deployment.MainDeployer.start (MainDeployer.java:818) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:630) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:594) at sun.reflect.GeneratedMethodAccessor27.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invok e(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:549)
[JBoss-dev] [ jboss-Bugs-618908 ] NSME from trunk.client.ConnectionManager
Bugs item #618908, was opened at 2002-10-05 12:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=618908group_id=22866 Category: JBossServer Group: v4.0 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Frank Langelage (lafr) Assigned to: David Jencks (d_jencks) Summary: NSME from trunk.client.ConnectionManager Initial Comment: OS Linux, JDK 1.4.1 on startup of a fresh checked out an compiled JBoss-4.0 I get an error message with a NoSuchMethodException. server/src/main/org/jboss/invocation/trunk/client/ConnectionManager.java tries to call method setMaxSize in connector/src/main/org/jboss/resource/work/BaseWorkManager.java. But there is only a setMaxThreads ! May be this should be called from ConnectionManager or something is missing in BaseWorkManager. -- Comment By: David Jencks (d_jencks) Date: 2002-12-16 05:18 Message: Logged In: YES user_id=60525 The relevant code is now in org.jboss.invocation.trunk.client.ClientSetup, and it correctly sets MaxThreads. Wonder how this one got through my testing... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=618908group_id=22866 --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] deployment scripts + extending Configuration of JBossSX on the fly
Sorry if I messed up the JBossMQ JAAS stuf; I could no figure out a
generic way to specify what MBean to invoke from a loginmodule.
The on-the-fly-security configuration you are asking for is however
possible to solve in more that one way. I tried the aproach of Scott a
while ago, but did not like it since it does not handle undordered
redeploys. So I ripes some parsing code from XMLLoginConfig and used its
MBean API. Heres the Mbean I use personally to on-the-fly-configure JCA
RA JAAS Security.
package org.jboss.resource.security;
import java.util.ArrayList;
import java.util.HashMap;
import javax.management.ObjectName;
import javax.security.auth.login.AppConfigurationEntry;
import javax.security.auth.login.AppConfigurationEntry.LoginModuleControlFlag;
import org.w3c.dom.Node;
import org.w3c.dom.Element;
import org.w3c.dom.NodeList;
import org.jboss.system.ServiceMBeanSupport;
import org.jboss.security.auth.login.XMLLoginConfigMBean;
import org.jboss.security.auth.login.AuthenticationInfo;
import org.jboss.util.jmx.MBeanProxy;
/**
* Add a security domain dynamically.
*
* pThrough this MBean you may add new security domains (LoginModules) to JBoss
dynamically. Just configure the MBean and deploy it and you will have a new
LoginConfigurations without having to restart the server.Configure it by setting the
MBean Attribute AuthConfig with the application-policy xml you would normally stuff
into login-config.xml./p
*
* pHere is an example:/p
prelt;servergt;
lt;!--new configuration for new ConnectionManager--gt;
lt;mbean code=org.jboss.resource.security.LoginConfigurator
name=jboss.jca:service=AuthenticationInfo,name=Usergt;
lt;depends
optional-attribute-name=LoginConfiggt;jboss.security:service=XMLLoginConfiglt;/dependsgt;
lt;attribute name=AuthConfiggt;
lt;application-policy name = usergt;
lt;authenticationgt;
lt;login-module code =org.jboss.security.auth.spi.LdapLoginModule flag =
requiredgt;
lt;module-option name =
unauthenticatedIdentitygt;nobodylt;/module-optiongt;
lt;module-option name =
java.naming.factory.initialgt;se.tim.jndi.ChainedCtxFactorylt;/module-optiongt;
lt;module-option name = principalDNPrefixgt;uid=lt;/module-optiongt;
lt;module-option name =
principalDNSuffixgt;,ou=People,dc=tim,dc=selt;/module-optiongt;
lt;module-option name =
uidAttributeIDgt;uniquememberlt;/module-optiongt;
lt;module-option name = roleAttributeIDgt;cnlt;/module-optiongt;
lt;module-option name = matchOnUserDNgt;truelt;/module-optiongt;
lt;module-option name = rolesCtxDNgt;ou=Groupslt;/module-optiongt;
lt;module-option name =
java.naming.provider.urlgt;ldap://pra.tim.se/dc=tim,dc=selt;/module-optiongt;
lt;module-option name =
java.naming.security.authenticationgt;simplelt;/module-optiongt;
lt;module-option name =
java.naming.security.principalgt;cn=Manager,dc=tim,dc=selt;/module-optiongt;
lt;module-option name =
java.naming.security.credentialsgt;PWDlt;/module-optiongt;
lt;module-option name =
se.tim.jndi.chained.classesgt;se.tim.jndi.dsml.DSMLInterceptorlt;/module-optiongt;
lt;module-option name =
se.tim.jndi.factory.initialgt;com.sun.jndi.ldap.LdapCtxFactorylt;/module-optiongt;
lt;module-option name =
se.tim.jndi.dsml.pmgt;se.tim.jndi.dsml.FilePMlt;/module-optiongt;
lt;/login-modulegt;
lt;/authenticationgt;
lt;/application-policygt;
lt;/attributegt;
lt;/mbeangt;
lt;/servergt;
/pre
*
* @author a href=mailto:[EMAIL PROTECTED];Peter Antman/a
* @version $Revision: 1.1 $
* @jmx:mbean name=jboss.jca:service=LoginConfigurator
extends=org.jboss.system.ServiceMBean
*/
public class LoginConfigurator
extends ServiceMBeanSupport
implements LoginConfiguratorMBean{
ObjectName loginConfig;
Element authConfig;
/**
* @jmx:managed-attribute
*/
public ObjectName getLoginConfig() {
return loginConfig;
}
/**
* @jmx:managed-attribute
*/
public void setLoginConfig(ObjectName loginConfig) {
this.loginConfig = loginConfig;
}
/**
* @jmx:managed-attribute
*/
public void setAuthConfig(Element authConfig) {
this.authConfig = authConfig;
}
/**
* @jmx:managed-attribute
*/
public Element getAuthConfig() {
return authConfig;
}
public void startService() throws Exception
{
// Check sanity
if ( loginConfig == null) {
throw new Exception(No LoginConfig MBean configured!);
} // end of if ()
if ( authConfig == null) {
throw new Exception(No authentication config set);
} // end of if ()
log.info(Config + authConfig.getNodeName());
if ( !application-policy.equals(authConfig.getNodeName()) ) {
throw new Exception(Autehntication config is not an application policy);
} // end of if ()
// DO IT
