Bug 777654 (SOA-164)

Summary: Quickstarts included in EAP version do not deploy
Product: [JBoss] JBoss Enterprise SOA Platform 4 Reporter: Joshua Wulf <jwulf>
Component: JBossESBAssignee: trev <tkirby>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: urgent Docs Contact:
Priority: urgent    
Version: 4.2 IR6CC: kevin.conner, lcarlon
Target Milestone: ---   
Target Release: 4.2 IR9   
Hardware: Unspecified   
OS: Unspecified   
URL: http://jira.jboss.org/jira/browse/SOA-164
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-01-04 17:20:18 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Joshua Wulf 2007-11-20 16:48:28 UTC
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.

Comment 1 Joshua Wulf 2007-11-20 16:56:21 UTC
Link: Added: This issue depends SOA-139


Comment 2 Joshua Wulf 2007-11-20 16:57:15 UTC
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.

Comment 3 Joshua Wulf 2007-11-20 16:57:15 UTC
Link: Added: This issue is related to SOA-139


Comment 4 Joshua Wulf 2007-11-20 17:02:46 UTC
Link: Removed: This issue depends SOA-139 


Comment 5 Kevin Conner 2007-11-20 17:08:52 UTC
The base-build.xml does not specify the deploy directory unless it is running within standalone.

The workaround is not correct.

Comment 6 Kevin Conner 2007-11-20 17:36:37 UTC
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.

Comment 7 Kevin Conner 2007-11-20 17:39:48 UTC
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)

Comment 8 Kevin Conner 2007-11-20 17:43:28 UTC
Link: Added: This issue depends JBESB-1355


Comment 9 Len DiMaggio 2007-11-25 03:01:44 UTC
The problem is still there in IR7.

Comment 10 Joshua Wulf 2007-11-26 03:02:50 UTC
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

Comment 11 Kevin Conner 2007-11-26 09:12:23 UTC
IR7 was a respin of IR6 and therefore did not pull across this fix.

The authentication error with JMS is a configuration issue.

Comment 12 Len DiMaggio 2007-11-26 18:50:53 UTC
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.


Comment 13 Kevin Conner 2007-11-26 18:56:53 UTC
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.

Comment 14 Len DiMaggio 2007-11-26 19:43:53 UTC
Link: Added: This issue depends JBESB-1364


Comment 15 Len DiMaggio 2007-11-27 14:36:59 UTC
Link: Added: This issue related SOA-84


Comment 16 Len DiMaggio 2007-12-06 20:38:02 UTC
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?

Comment 17 Len DiMaggio 2007-12-10 22:12:41 UTC
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?

Comment 18 Kevin Conner 2007-12-11 05:14:24 UTC
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.

Comment 19 Len DiMaggio 2007-12-11 13:59:10 UTC
Re-opening the JIRA - and then marking it as resolved per Kevin's comments.

Comment 20 Len DiMaggio 2007-12-11 13:59:59 UTC
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.

Comment 21 Kevin Conner 2007-12-17 04:47:17 UTC
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.

Comment 22 Len DiMaggio 2008-01-04 15:30:55 UTC
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"/>



Comment 23 Kevin Conner 2008-01-04 16:21:31 UTC
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.

Comment 24 Len DiMaggio 2008-01-04 17:20:18 UTC
Verified in the beta1 build.

Comment 25 Len DiMaggio 2008-01-06 01:03:36 UTC
Link: Removed: This issue related SOA-84 


Comment 26 Julian Coleman 2008-07-01 15:28:09 UTC
Link: Added: This issue related SOA-616


Comment 27 nwallace 2008-09-25 18:55:27 UTC
Link: Added: This issue related SOA-847