Hide Forgot
Date of First Response: 2007-11-20 12:08:52 project_key: SOA The base-build.xml file for the quickstarts specifies "default" as the deploy directory. This works fine for the standalone version, but the EAP version does not have esb enabled in the default profile, so deployment of the quickstart fails. I managed to get around this in IR5 by modifying the base-build.xml file to replace references to "default" with "production". If we rename "default" in the standalone version to "production", then this workaround would work on both.
Link: Added: This issue depends SOA-139
If we were to delete the default profile from the EAP version and change the name of the standalone "default" profile to "production" this would tidy things up immensely.
Link: Added: This issue is related to SOA-139
Link: Removed: This issue depends SOA-139
The base-build.xml does not specify the deploy directory unless it is running within standalone. The workaround is not correct.
After discussing with Joshua, we will be extending the base-build.xml to handle the 'production' profile for embedded environments. No need to add the quickstarts.properties file.
Joshua has asked for the fix to be emailed to him so that he can look at the documentation issues (just adding here so that I do not forget)
Link: Added: This issue depends JBESB-1355
The problem is still there in IR7.
With the fix that Kev emailed me the quickstart will deploy, but it gives an error similar to SOA-112 when I run ant runtest. I might think this is SOA-112, except that Len gave me another build-base.xml that works (http://qafiler.boston.redhat.com/testkits/JBoss/jwulf/). Here's the error I get using Kev's build-base.xml: runtest: [echo] Runs Test JMS Sender [java] Exception in thread "main" javax.jms.JMSSecurityException: User null is NOT authenticated [java] at org.jboss.jms.server.security.SecurityMetadataStore.authenticate(SecurityMetadataStore.java:202) [java] at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint.createConnectionDelegateInternal(ServerConnectionFactoryEndpoint.java:222) [java] at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint.createConnectionDelegate(ServerConnectionFactoryEndpoint.java:162) [java] at org.jboss.jms.server.endpoint.advised.ConnectionFactoryAdvised.org$jboss$jms$server$endpoint$advised$ConnectionFactoryAdvised$createConnectionDelegate$aop(ConnectionFactoryAdvised.java:108) [java] at org.jboss.jms.server.endpoint.advised.ConnectionFactoryAdvised.createConnectionDelegate(ConnectionFactoryAdvised.java) [java] at org.jboss.jms.wireformat.ConnectionFactoryCreateConnectionDelegateRequest.serverInvoke(ConnectionFactoryCreateConnectionDelegateRequest.java:91) [java] at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:144) [java] at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:769) [java] at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:573) [java] at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:387) [java] at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166) [java] at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:163) [java] at org.jboss.remoting.Client.invoke(Client.java:1634) [java] at org.jboss.remoting.Client.invoke(Client.java:548) [java] at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.org$jboss$jms$client$delegate$ClientConnectionFactoryDelegate$createConnectionDelegate$aop(ClientConnectionFactoryDelegate.java:167) [java] at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java) [java] at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:83) [java] at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect0.invoke(StateCreationAspect0.java) [java] at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java) [java] at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java) [java] at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:205) [java] at org.jboss.jms.client.JBossConnectionFactory.createQueueConnection(JBossConnectionFactory.java:101) [java] at org.jboss.jms.client.JBossConnectionFactory.createQueueConnection(JBossConnectionFactory.java:95) [java] at org.jboss.soa.esb.samples.quickstart.helloworld.test.SendJMSMessage.setupConnection(SendJMSMessage.java:54) [java] at org.jboss.soa.esb.samples.quickstart.helloworld.test.SendJMSMessage.main(SendJMSMessage.java:81) BUILD FAILED /home/jwulf/IR7/jboss-soa-p.4.2.0/jboss-as/samples/quickstarts/helloworld/build.xml:14: Java returned: 1
IR7 was a respin of IR6 and therefore did not pull across this fix. The authentication error with JMS is a configuration issue.
The configs that we support for ESB archives for the enbedded server are "production" and "all" - so, yes, we will want to be able to deploy the quickstarts to "all" too.
This is moving away from our notion of embedding the samples and fits more with the requirements for the jbossesb deployment. I'll create a new ESB issue to allow the SOA deployments to configure the target in the same manner.
Link: Added: This issue depends JBESB-1364
Link: Added: This issue related SOA-84
Just to confirm - in IR8, this issue is still present. The quickstart configuration (base-build.xml) deploys to the production configuration. This JIRA was closed as "done", but it's really rejected for SOA-P GA, in favor of the approach described in http://jira.jboss.com/jira/browse/JBESB-1364?
So - our plan is to document this - for folks who want to run the quickstarts on the "all" config - it works on the production config - and fix it in CP1? Is this what is proposed? http://jira.jboss.com/jira/browse/SOA-164#action_12390935 How hard would it be to make this work on the all config for the SOA-P release?
The plan is to remove the quickstart configuration restriction for an embedded environment and will be in the next code drop. The changes have already been made but need to be verified.
Re-opening the JIRA - and then marking it as resolved per Kevin's comments.
Re-opening the JIRA - and then marking it as resolved per Kevin's comments. (We need a "fix version" of IR9 - or "beta1" to be defined.
The restriction has now been removed from the embedded deployments, both config and server home can be specified. The default for the platform is still to deploy into the production configuration.
So - what is the answer for customers? Do we have them edit base-build.xml and replace "production" with "all"? [ldimaggi@ldimaggi conf]$ cat -n base-build.xml | grep production 31 <available file="${product.dir}/server/production"/> 42 <available file="${product.dir}/server/production"/> 204 <condition property="jbossesb-server-production"> 205 <available file="${product.dir}/server/production/deploy/jbossesb.sar"/> 213 <isset property="jbossesb-server-production"/> 225 value="production"> 226 <isset property="jbossesb-server-production"/>
The answer for anyone, customers or otherwise, is to specify them in the same manner that would be done for the non embedded distribution of the project. Edit quickstarts/conf/quickstarts.properties and specify org.jboss.esb.server.config if you want to shift the server profile. Having just checked the quickstarts.properties-example file I have noticed that the comment is no longer correct for the SOA platform, it is only valid for the project. We should change this as part of the SOA build.
Verified in the beta1 build.
Link: Removed: This issue related SOA-84
Link: Added: This issue related SOA-616
Link: Added: This issue related SOA-847