Re: Error formatting macro: snippet
Daniel,
Thank you for clarifying this. Some of our pages have the entire url
specified in the snippet macro, that's why it doesn't work. Now we know
how to solve it...
Gert
Daniel Kulp wrote:
I just checked the confluence snippet macro config and it looks ok. It
has a mapping of:
prefix: servicemix/
to url: http://svn.apache.org/repos/asf/incubator/servicemix/
Thus, on your page, it should just be:
{snippet:id=expression|lang=xml|
url=servicemix/trunk/common/servicemix-components/src/test/resources/org/apache/servicemix/components/net/ftp.xml}
Dan
On Tuesday 10 July 2007 10:25, Gert Vanthienen wrote:
L.S.,
Some of our documentation pages use Confluence's snippet macro to
include code sample (e.g.
http://incubator.apache.org/servicemix/ftp.html). Currently, this
macro doesn't seem to work any more:
Error formatting macro: snippet:
java.lang.IllegalArgumentException: Invalid url: must begin with a
configured prefix.
We're not alone, apparently the Struts team has the same problem (e.g.
http://struts.apache.org/2.0.5/docs/conversion-validator.html). A
quick search on the web seems to indicate that this is some kind of
confguration problem with the snippet macro. Who can administer the
Confluence instance that hosts our website to resolve this issue?
Gert
[jira] Created: (SM-997) Basic example fails to build: InvalidProjectModelException
Basic example fails to build: InvalidProjectModelException -- Key: SM-997 URL: https://issues.apache.org/activemq/browse/SM-997 Project: ServiceMix Issue Type: Bug Components: servicemix-assembly Affects Versions: 3.1.1 Environment: Servicemix 3.1.1-incubating, Windows XP, Java 1.5.0_12, Maven 2.0.6 Reporter: Evan Deaubl When I attempt to run either mvn install, or mvn jbi:embeddedServicemix on the project in examples/basic, I receive the following error. I have completely removed my Maven repository and had it redownload everything from scratch, and still received this error. I manually checked the file it had downloaded, and the XML file was indeed invalid, and downloading the file directly from the source (http://people.apache.org/repo/m2-incubating-repository/org/apache/servicemix/servicemix/3.1.1-incubating/servicemix-3.1.1-incubating.pom) using Firefox yields an XML Parsing Error. [INFO] Scanning for projects... Downloading: http://people.apache.org/repo/m2-incubating-repository/org/apache/servicemix/samples/3.1.1-incubating/samples-3.1.1-incubating.pom 2K downloaded Downloading: http://people.apache.org/repo/m2-incubating-repository/org/apache/servicemix/servicemix/3.1.1-incubating/servicemix-3.1.1-incubating.pom 69K downloaded [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = '507906935d130cfa9b44696270f62e006367533d'; remote = 'a79a1012430e34db6e471c444f0dd77c28be9d0e' - RETRYING Downloading: http://people.apache.org/repo/m2-incubating-repository/org/apache/servicemix/servicemix/3.1.1-incubating/servicemix-3.1.1-incubating.pom 69K downloaded [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = '507906935d130cfa9b44696270f62e006367533d'; remote = 'a79a1012430e34db6e471c444f0dd77c28be9d0e' - IGNORING [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.servicemix:samples:pom:null Reason: Cannot find parent: org.apache.servicemix:servicemix for project: org.apache.servicemix:samples:pom:null [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.servicemix:servicemix for project: org.apache.servicemix:samples:pom:null at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.servicemix:servicemix for project: org.apache.servicemix:samples:pom:null at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1264) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1281) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:749) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:479) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:537) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:467) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:364) ... 11 more Caused by: org.apache.maven.project.InvalidProjectModelException: Parse error reading POM. Reason: end tag name /exclusion must match start tag name dependency from line 819 (position: TEXT seen ...dependency\n /exclusion... @820:18) at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1423) at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1380) at
RE: checkstyle on the se-archectype
While trying to build from the source from the trunk.. Meven 2 JBI Plugin failed fo me ith check style errors.. GraphArtifactCollector.java:58:37: More than 7 parameters JbiComponentDescriptorWriter.java:37:15: More than 7 parameters Do you have the same errors? Regards, Rabi Mishra http://rabisblog.blogspot.com/ From: [EMAIL PROTECTED] on behalf of Brian O'Neill Sent: Tue 7/10/2007 11:52 PM To: servicemix-dev@geronimo.apache.org Subject: checkstyle on the se-archectype Following the se tutorial: http://incubator.apache.org/servicemix/hello-world-se.html The code produced from the mvn archetype failed the checkstyle check (with errors). Has anyone else experienced this? (I also had to go in and update the version in the pom.xml, so it would pull a current release of sm) -brian -- Brian ONeill Source Equity (http://www.sourceequity.com http://www.sourceequity.com/ ) jBIZint (http://www.jbizint.org http://www.jbizint.org/ ) Technical Architect, Gestalt LLC (http://www.gestalt-llc.com http://www.gestalt-llc.com/ ) mobile:215.588.6024 The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
Re: checkstyle on the se-archectype
Unfortunately those are different errors, because I'm getting them in the code generated by the maven archetype. After fixing the checkstyle errors, I had to fix a couple PMD errors. Now, I'm on to making the test pass, which is generating: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jbi' defined in class path resource [spring.xml]: Invocation of init method failed; nested exception is java.lang.NoSuchMethodError: org.springframework.jmx.support.ConnectorServerFactoryBean.setObjectName(Ljava/lang/String;)V I'm guessing this is a spring version problem. Trying to track it down now. -brian On 7/10/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: While trying to build from the source from the trunk.. Meven 2 JBI Plugin failed fo me ith check style errors.. GraphArtifactCollector.java:58:37: More than 7 parameters JbiComponentDescriptorWriter.java:37:15: More than 7 parameters Do you have the same errors? Regards, Rabi Mishra http://rabisblog.blogspot.com/ From: [EMAIL PROTECTED] on behalf of Brian O'Neill Sent: Tue 7/10/2007 11:52 PM To: servicemix-dev@geronimo.apache.org Subject: checkstyle on the se-archectype Following the se tutorial: http://incubator.apache.org/servicemix/hello-world-se.html The code produced from the mvn archetype failed the checkstyle check (with errors). Has anyone else experienced this? (I also had to go in and update the version in the pom.xml, so it would pull a current release of sm) -brian -- Brian ONeill Source Equity (http://www.sourceequity.com http://www.sourceequity.com/ ) jBIZint (http://www.jbizint.org http://www.jbizint.org/ ) Technical Architect, Gestalt LLC (http://www.gestalt-llc.com http://www.gestalt-llc.com/ ) mobile:215.588.6024 The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -- Brian ONeill Source Equity (http://www.sourceequity.com) jBIZint (http://www.jbizint.org) Technical Architect, Gestalt LLC (http://www.gestalt-llc.com) mobile:215.588.6024
[jira] Created: (SM-998) In-Out Exchanges in a JMS queue cannot be successfully processed after a crash/shutdown
In-Out Exchanges in a JMS queue cannot be successfully processed after a crash/shutdown --- Key: SM-998 URL: https://issues.apache.org/activemq/browse/SM-998 Project: ServiceMix Issue Type: Bug Components: servicemix-jms Affects Versions: 3.1.2 Environment: any Reporter: Sam Gerstein Fix For: 3.1.2 Attachments: servicemix-jms_patch.txt Because a temporary queue is used for the reply-to destination and the Exchange is stored in an in-memory Map, In-Out message exchanges in a JMS queue cannot be returned to their sender after a crash or shutdown of ServiceMix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (SM-998) In-Out Exchanges in a JMS queue cannot be successfully processed after a crash/shutdown
I meant to add a comment here- I've only fixed StandardProviderProcessor, MultiplexingProviderProcessor, and StandardConsumerProcessor. MultiplexingConsumerProcessor is a bit more complicated and I unfortunately don't have time for it right now. I tested with mySQL and the jdbcStore, which worked fine except that the size of the id column that the Store created was too small for the exchange ID.. I suppose it should just be bigger by default, and I haven't fixed that yet. -Sam JIRA [EMAIL PROTECTED] wrote: In-Out Exchanges in a JMS queue cannot be successfully processed after a crash/shutdown --- Key: SM-998 URL: https://issues.apache.org/activemq/browse/SM-998 Project: ServiceMix Issue Type: Bug Components: servicemix-jms Affects Versions: 3.1.2 Environment: any Reporter: Sam Gerstein Fix For: 3.1.2 Attachments: servicemix-jms_patch.txt Because a temporary queue is used for the reply-to destination and the Exchange is stored in an in-memory Map, In-Out message exchanges in a JMS queue cannot be returned to their sender after a crash or shutdown of ServiceMix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- View this message in context: http://www.nabble.com/-jira--Created%3A-%28SM-998%29-In-Out-Exchanges-in-a-JMS-queue-cannot-be-successfully-processed-after-a-crash-shutdown-tf4058643s12049.html#a11530104 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
[jira] Created: (SM-999) InOut to InOnly pattern Endpoint for eip-su
InOut to InOnly pattern Endpoint for eip-su --- Key: SM-999 URL: https://issues.apache.org/activemq/browse/SM-999 Project: ServiceMix Issue Type: Improvement Components: servicemix-eip Reporter: Netflexity Please add the following pattern to be able to use components that support only InOnly MEPs for InOut components. Attached file illustrates the idea. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Build Failure
Hi All,
I am getting following compilation error while building the latest
source code.
Thanks,
Lasantha Ranaweera
[INFO]
[INFO] Building Geronimo :: OpenEJB
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/target
[INFO] Deleting directory
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/target/classes
[INFO] Deleting directory
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/target/test-classes
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/target/classes/META-INF
[INFO] Copying 2 files to
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 21 source files to
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/target/classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenejbRemoteLoginModule.java:[70,45]
directAuthentication(java.lang.String,java.lang.String,org.apache.openejb.client.ServerMetaData)
in org.apache.openejb.client.ClientSecurity cannot be applied to
(java.lang.String,java.lang.String,java.lang.String,org.apache.openejb.client.ServerMetaData)
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenejbRemoteLoginModule.java:[70,45]
directAuthentication(java.lang.String,java.lang.String,org.apache.openejb.client.ServerMetaData)
in org.apache.openejb.client.ClientSecurity cannot be applied to
(java.lang.String,java.lang.String,java.lang.String,org.apache.openejb.client.ServerMetaData)
Re: Build Failure
Ran into the same problem at rev 554886.
Vamsi
On 7/10/07, Lasantha Ranaweera [EMAIL PROTECTED] wrote:
Hi All,
I am getting following compilation error while building the latest
source code.
Thanks,
Lasantha Ranaweera
[INFO]
[INFO] Building Geronimo :: OpenEJB
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/target
[INFO] Deleting directory
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/target/classes
[INFO] Deleting directory
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/target/test-classes
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/target/classes/META-INF
[INFO] Copying 2 files to
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 21 source files to
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/target/classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenejbRemoteLoginModule.java:[70,45]
directAuthentication(java.lang.String,java.lang.String,
org.apache.openejb.client.ServerMetaData)
in org.apache.openejb.client.ClientSecurity cannot be applied to
(java.lang.String,java.lang.String,java.lang.String,
org.apache.openejb.client.ServerMetaData)
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenejbRemoteLoginModule.java:[70,45]
directAuthentication(java.lang.String,java.lang.String,
org.apache.openejb.client.ServerMetaData)
in org.apache.openejb.client.ClientSecurity cannot be applied to
(java.lang.String,java.lang.String,java.lang.String,
org.apache.openejb.client.ServerMetaData)
Re: Build Failure
I built the latest OpenEJB code locally and then Geronimo Rev554771 without
any problems
-Donald
Vamsavardhana Reddy wrote:
Ran into the same problem at rev 554886.
Vamsi
On 7/10/07, *Lasantha Ranaweera* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi All,
I am getting following compilation error while building the latest
source code.
Thanks,
Lasantha Ranaweera
[INFO]
[INFO] Building Geronimo :: OpenEJB
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/target
[INFO] Deleting directory
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/target/classes
[INFO] Deleting directory
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/target/test-classes
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/target/classes/META-INF
[INFO] Copying 2 files to
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 21 source files to
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/target/classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenejbRemoteLoginModule.java:[70,45]
directAuthentication(java.lang.String,java.lang.String,org.apache.openejb.client.ServerMetaData)
in org.apache.openejb.client.ClientSecurity cannot be applied to
(java.lang.String,java.lang.String,java.lang.String
,org.apache.openejb.client.ServerMetaData)
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenejbRemoteLoginModule.java:[70,45]
directAuthentication(
java.lang.String,java.lang.String,org.apache.openejb.client.ServerMetaData)
in org.apache.openejb.client.ClientSecurity cannot be applied to
(java.lang.String,java.lang.String,java.lang.String,org.apache.openejb.client.ServerMetaData
)
smime.p7s
Description: S/MIME Cryptographic Signature
[jira] Created: (GERONIMODEVTOOLS-174) Distribution of configuration failed when attempting to deploy using Geronimo 2.0 adapter
Distribution of configuration failed when attempting to deploy using Geronimo 2.0 adapter --- Key: GERONIMODEVTOOLS-174 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-174 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Tom Mutdosch Using the following Geronimo 2.0 runtime server and adapter: (*) Server: http://people.apache.org/dist/geronimo/eclipse/unstable/servers/geronimo-tomcat6-jee5-2.0-SNAPSHOT-bin.zip (*)Server plugins: http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-2.0.0-v20070621.1204-deployable.zip Using eclipse WTP, I create a simple Dynamic Web Project targeting Geronimo with a single HTML file. When I do a Run on Server I get the following error in an error dialog and my page does not run. Error: Distribution of configuration failed. See log for details. Cannot deploy the requested application module because no deployer is able to handle it. This can happen if you have omitted the J2EE deployment descriptor, disabled a deployer module, or if, for example, you are trying to deploy an EJB module on a minimal Geronimo server that does not have EJB support installed. (moduleFile=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\geronimo-deployer1127.tmpdir\geronimoTestEAR.zip) org.apache.geronimo.common.DeploymentException: Cannot deploy the requested application module because no deployer is able to handle it. This can happen if you have omitted the J2EE deployment descriptor, disabled a deployer module, or if, for example, you are trying to deploy an EJB module on a minimal Geronimo server that does not have EJB support installed. (moduleFile=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\geronimo-deployer1127.tmpdir\geronimoTestEAR.zip) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:239) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:863) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:863) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:168) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:231) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:238) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:833) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:802) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1423) at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:96) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1260) at java.security.AccessController.doPrivileged(AccessController.java:275) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1363) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:797) at sun.reflect.GeneratedMethodAccessor193.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309) at sun.rmi.transport.Transport$1.run(Transport.java:168) at java.security.AccessController.doPrivileged(AccessController.java:275) at sun.rmi.transport.Transport.serviceCall(Transport.java:164) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912) at java.lang.Thread.run(Thread.java:801) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE] Release specs for Activation and StAX - rc2
The activation and stax specs had almost passed the vote the first time around. It got dinged on missing scm section in the poms. I have fixed it now and am resubmitting them for a vote. Please review the specifications located at http://people.apache.org/~prasad/specs_rc2/ Voting concludes on Monday, July 13th at 1000 ET. The other outstanding specs (depending on servlet) that would be released together are servlet_2.5_spec-1.1 jsp_2.1_spec-1.0 jacc_1.1_spec-1.0 Cheers Prasad
[jira] Commented: (GERONIMODEVTOOLS-174) Distribution of configuration failed when attempting to deploy using Geronimo 2.0 adapter
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511449 ] Jacek Laskowski commented on GERONIMODEVTOOLS-174: -- It looks strange. See what file was to have been deployed - moduleFile=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\geronimo-deployer1127.tmpdir\geronimoTestEAR.zip. What Eclipse version do you use? Is it Eclipse IDE 3.3? I gave it a shot and could easily reproduce it. Zip file is deployed but Geronimo can't recognize it as a known file type. It seems like a bug in WTP. I'm using wtp-R-2.0-200706260303. Distribution of configuration failed when attempting to deploy using Geronimo 2.0 adapter --- Key: GERONIMODEVTOOLS-174 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-174 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Tom Mutdosch Using the following Geronimo 2.0 runtime server and adapter: (*) Server: http://people.apache.org/dist/geronimo/eclipse/unstable/servers/geronimo-tomcat6-jee5-2.0-SNAPSHOT-bin.zip (*)Server plugins: http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-2.0.0-v20070621.1204-deployable.zip Using eclipse WTP, I create a simple Dynamic Web Project targeting Geronimo with a single HTML file. When I do a Run on Server I get the following error in an error dialog and my page does not run. Error: Distribution of configuration failed. See log for details. Cannot deploy the requested application module because no deployer is able to handle it. This can happen if you have omitted the J2EE deployment descriptor, disabled a deployer module, or if, for example, you are trying to deploy an EJB module on a minimal Geronimo server that does not have EJB support installed. (moduleFile=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\geronimo-deployer1127.tmpdir\geronimoTestEAR.zip) org.apache.geronimo.common.DeploymentException: Cannot deploy the requested application module because no deployer is able to handle it. This can happen if you have omitted the J2EE deployment descriptor, disabled a deployer module, or if, for example, you are trying to deploy an EJB module on a minimal Geronimo server that does not have EJB support installed. (moduleFile=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\geronimo-deployer1127.tmpdir\geronimoTestEAR.zip) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:239) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:863) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:863) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:168) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:231) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:238) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:833) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:802) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1423) at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:96) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1260) at java.security.AccessController.doPrivileged(AccessController.java:275) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1363) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:797) at sun.reflect.GeneratedMethodAccessor193.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at
[jira] Closed: (GERONIMO-3273) Tomcat MBeans not getting registered with MBeanServer created by Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-3273. - Resolution: Fixed A tomcat fix is not necessary as reported earlier. Completed: At revision: 554952 in trunk. Tomcat MBeans not getting registered with MBeanServer created by Geronimo - Key: GERONIMO-3273 URL: https://issues.apache.org/jira/browse/GERONIMO-3273 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0-M7 Environment: Geronimo Tomcat 2.0-SNAPSHOT Reporter: Vamsavardhana Reddy Fix For: 2.0-M7 When a new JMX Service is configured as given in http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html, Tomcat MBeans are not getting registered with the MBeanServer created by Geronimo. Due to this, Tomcat MBeans are not available through the JMX Service provided by Geronimo. A fix for this may not be possible until the tomcat issue http://issues.apache.org/bugzilla/show_bug.cgi?id=42759 is addressed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: More problems exporting a plugin and importing into minimal assembly
On 7/8/07, David Jencks [EMAIL PROTECTED] wrote: One obvious problem here is that the plugin installation is trying to use the geronimo-transaction-jta11 module which doesn't exist any more. Trying the link http://geronimo.apache.org/plugins/geronimo-2.0/repository/indicates the apache snapshot repo is being used... which makes me think that perhaps the problem is that no recent snapshots for geronimo have been deployed? Sorry for my confusion, but is this something we (all the geronimo developers) have agreed to do after every change? Is there an automated process for it? IIUC the openejb project has been pretty good at pushing new snapshots after most changes... I'd rather have something automatic but a clear policy might be adequate (especially since I'm not about to try to set up an automated build) I'm trying to get publish snapshots on a daily basis as a part of the automated builds. I've had problem with it in the configs modules. Hopefully we should be able to get this to work. http://www.nabble.com/-BUILD--TRUNK%3A-Failed-for-Revision%3A-550730-tf3981354s134.html#a11302476 Cheers Prasad. Something that might help since you appear to have done a local build, is to add your local maven repo to the plugin repo list. I think you also have to add a plugins.xml file there, perhaps we could find a way to automatically install some reasonable default copy? Or maybe for local repos have the plugin system scan the repo? thanks david jencks On Jul 7, 2007, at 10:49 PM, Ajay Panagariya wrote: Hi, I just checked out the current trunk, and deployed the minimal tomcat assembly. I exported it from the regular assembly and tried importing it into the minimal, here's the output of that operation (followed by my geronimo-plugin.xml file). I asked a similar question one or two days ago, and all had gone well, but that was on an older build. This install is using the latest trunk. If posting the output in geonimo.log would help, I will be happy to provide that as well. Thanks ahead of time. $ target/geronimo-tomcat6-minimal-2.0-SNAPSHOT/bin/deploy.bat install-plugin amq.car Using GERONIMO_BASE: C:\g5\target\geronimo-tomcat6-minimal-2.0-SNAPSHOT Using GERONIMO_HOME: C:\g5\target\geronimo- tomcat6-minimal-2.0-SNAPSHOT Using GERONIMO_TMPDIR: var\temp Using JRE_HOME:C:\Program Files\Java\jdk1.5.0_12\jre Checking for status every 1000ms: Searching for org.apache.geronimo.configs/system-database//car at http://geronimo.apache.org/plugins/geronimo-2.0/repository/ Downloading org.apache.geronimo.configs/system-database/2.0-SNAPSHOT/car... (9%) Downloading org.apache.derby/derby/10.2.2.0/jar... Downloading org.apache.derby/derby/10.2.2.0/jar... (4%) Downloading org.apache.derby/derby/10.2.2.0/jar... (11%) Downloading org.apache.derby/derby/10.2.2.0/jar... (19%) Downloading org.apache.derby/derby/10.2.2.0/jar... (26%) Downloading org.apache.derby/derby/10.2.2.0/jar... (34%) Downloading org.apache.derby/derby/10.2.2.0/jar... (42%) Downloading org.apache.derby/derby/10.2.2.0/jar... (48%) Downloading org.apache.derby/derby/10.2.2.0/jar... (56%) Downloading org.apache.derby/derby/10.2.2.0/jar... (64%) Downloading org.apache.derby/derby/10.2.2.0/jar... (69%) Downloading org.apache.derby/derby/10.2.2.0/jar... (75%) Downloading org.apache.derby/derby/10.2.2.0/jar... (83%) Downloading org.apache.derby/derby/10.2.2.0/jar... (90%) Downloading org.apache.derby/derby/10.2.2.0/jar... (93%) Searching for org.apache.geronimo.configs /transaction-jta11//car at http://geronimo.apache.org/plugins/geronimo-2.0/repository/ Searching for org.apache.geronimo.modules/geronimo-transaction-jta11/2.0-SNAPSHOT/jar at http://geronimo.apache.org/plugins/geroni mo-2.0/repository/ Searching for org.apache.geronimo.modules/geronimo-derby/2.0-SNAPSHOT/jar at http://geronimo.apache.org/plugins/geronimo-2.0/repos itory/ Downloading org.apache.geronimo.modules/geronimo-derby/2.0-SNAPSHOT/jar... Downloading org.apache.derby/derbyclient/10.2.2.0/jar... Downloading org.apache.derby/derbyclient/10.2.2.0/jar... (24%) Downloading org.apache.derby/derbyclient/10.2.2.0/jar... (50%) Downloading org.apache.derby/derbyclient/10.2.2.0/jar... (71%) Searching for org.apache.geronimo.modules /geronimo-timer/2.0-SNAPSHOT/jar at http://geronimo.apache.org/plugins/geronimo-2.0/repos itory/ Downloading org.apache.geronimo.modules/geronimo-timer/2.0-SNAPSHOT/jar... (26%) Downloading org.apache.derby/derbynet/10.2.2.0/jar... Downloading org.apache.derby/derbynet/10.2.2.0/jar... (17%) Downloading org.apache.derby/derbynet/10.2.2.0/jar... (77%) Searching for org.apache.geronimo.modules /geronimo-activemq/2.0-SNAPSHOT/jar at http://geronimo.apache.org/plugins/geronimo-2.0/re pository/ Downloading org.apache.geronimo.modules/geronimo-activemq/2.0-SNAPSHOT/jar... (25%) Searching for org.apache.geronimo.modules/geronimo-activemq-management/2.0-SNAPSHOT/jar at http://geronimo.apache.org/plugins/gero nimo-2.0/repository/ Downloading
Re: Build Failure
Using the published openejb artifacts will give this problem. Build
openejb locally to get around this. Hopefully somebody from openejb
will publish new snaps soon.
Cross-posting to openejb dev list for their attention.
Cheers
Prasad
On 7/10/07, Lasantha Ranaweera [EMAIL PROTECTED] wrote:
Hi All,
I am getting following compilation error while building the latest
source code.
Thanks,
Lasantha Ranaweera
[INFO]
[INFO] Building Geronimo :: OpenEJB
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/target
[INFO] Deleting directory
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/target/classes
[INFO] Deleting directory
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/target/test-classes
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/target/classes/META-INF
[INFO] Copying 2 files to
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 21 source files to
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/target/classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenejbRemoteLoginModule.java:[70,45]
directAuthentication(java.lang.String,java.lang.String,org.apache.openejb.client.ServerMetaData)
in org.apache.openejb.client.ClientSecurity cannot be applied to
(java.lang.String,java.lang.String,java.lang.String,org.apache.openejb.client.ServerMetaData)
/home/hd2/work/geronimo/trunk/my-workspace/my-server/modules/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenejbRemoteLoginModule.java:[70,45]
directAuthentication(java.lang.String,java.lang.String,org.apache.openejb.client.ServerMetaData)
in org.apache.openejb.client.ClientSecurity cannot be applied to
(java.lang.String,java.lang.String,java.lang.String,org.apache.openejb.client.ServerMetaData)
Error formatting macro: snippet
L.S., Some of our documentation pages use Confluence's snippet macro to include code sample (e.g. http://incubator.apache.org/servicemix/ftp.html). Currently, this macro doesn't seem to work any more: Error formatting macro: snippet: java.lang.IllegalArgumentException: Invalid url: must begin with a configured prefix. We're not alone, apparently the Struts team has the same problem (e.g. http://struts.apache.org/2.0.5/docs/conversion-validator.html). A quick search on the web seems to indicate that this is some kind of confguration problem with the snippet macro. Who can administer the Confluence instance that hosts our website to resolve this issue? Gert
[jira] Created: (GERONIMO-3304) ability to update openejb-jar.xml by examining annotations
ability to update openejb-jar.xml by examining annotations -- Key: GERONIMO-3304 URL: https://issues.apache.org/jira/browse/GERONIMO-3304 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: J2G Environment: windows xp, linux Reporter: Viet Hung Nguyen As of now, when there is a jboss.xml in a JBoss project, the geronimo equivalent is written to openejb-jar.xml. However, that only covers EJB 2.1's features. We need a way to update the openejb-jar.xml by looking at the annotations because there is still some configuring left to do. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Error formatting macro: snippet
I just checked the confluence snippet macro config and it looks ok. It
has a mapping of:
prefix: servicemix/
to url: http://svn.apache.org/repos/asf/incubator/servicemix/
Thus, on your page, it should just be:
{snippet:id=expression|lang=xml|
url=servicemix/trunk/common/servicemix-components/src/test/resources/org/apache/servicemix/components/net/ftp.xml}
Dan
On Tuesday 10 July 2007 10:25, Gert Vanthienen wrote:
L.S.,
Some of our documentation pages use Confluence's snippet macro to
include code sample (e.g.
http://incubator.apache.org/servicemix/ftp.html). Currently, this
macro doesn't seem to work any more:
Error formatting macro: snippet:
java.lang.IllegalArgumentException: Invalid url: must begin with a
configured prefix.
We're not alone, apparently the Struts team has the same problem (e.g.
http://struts.apache.org/2.0.5/docs/conversion-validator.html). A
quick search on the web seems to indicate that this is some kind of
confguration problem with the snippet macro. Who can administer the
Confluence instance that hosts our website to resolve this issue?
Gert
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog
[jira] Updated: (GERONIMO-3304) ability to update openejb-jar.xml by examining annotations
[ https://issues.apache.org/jira/browse/GERONIMO-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3304: --- Attachment: geronimo-3304.patch this patch updates (under certain circumstances creates) openejb-jar.xml by looking at the annotations, and updates as much of the DD as possible. ability to update openejb-jar.xml by examining annotations -- Key: GERONIMO-3304 URL: https://issues.apache.org/jira/browse/GERONIMO-3304 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: J2G Environment: windows xp, linux Reporter: Viet Hung Nguyen Attachments: geronimo-3304.patch As of now, when there is a jboss.xml in a JBoss project, the geronimo equivalent is written to openejb-jar.xml. However, that only covers EJB 2.1's features. We need a way to update the openejb-jar.xml by looking at the annotations because there is still some configuring left to do. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Build Failure
On 7/10/07, Prasad Kashyap [EMAIL PROTECTED] wrote: Using the published openejb artifacts will give this problem. Build openejb locally to get around this. Hopefully somebody from openejb will publish new snaps soon. Yeah. I've already marked it to do once I get a capable connection to perform the release. It should be done in a couple of hours unless other openejber beats me to it. Patience is appreciated. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
[jira] Created: (GERONIMO-3305) Out Of Memory Error when Running DayTrader in WebServices Mode
Out Of Memory Error when Running DayTrader in WebServices Mode
--
Key: GERONIMO-3305
URL: https://issues.apache.org/jira/browse/GERONIMO-3305
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Affects Versions: 2.0-M7
Environment: All
Reporter: Matt Hogstrom
Assignee: Kevan Miller
I deployed DayTrader 2.0 on the latest SVN rev 554753 of trunk.
I deploy daytrader-ear-2.0-SNAPSHOT.ear (using the
daytrader-g-2.0-SNAPSHOT-plan.xml in ${DT}/trunk/plans
Create the tables and populate them in the config section.
Switch to WebServices mode
Log in and do portfolio, quotes, buy and sell a few stocks and then logoff.
Try to log in again and I get:
10:34:34,089 ERROR [Log] Error: JSR 109 lookup failed .. defaulting to JSR 101
javax.naming.NamingException: Could not look up : service/Trade [Root
exception is net.sf.cglib.core.CodeGenerationException:
java.lang.reflect.InvocationTargetException--null]
javax.naming.NamingException: Could not look up : service/Trade [Root exception
is net.sf.cglib.core.CodeGenerationException:
java.lang.reflect.InvocationTargetException--null]
at
org.apache.xbean.naming.context.ContextUtil.resolve(ContextUtil.java:65)
at
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:112)
at
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:611)
at
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:152)
at
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:611)
at
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:152)
at
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:597)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at
org.apache.geronimo.samples.daytrader.soap.TradeWebSoapProxy.getPortFromFactory(TradeWebSoapProxy.java:67)
at
org.apache.geronimo.samples.daytrader.soap.TradeWebSoapProxy.getTrade(TradeWebSoapProxy.java:47)
at
org.apache.geronimo.samples.daytrader.soap.TradeWebSoapProxy.getAccountData(TradeWebSoapProxy.java:122)
at
org.apache.geronimo.samples.daytrader.web.TradeServletAction.doHome(TradeServletAction.java:277)
at
org.apache.geronimo.samples.daytrader.web.TradeServletAction.doLogin(TradeServletAction.java:372)
at
org.apache.geronimo.samples.daytrader.web.TradeAppServlet.performTask(TradeAppServlet.java:126)
at
org.apache.geronimo.samples.daytrader.web.TradeAppServlet.doPost(TradeAppServlet.java:91)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.geronimo.samples.daytrader.web.OrdersAlertFilter.doFilter(OrdersAlertFilter.java:91)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:351)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:613)
Caused by: net.sf.cglib.core.CodeGenerationException:
java.lang.reflect.InvocationTargetException--null
at
net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:237)
at
Re: [VOTE] Release specs for Activation and StAX - rc2
+1 Jarek On 7/10/07, Prasad Kashyap [EMAIL PROTECTED] wrote: The activation and stax specs had almost passed the vote the first time around. It got dinged on missing scm section in the poms. I have fixed it now and am resubmitting them for a vote. Please review the specifications located at http://people.apache.org/~prasad/specs_rc2/ Voting concludes on Monday, July 13th at 1000 ET. The other outstanding specs (depending on servlet) that would be released together are servlet_2.5_spec-1.1 jsp_2.1_spec-1.0 jacc_1.1_spec-1.0 Cheers Prasad
[jira] Closed: (GERONIMO-3303) Simplify security authentication framework by removing mixed local/remote logins.
[ https://issues.apache.org/jira/browse/GERONIMO-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3303. -- Resolution: Fixed Committed in rev 554977. This is likely to require little bits of additional cleanup, but I did some looking around in e.g. the testsuite plans. Simplify security authentication framework by removing mixed local/remote logins. --- Key: GERONIMO-3303 URL: https://issues.apache.org/jira/browse/GERONIMO-3303 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: security Affects Versions: 2.0-M6 Reporter: David Jencks Assignee: David Jencks Fix For: 2.0-M7 Back at apachecon 2005 there was a big discussion where we decided to remove the parts of the geronimo authentication framework that let clients run login modules on the server. See the email from me dated Dec 23, 2005, at 6:37 PM, Geronimo Security plans (from ApacheCon). I've finally replaced the remote login with something using the openejb protocol and removed the no longer needed code. This is a big simplification. I've refactored the authentication stuff so that: - we still have a GeronimoLoginConfiguration - we can still (optionally) wrap principals to determine exactly which login module and realm they came from - all authentication happens in a single vm, no sneaky remoting stuff - we use the LoginContext to create the login modules directly from the AppConfigurationEntry[] - registering and unregistering the subject and inserting the identification principal is done by a login module automatically added by the GenericSecurityRealm, rather than the JaasSecuritySession This eliminates most of the hard to understand code including: JaasLoginCoordinator JaasSecuritySession JaasLoginService I've also removed the subject carrying protocol and the remoting jmx code since it isn't used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release specs for Activation and StAX - rc2
Btw, I assume you meant Friday the 13th, right? Jarek On 7/10/07, Prasad Kashyap [EMAIL PROTECTED] wrote: The activation and stax specs had almost passed the vote the first time around. It got dinged on missing scm section in the poms. I have fixed it now and am resubmitting them for a vote. Please review the specifications located at http://people.apache.org/~prasad/specs_rc2/ Voting concludes on Monday, July 13th at 1000 ET. The other outstanding specs (depending on servlet) that would be released together are servlet_2.5_spec-1.1 jsp_2.1_spec-1.0 jacc_1.1_spec-1.0 Cheers Prasad
Re: Geronimo Security plans (from ApacheCon)
I've committed this in rev 554977. Please speak up if you have comments or objections or encounter problems. thanks david jencks On Jul 10, 2007, at 1:52 AM, David Jencks wrote: So its a year and a half later I've finally made a bit of progress on the first of these goals. Recently I replaced the only use of remote login with login over the openejb protocol. This means that the client/server-side distinction is no longer relevant, and the login module wrapping a set of login modules is not needed either. I've refactored the authentication stuff so that: - we still have a GeronimoLoginConfiguration - we can still (optionally) wrap principals to determine exactly which login module and realm they came from - all authentication happens in a single vm, no sneaky remoting stuff - we use the LoginContext to create the login modules directly from the AppConfigurationEntry[] - registering and unregistering the subject and inserting the identification principal is done by a login module automatically added by the GenericSecurityRealm, rather than the JaasSecuritySession This eliminates most of the hard to understand code including: JaasLoginCoordinator JaasSecuritySession JaasLoginService I've also removed the subject carrying protocol and the remoting jmx code since it isn't used. I'm somewhat sorry to see all this sophisticated code Alan wrote go since it is a quite interesting solution to the problem of how to share authentication between a client and server, but I think it has proven to be fatally complex and not really a good solution to the original problem. As we discussed at this apachecon security assertions seem to provide a better framework for thinking about these questions. I opened GERONIMO-3303 about this and expect to be comitting after just a bit more cleanup. thanks david jencks On Dec 23, 2005, at 6:37 PM, David Jencks wrote: At ApacheCon several of us got together to discuss security in Geronimo. These are my recollections, please expand/contradict/ modify what I forgot or got wrong. People: Alan Cabrera, David Jencks, Kresten Krab Thorup, Hiram Chirino, Simon Godik (Others ???) Problems with the current implementation: - Distinction between client-side and server-side login modules is too hard to understand and too ad-hoc: security assertions are a better, standard, and more comprehensible way of getting the same functionality. - The LoginModule wrapping a set of login modules serves little purpose. Things we like and want to generalize somehow: - We'd like to extend the variety of approaches represented in the CORBA csiv2 model to other transports and contexts beyond CORBA How we might get there: Simon gave us some hints about SAML and XACML and IIUC pointed out that most of the basic ideas we need are worked out in detail in these specs and that we can implement these ideas without necessarily relying on the xml-centered implementation called for in the specs. In particular SAML extensively discusses security assertions which are a more powerful and systematic way of dealing with both the client/server login module problems and the information dealt with by csiv2. My current and very limited understanding is that SAML indicates what kind of security assertions can be made and how to transfer them between systems. XACML provides a framework in which (among many many other things) these security assertions can have effects on authentication and authorization decisions Since ApacheCon I've started looking into XACML and SAML a tiny bit and although I am not thrilled by the pointy brackets I think this is an avenue we should investigate thoroughly. I think it can definitely provide the flexibility we want in the security model: I think the challenge will be making the configuration comprehensible and the implementation fast. From my very brief study it looks like XACML will provide a framework in which authorization rules that include the request info provided by JACC can be evaluated. I'm not sure what else it will bring us :-) Many thanks, david jencks
Re: [VOTE] Release specs for Activation and StAX - rc2
+1 Lin Prasad Kashyap wrote: The activation and stax specs had almost passed the vote the first time around. It got dinged on missing scm section in the poms. I have fixed it now and am resubmitting them for a vote. Please review the specifications located at http://people.apache.org/~prasad/specs_rc2/ Voting concludes on Monday, July 13th at 1000 ET. The other outstanding specs (depending on servlet) that would be released together are servlet_2.5_spec-1.1 jsp_2.1_spec-1.0 jacc_1.1_spec-1.0 Cheers Prasad
Re: [VOTE] Release specs for Activation and StAX - rc2
Yeah.. Maybe I didn't want to spook this vote again with a Friday the 13th deadline ;-) Cheers Prasad On 7/10/07, Jarek Gawor [EMAIL PROTECTED] wrote: Btw, I assume you meant Friday the 13th, right? Jarek On 7/10/07, Prasad Kashyap [EMAIL PROTECTED] wrote: The activation and stax specs had almost passed the vote the first time around. It got dinged on missing scm section in the poms. I have fixed it now and am resubmitting them for a vote. Please review the specifications located at http://people.apache.org/~prasad/specs_rc2/ Voting concludes on Monday, July 13th at 1000 ET. The other outstanding specs (depending on servlet) that would be released together are servlet_2.5_spec-1.1 jsp_2.1_spec-1.0 jacc_1.1_spec-1.0 Cheers Prasad
Re: svn commit: r554980 - /geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.st.v20.core/src/org/apache/geronimo/st/v20/core/GeronimoServer.java
On 7/10/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: mcconne Date: Tue Jul 10 08:35:58 2007 New Revision: 554980 URL: http://svn.apache.org/viewvc?view=revrev=554980 Log: GERONIMODEVTOOLS-173 Check for existence of the jpa.jar file when setting javaagent Hi, Could code formatting be committed with no other code changes? It's really hard to find out what changed in this commit. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
[jira] Created: (GERONIMO-3306) JMS Objects being bound at an incorrect spot in the JNDI tree.
JMS Objects being bound at an incorrect spot in the JNDI tree.
--
Key: GERONIMO-3306
URL: https://issues.apache.org/jira/browse/GERONIMO-3306
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Affects Versions: 2.0-M7
Environment: All
Reporter: Matt Hogstrom
Assignee: Tim McConnell
DayTrader 2.0 uses a Session Bean that acts as a focal point for many
application operations. This bean does a lookup of several resources in the
setSessionContext method. This method looks up the following resources. The
first line is line 1034 from TradeBean.java. Note that the jms/ resource are
successfully looked up but that the items on line 1056 and 1057 needs to have
geronimo inserted into the name in order for the resolution to be successful.
{code}
*1034* public void ejbCreate() throws CreateException {
*1035* try {
*1036*
*1037* if (Log.doTrace())
*1038* Log.trace(TradeBean:ejbCreate -- JNDI lookups
of EJB and JMS resources);
*1039*
*1040* InitialContext ic = new InitialContext();
*1041* quoteHome = (LocalQuoteHome)
ic.lookup(java:comp/env/ejb/Quote);
*1042* accountHome = (LocalAccountHome)
ic.lookup(java:comp/env/ejb/Account);
*1043* profileHome = (LocalAccountProfileHome)
ic.lookup(java:comp/env/ejb/AccountProfile);
*1044* holdingHome = (LocalHoldingHome)
ic.lookup(java:comp/env/ejb/Holding);
*1045* orderHome = (LocalOrderHome)
ic.lookup(java:comp/env/ejb/Order);
*1046* keySequenceHome = (LocalKeySequenceHome)
ic.lookup(java:comp/env/ejb/KeySequence);
*1047*
*1048* orderBySQLSupported = ( (Boolean)
ic.lookup(java:comp/env/orderBySQLSupported) ).booleanValue();
*1049* updateQuotePrices = ( (Boolean)
ic.lookup(java:comp/env/updateQuotePrices) ).booleanValue();
*1050* TradeConfig.setUpdateQuotePrices(updateQuotePrices);
*1051*
*1052* try
*1053* {
*1054* qConnFactory = (ConnectionFactory)
ic.lookup(java:comp/env/jms/QueueConnectionFactory);
*1055* tConnFactory = (ConnectionFactory)
ic.lookup(java:comp/env/jms/TopicConnectionFactory);
*1056* streamerTopic = (Topic)
ic.lookup(java:comp/geronimo/env/jms/TradeStreamerTopic);
*1057*brokerQueue = (Queue)
ic.lookup(java:comp/geronimo/env/jms/TradeBrokerQueue);
{code}
Now, looking at the streamerTopic and brokerQueue definitions we also have
annotations which have the desired (correct?) names defined. However, when
the bean is initialized we receive the following warnings:
{code}
*46*@Resource(name = jms/TradeBrokerQueue)
*47*private Queue brokerQueue = null;
*48*
*49*private ConnectionFactory tConnFactory = null;
*50*
*51*@Resource(name = jms/TradeStreamerTopic)
*52*private Topic streamerTopic = null;
{code}
12:24:37,117 WARN [OpenEJB] Injection data not found in enc:
jndiName='jms/TradeBrokerQueue', target=class
org.apache.geronimo.samples.daytrader.ejb.TradeBean/brokerQueue
12:24:37,118 WARN [OpenEJB] Injection data not found in enc:
jndiName='jms/TradeStreamerTopic', target=class
org.apache.geronimo.samples.daytrader.ejb.TradeBean/streamerTopic
So, the other resources outlined above (like the ConnectionFactories) seem to
be bound correctly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Build Failure
On 7/10/07, Jacek Laskowski [EMAIL PROTECTED] wrote: On 7/10/07, Prasad Kashyap [EMAIL PROTECTED] wrote: Using the published openejb artifacts will give this problem. Build openejb locally to get around this. Hopefully somebody from openejb will publish new snaps soon. Yeah. I've already marked it to do once I get a capable connection to perform the release. It should be done in a couple of hours unless other openejber beats me to it. Done. It failed at examples publishing (needs to be fixed), but it should fix the issue. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
[jira] Reopened: (GERONIMODEVTOOLS-173) Geronimo Little-G release with Jetty don't start within Eclipse
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell reopened GERONIMODEVTOOLS-173: Geronimo Little-G release with Jetty don't start within Eclipse --- Key: GERONIMODEVTOOLS-173 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-173 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Environment: Windows XP, JDK 6, Eclipse 3.3 Europa Reporter: Mario Ruebsam Assignee: Tim McConnell Fix For: 2.0 Geronimo Little-G release with Jetty don't start within Eclipse. It requires the bin/jpa.jar and lib/geronimo-transfromer-2.0-SNAPSHOT.jar from the standard server release. JPA should not be an requirement to start the Little-G server in Eclipse. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release specs for Activation and StAX - rc2
+1 On Jul 10, 2007, at 9:30 AM, Prasad Kashyap wrote: The activation and stax specs had almost passed the vote the first time around. It got dinged on missing scm section in the poms. I have fixed it now and am resubmitting them for a vote. Please review the specifications located at http://people.apache.org/~prasad/specs_rc2/ Voting concludes on Monday, July 13th at 1000 ET. The other outstanding specs (depending on servlet) that would be released together are servlet_2.5_spec-1.1 jsp_2.1_spec-1.0 jacc_1.1_spec-1.0 Cheers Prasad
Re: [VOTE] Release specs for Activation and StAX - rc2
+1 Vamsi On 7/10/07, Prasad Kashyap [EMAIL PROTECTED] wrote: The activation and stax specs had almost passed the vote the first time around. It got dinged on missing scm section in the poms. I have fixed it now and am resubmitting them for a vote. Please review the specifications located at http://people.apache.org/~prasad/specs_rc2/ Voting concludes on Monday, July 13th at 1000 ET. The other outstanding specs (depending on servlet) that would be released together are servlet_2.5_spec-1.1 jsp_2.1_spec-1.0 jacc_1.1_spec-1.0 Cheers Prasad
[jira] Commented: (GERONIMODEVTOOLS-173) Geronimo Little-G release with Jetty don't start within Eclipse
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511495 ] Tim McConnell commented on GERONIMODEVTOOLS-173: Changed org.apache.geronimo.st.v20.core.GeronimoServer to check for the existence of the jpa.jar file prior to setting javaagent field (in a similar manner as the geronimo.bat/sh files) so that all configurations of Geronimo will start successfully under Eclipse. Still trying to figure out how to Resolve/Close this defect though as those options are not available to me for some reason. Geronimo Little-G release with Jetty don't start within Eclipse --- Key: GERONIMODEVTOOLS-173 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-173 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Environment: Windows XP, JDK 6, Eclipse 3.3 Europa Reporter: Mario Ruebsam Assignee: Tim McConnell Fix For: 2.0 Geronimo Little-G release with Jetty don't start within Eclipse. It requires the bin/jpa.jar and lib/geronimo-transfromer-2.0-SNAPSHOT.jar from the standard server release. JPA should not be an requirement to start the Little-G server in Eclipse. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3304) ability to update openejb-jar.xml by examining annotations
[ https://issues.apache.org/jira/browse/GERONIMO-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511497 ] Matt Hogstrom commented on GERONIMO-3304: - You might look at DayTrader as it has jboss DDs in it. Look here for the current DT source: https://svn.apache.org/repos/asf/geronimo/daytrader/trunk ability to update openejb-jar.xml by examining annotations -- Key: GERONIMO-3304 URL: https://issues.apache.org/jira/browse/GERONIMO-3304 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: J2G Environment: windows xp, linux Reporter: Viet Hung Nguyen Attachments: geronimo-3304.patch As of now, when there is a jboss.xml in a JBoss project, the geronimo equivalent is written to openejb-jar.xml. However, that only covers EJB 2.1's features. We need a way to update the openejb-jar.xml by looking at the annotations because there is still some configuring left to do. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release specs for Activation and StAX - rc2
+1 Jacek On 7/10/07, Prasad Kashyap [EMAIL PROTECTED] wrote: The activation and stax specs had almost passed the vote the first time around. It got dinged on missing scm section in the poms. I have fixed it now and am resubmitting them for a vote. Please review the specifications located at http://people.apache.org/~prasad/specs_rc2/ Voting concludes on Monday, July 13th at 1000 ET. The other outstanding specs (depending on servlet) that would be released together are servlet_2.5_spec-1.1 jsp_2.1_spec-1.0 jacc_1.1_spec-1.0 Cheers Prasad -- Jacek Laskowski http://www.JacekLaskowski.pl
[jira] Commented: (GERONIMODEVTOOLS-173) Geronimo Little-G release with Jetty don't start within Eclipse
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511498 ] Jacek Laskowski commented on GERONIMODEVTOOLS-173: -- Try it out now. You were in geronimo-contributor group. Geronimo Little-G release with Jetty don't start within Eclipse --- Key: GERONIMODEVTOOLS-173 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-173 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Environment: Windows XP, JDK 6, Eclipse 3.3 Europa Reporter: Mario Ruebsam Assignee: Tim McConnell Fix For: 2.0 Geronimo Little-G release with Jetty don't start within Eclipse. It requires the bin/jpa.jar and lib/geronimo-transfromer-2.0-SNAPSHOT.jar from the standard server release. JPA should not be an requirement to start the Little-G server in Eclipse. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-935) Allow to specify additional JNDI properties
[
https://issues.apache.org/activemq/browse/SM-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_39637
]
Phiroze Dastoor commented on SM-935:
Please will someone tell me if there is any progress on this issue?
We are also interested in user authentication when configuring a specific JMS
endpoint.
Phiroze
Allow to specify additional JNDI properties
---
Key: SM-935
URL: https://issues.apache.org/activemq/browse/SM-935
Project: ServiceMix
Issue Type: New Feature
Components: servicemix-jms
Affects Versions: 3.1
Reporter: Gert Vanthienen
Priority: Minor
In addition to using initialContext and jndiProviderUrl to configure a JMS
endpoint, it should be possible to specify additional JNDI properties (e.g
{{java.naming.security.principal}}, {{java.naming.security.credentials}})
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r554980 - /geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.st.v20.core/src/org/apache/geronimo/st/v20/core/GeronimoServer.java
Hi Jacek, Sorry about that--I must have inadvertently reformatted the code in my
IDE. I shall be more careful though next time. Here is the only change made to
class though:
//-javaagent:GERONIMO_BASE/bin/jpa.jar
String javaagent = ;
File jpaJar = new File(runtimeLocation + /bin/jpa.jar);
if (jpaJar.exists()) {
javaagent = -javaagent:\ + runtimeLocation + /bin/jpa.jar\;
}
Jacek Laskowski wrote:
On 7/10/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: mcconne
Date: Tue Jul 10 08:35:58 2007
New Revision: 554980
URL: http://svn.apache.org/viewvc?view=revrev=554980
Log:
GERONIMODEVTOOLS-173 Check for existence of the jpa.jar file when
setting javaagent
Hi,
Could code formatting be committed with no other code changes? It's
really hard to find out what changed in this commit.
Jacek
--
Thanks,
Tim McConnell
[jira] Closed: (GERONIMODEVTOOLS-173) Geronimo Little-G release with Jetty don't start within Eclipse
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell closed GERONIMODEVTOOLS-173. -- Resolution: Fixed Much better--thanks Jacek !! Geronimo Little-G release with Jetty don't start within Eclipse --- Key: GERONIMODEVTOOLS-173 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-173 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Environment: Windows XP, JDK 6, Eclipse 3.3 Europa Reporter: Mario Ruebsam Assignee: Tim McConnell Fix For: 2.0 Geronimo Little-G release with Jetty don't start within Eclipse. It requires the bin/jpa.jar and lib/geronimo-transfromer-2.0-SNAPSHOT.jar from the standard server release. JPA should not be an requirement to start the Little-G server in Eclipse. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-174) Distribution of configuration failed when attempting to deploy using Geronimo 2.0 adapter
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511514 ] Tom Mutdosch commented on GERONIMODEVTOOLS-174: --- This was using Eclipse 33RC4a (and I'm pretty sure the WTP 2.0 RC4 build as well). Did you say you mean that you could *not* reproduce it, or you were able to? Distribution of configuration failed when attempting to deploy using Geronimo 2.0 adapter --- Key: GERONIMODEVTOOLS-174 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-174 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Tom Mutdosch Using the following Geronimo 2.0 runtime server and adapter: (*) Server: http://people.apache.org/dist/geronimo/eclipse/unstable/servers/geronimo-tomcat6-jee5-2.0-SNAPSHOT-bin.zip (*)Server plugins: http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-2.0.0-v20070621.1204-deployable.zip Using eclipse WTP, I create a simple Dynamic Web Project targeting Geronimo with a single HTML file. When I do a Run on Server I get the following error in an error dialog and my page does not run. Error: Distribution of configuration failed. See log for details. Cannot deploy the requested application module because no deployer is able to handle it. This can happen if you have omitted the J2EE deployment descriptor, disabled a deployer module, or if, for example, you are trying to deploy an EJB module on a minimal Geronimo server that does not have EJB support installed. (moduleFile=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\geronimo-deployer1127.tmpdir\geronimoTestEAR.zip) org.apache.geronimo.common.DeploymentException: Cannot deploy the requested application module because no deployer is able to handle it. This can happen if you have omitted the J2EE deployment descriptor, disabled a deployer module, or if, for example, you are trying to deploy an EJB module on a minimal Geronimo server that does not have EJB support installed. (moduleFile=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\geronimo-deployer1127.tmpdir\geronimoTestEAR.zip) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:239) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:863) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:863) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:168) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:231) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:238) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:833) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:802) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1423) at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:96) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1260) at java.security.AccessController.doPrivileged(AccessController.java:275) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1363) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:797) at sun.reflect.GeneratedMethodAccessor193.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309) at sun.rmi.transport.Transport$1.run(Transport.java:168) at java.security.AccessController.doPrivileged(AccessController.java:275) at
[jira] Commented: (GERONIMODEVTOOLS-174) Distribution of configuration failed when attempting to deploy using Geronimo 2.0 adapter
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511522 ] Jacek Laskowski commented on GERONIMODEVTOOLS-174: -- I could very easily and that's why I think it's WTP issue not Geronimo's. Distribution of configuration failed when attempting to deploy using Geronimo 2.0 adapter --- Key: GERONIMODEVTOOLS-174 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-174 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Tom Mutdosch Using the following Geronimo 2.0 runtime server and adapter: (*) Server: http://people.apache.org/dist/geronimo/eclipse/unstable/servers/geronimo-tomcat6-jee5-2.0-SNAPSHOT-bin.zip (*)Server plugins: http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-2.0.0-v20070621.1204-deployable.zip Using eclipse WTP, I create a simple Dynamic Web Project targeting Geronimo with a single HTML file. When I do a Run on Server I get the following error in an error dialog and my page does not run. Error: Distribution of configuration failed. See log for details. Cannot deploy the requested application module because no deployer is able to handle it. This can happen if you have omitted the J2EE deployment descriptor, disabled a deployer module, or if, for example, you are trying to deploy an EJB module on a minimal Geronimo server that does not have EJB support installed. (moduleFile=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\geronimo-deployer1127.tmpdir\geronimoTestEAR.zip) org.apache.geronimo.common.DeploymentException: Cannot deploy the requested application module because no deployer is able to handle it. This can happen if you have omitted the J2EE deployment descriptor, disabled a deployer module, or if, for example, you are trying to deploy an EJB module on a minimal Geronimo server that does not have EJB support installed. (moduleFile=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\geronimo-deployer1127.tmpdir\geronimoTestEAR.zip) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:239) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:863) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:863) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:168) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:231) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:238) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:833) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:802) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1423) at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:96) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1260) at java.security.AccessController.doPrivileged(AccessController.java:275) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1363) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:797) at sun.reflect.GeneratedMethodAccessor193.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309) at sun.rmi.transport.Transport$1.run(Transport.java:168) at java.security.AccessController.doPrivileged(AccessController.java:275) at sun.rmi.transport.Transport.serviceCall(Transport.java:164) at
Re: [VOTE] Release specs for Activation and StAX - rc2
+1 On Jul 10, 2007, at 9:30 AM, Prasad Kashyap wrote: The activation and stax specs had almost passed the vote the first time around. It got dinged on missing scm section in the poms. I have fixed it now and am resubmitting them for a vote. Please review the specifications located at http://people.apache.org/~prasad/specs_rc2/ Voting concludes on Monday, July 13th at 1000 ET. The other outstanding specs (depending on servlet) that would be released together are servlet_2.5_spec-1.1 jsp_2.1_spec-1.0 jacc_1.1_spec-1.0 Cheers Prasad
checkstyle on the se-archectype
Following the se tutorial: http://incubator.apache.org/servicemix/hello-world-se.html The code produced from the mvn archetype failed the checkstyle check (with errors). Has anyone else experienced this? (I also had to go in and update the version in the pom.xml, so it would pull a current release of sm) -brian -- Brian ONeill Source Equity (http://www.sourceequity.com) jBIZint (http://www.jbizint.org) Technical Architect, Gestalt LLC (http://www.gestalt-llc.com) mobile:215.588.6024
Re: [VOTE] Release specs for Activation and StAX - rc2
And my +1 too Cheers Prasad On 7/10/07, Prasad Kashyap [EMAIL PROTECTED] wrote: The activation and stax specs had almost passed the vote the first time around. It got dinged on missing scm section in the poms. I have fixed it now and am resubmitting them for a vote. Please review the specifications located at http://people.apache.org/~prasad/specs_rc2/ Voting concludes on Monday, July 13th at 1000 ET. The other outstanding specs (depending on servlet) that would be released together are servlet_2.5_spec-1.1 jsp_2.1_spec-1.0 jacc_1.1_spec-1.0 Cheers Prasad
SNAPSHOT dependencies that need to be released.
The following Geronimo dependencies uses SNAPSHOT versions. Can we please chase these projects and get them to release the artifacts, whatever it takes; contacts, muscles, bribes, favors, etc :-) If enough people on this list volunteer to get some of these released, then I'll create a wiki page where they can sign up. openejbVersion3.0-incubating-SNAPSHOT/openejbVersion groupIdorg.apache.cxf/groupId artifactIdcxf-api/artifactId version2.0-incubator-SNAPSHOT/version groupIdorg.apache.axis2/groupId artifactIdaxis2-java2wsdl/artifactId versionSNAPSHOT/version groupIdorg.apache.axis2/groupId artifactIdaxis2-kernel/artifactId versionSNAPSHOT/version groupIdorg.apache.axis2/groupId artifactIdaxis2-adb/artifactId versionSNAPSHOT/version groupIdorg.apache.axis2/groupId artifactIdaxis2-jaxws-api/artifactId versionSNAPSHOT/version groupIdorg.apache.axis2/groupId artifactIdaxis2-jaxws/artifactId versionSNAPSHOT/version groupIdorg.apache.axis2/groupId artifactIdaxis2-metadata/artifactId versionSNAPSHOT/version groupIdorg.apache.axis2/groupId artifactIdaxis2-saaj/artifactId versionSNAPSHOT/version groupIdorg.apache.geronimo.javamail/groupId artifactIdgeronimo-javamail_1.4_mail/artifactId version1.1-SNAPSHOT/version groupIdorg.apache.geronimo.schema/groupId artifactIdgeronimo-schema-jee_5/artifactId version1.1-SNAPSHOT/version groupIdorg.apache.geronimo.schema/groupId artifactIdgeronimo-schema-j2ee_1.4/artifactId version1.1-SNAPSHOT/version groupIdorg.apache.openjpa/groupId artifactIdopenjpa/artifactId version1.0.0-SNAPSHOT/version groupIdorg.apache.xbean/groupId artifactIdxbean-finder/artifactId version3.0-SNAPSHOT/version groupIdorg.apache.xbean/groupId artifactIdxbean-naming/artifactId version3.0-SNAPSHOT/version groupIdorg.apache.xbean/groupId artifactIdxbean-reflect/artifactId version3.1-SNAPSHOT/version groupIdorg.apache.ws.scout/groupId artifactIdscout/artifactId versionSNAPSHOT/version groupIdorg.apache.yoko/groupId artifactIdyoko-core/artifactId version1.0-incubating-SNAPSHOT/version groupIdorg.apache.yoko/groupId artifactIdyoko-spec-corba/artifactId version1.0-incubating-SNAPSHOT/version groupIdorg.apache.yoko/groupId artifactIdyoko-rmi-spec/artifactId version1.0-incubating-SNAPSHOT/version groupIdorg.apache.yoko/groupId artifactIdyoko-rmi-impl/artifactId version1.0-incubating-SNAPSHOT/version groupIdorg.mortbay.jetty/groupId artifactIdjetty/artifactId version6.1-SNAPSHOT/version groupIdorg.mortbay.jetty/groupId artifactIdjetty-ajp/artifactId version6.1-SNAPSHOT/version groupIdorg.mortbay.jetty/groupId artifactIdjetty-sslengine/artifactId version6.1-SNAPSHOT/version groupIdorg.mortbay.jetty/groupId artifactIdjetty-util/artifactId version6.1-SNAPSHOT/version groupIdorg.apache.myfaces.core/groupId artifactIdmyfaces-api/artifactId version1.2.0-SNAPSHOT/version groupIdorg.apache.myfaces.core/groupId artifactIdmyfaces-impl/artifactId version1.2.0-SNAPSHOT/version Cheers Prasad
Re: SNAPSHOT dependencies that need to be released.
On Jul 10, 2007, at 10:42 PM, Prasad Kashyap wrote: The following Geronimo dependencies uses SNAPSHOT versions. Can we please chase these projects and get them to release the artifacts, whatever it takes; contacts, muscles, bribes, favors, etc :-) [...] groupIdorg.apache.myfaces.core/groupId artifactIdmyfaces-api/artifactId version1.2.0-SNAPSHOT/version groupIdorg.apache.myfaces.core/groupId artifactIdmyfaces-impl/artifactId version1.2.0-SNAPSHOT/version I think Matthias is in the process of releasing the MyFaces 1.2 jars right now. Best wishes, Paul
Re: [VOTE] Release specs for Activation and StAX - rc2
+1 -Donald Prasad Kashyap wrote: The activation and stax specs had almost passed the vote the first time around. It got dinged on missing scm section in the poms. I have fixed it now and am resubmitting them for a vote. Please review the specifications located at http://people.apache.org/~prasad/specs_rc2/ Voting concludes on Monday, July 13th at 1000 ET. The other outstanding specs (depending on servlet) that would be released together are servlet_2.5_spec-1.1 jsp_2.1_spec-1.0 jacc_1.1_spec-1.0 Cheers Prasad smime.p7s Description: S/MIME Cryptographic Signature
