[JBoss JIRA] (AS7-6822) standalone.bat has an error for setting debug mode with --debug
by James Perkins (JIRA)
James Perkins created AS7-6822:
----------------------------------
Summary: standalone.bat has an error for setting debug mode with --debug
Key: AS7-6822
URL: https://issues.jboss.org/browse/AS7-6822
Project: Application Server 7
Issue Type: Bug
Components: Scripts
Reporter: James Perkins
Assignee: James Perkins
Priority: Minor
Fix For: 8.0.0.Alpha1
In the released EAP 6.1.0-alpha, standalone.bat has these lines:
{code}
rem Set debug settings if not already set
if "%DEBUG_MODE%" == "true" (
echo "%JAVA_OPTS%" | findstr /I "\-agentlib:jdwp" > nul
if errorlevel == 1 (
echo Debug already enabled in JAVA_OPTS, ignoring --debug argument
) else (
set "JAVA_OPTS=%JAVA_OPTS% -agentlib:jdwp=transport=dt_socket,address=%DEBUG_PORT%,server=y,suspend=n"
)
)
{code}
The check on the error level is wrong. If "findstr" *can* find the agentlib setting, then errorlevel will be 0.
So the correction is:
{code}
if errorlevel == 1 (
{code}
should be:
{code}
if errorlevel == 0 (
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (AS7-6727) Modular build not in sync with modules directory structure
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6727?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6727:
----------------------------------------------
Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 947145|https://bugzilla.redhat.com/show_bug.cgi?id=947145] from NEW to POST
> Modular build not in sync with modules directory structure
> ----------------------------------------------------------
>
> Key: AS7-6727
> URL: https://issues.jboss.org/browse/AS7-6727
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Labels: Karaf
>
> {code}
> [echo] Static modules: [org.jboss.as.standalone,org.jboss.as.domain-http-error-context,,, org.jboss.logging, org.jboss.vfs, org.slf4j, org.jboss.logging.jul-to-slf4j-stub]
> [java] Exception in thread "main" java.io.FileNotFoundException: /Users/tdiesler/git/jboss-as/build-modular/../build/src/main/resources/modules/org/jboss/as/logging/main/module.xml (No such file or directory)
> [java] at java.io.FileInputStream.open(Native Method)
> [java] at java.io.FileInputStream.<init>(FileInputStream.java:138)
> [java] at org.jboss.as.config.assembly.ModuleParser.parse(ModuleParser.java:61)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.processModuleDependency(GenerateModulesDefinition.java:193)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.process(GenerateModulesDefinition.java:130)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.main(GenerateModulesDefinition.java:104)
> [java] Java Result: 1
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (AS7-6727) Modular build not in sync with modules directory structure
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6727?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6727:
----------------------------------------------
Brian Stansberry <brian.stansberry(a)redhat.com> made a comment on [bug 947145|https://bugzilla.redhat.com/show_bug.cgi?id=947145]
The EAP 6 and AS7 codebase includes a facility for building a specialized variant of the server distribution by activating special maven profiles when building the server. The use case in community is to build specialized osgi-oriented distributions. The basic goal is to allow building of smaller filesystem footprint distributions (e.g. with few modules) for specialized cases.
This facility was broken by the change in the structure of the modules directory that was made in 6.1.0.Alpha1 to meet the layered product needs.
I'm not aware of any use of this facility in EAP itself, but it should be fixed since the fix is available in a pull request and it does not impact the standard EAP distribution.
> Modular build not in sync with modules directory structure
> ----------------------------------------------------------
>
> Key: AS7-6727
> URL: https://issues.jboss.org/browse/AS7-6727
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Labels: Karaf
>
> {code}
> [echo] Static modules: [org.jboss.as.standalone,org.jboss.as.domain-http-error-context,,, org.jboss.logging, org.jboss.vfs, org.slf4j, org.jboss.logging.jul-to-slf4j-stub]
> [java] Exception in thread "main" java.io.FileNotFoundException: /Users/tdiesler/git/jboss-as/build-modular/../build/src/main/resources/modules/org/jboss/as/logging/main/module.xml (No such file or directory)
> [java] at java.io.FileInputStream.open(Native Method)
> [java] at java.io.FileInputStream.<init>(FileInputStream.java:138)
> [java] at org.jboss.as.config.assembly.ModuleParser.parse(ModuleParser.java:61)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.processModuleDependency(GenerateModulesDefinition.java:193)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.process(GenerateModulesDefinition.java:130)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.main(GenerateModulesDefinition.java:104)
> [java] Java Result: 1
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (AS7-6727) Modular build not in sync with modules directory structure
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6727?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration updated AS7-6727:
-----------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=947145
> Modular build not in sync with modules directory structure
> ----------------------------------------------------------
>
> Key: AS7-6727
> URL: https://issues.jboss.org/browse/AS7-6727
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Labels: Karaf
>
> {code}
> [echo] Static modules: [org.jboss.as.standalone,org.jboss.as.domain-http-error-context,,, org.jboss.logging, org.jboss.vfs, org.slf4j, org.jboss.logging.jul-to-slf4j-stub]
> [java] Exception in thread "main" java.io.FileNotFoundException: /Users/tdiesler/git/jboss-as/build-modular/../build/src/main/resources/modules/org/jboss/as/logging/main/module.xml (No such file or directory)
> [java] at java.io.FileInputStream.open(Native Method)
> [java] at java.io.FileInputStream.<init>(FileInputStream.java:138)
> [java] at org.jboss.as.config.assembly.ModuleParser.parse(ModuleParser.java:61)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.processModuleDependency(GenerateModulesDefinition.java:193)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.process(GenerateModulesDefinition.java:130)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.main(GenerateModulesDefinition.java:104)
> [java] Java Result: 1
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (AS7-6821) Installed library not available to an EAR deployment
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/AS7-6821?page=com.atlassian.jira.plugin.s... ]
Jozef Hartinger commented on AS7-6821:
--------------------------------------
Testcase https://github.com/jbossas/jboss-as/pull/4308
> Installed library not available to an EAR deployment
> ----------------------------------------------------
>
> Key: AS7-6821
> URL: https://issues.jboss.org/browse/AS7-6821
> Project: Application Server 7
> Issue Type: Bug
> Components: EE
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Reporter: Jozef Hartinger
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha1
>
>
> {quote}The referenced libraries must be made available to all components contained within the referencing file, including any components contained within other JAR format files within the referencing file. For example, if a .ear file references an installed library, the library must be made available to all components in all .war files, EJB .jar files, application .jar files, and resource adapter .rar files within the .ear file.{quote}
> A referenced installed library seems to only be made available to some (not all) components in an EAR.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (AS7-6821) Installed library not available to an EAR deployment
by Jozef Hartinger (JIRA)
Jozef Hartinger created AS7-6821:
------------------------------------
Summary: Installed library not available to an EAR deployment
Key: AS7-6821
URL: https://issues.jboss.org/browse/AS7-6821
Project: Application Server 7
Issue Type: Bug
Components: EE
Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
Reporter: Jozef Hartinger
Assignee: Stuart Douglas
Fix For: 8.0.0.Alpha1
{quote}The referenced libraries must be made available to all components contained within the referencing file, including any components contained within other JAR format files within the referencing file. For example, if a .ear file references an installed library, the library must be made available to all components in all .war files, EJB .jar files, application .jar files, and resource adapter .rar files within the .ear file.{quote}
A referenced installed library seems to only be made available to some (not all) components in an EAR.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (AS7-6779) AS7.1 jars run against as7.2/eap6.1 cause test case (eclipse) to hang
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6779?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6779:
----------------------------------------------
Jason T. Greene <jason.greene(a)redhat.com> made a comment on [bug 927318|https://bugzilla.redhat.com/show_bug.cgi?id=927318]
Need acks to merge the fix
> AS7.1 jars run against as7.2/eap6.1 cause test case (eclipse) to hang
> ---------------------------------------------------------------------
>
> Key: AS7-6779
> URL: https://issues.jboss.org/browse/AS7-6779
> Project: Application Server 7
> Issue Type: Bug
> Components: Remoting
> Reporter: Rob Stryker
> Assignee: Emanuel Muckenhuber
> Priority: Blocker
> Attachments: AS7-6779.out2.txt, AS7-6779.stack.txt, out.zip
>
>
> Somewhere along the line recently, EAP6.1 / AS 7.2 has a regression in remoting or xnio somehow, and this is causing blocking problems for tools.
> Recall:
> 1) JBossTools bundles a set of jars capable of communicating with a running application server
> 2) This single set of jars must be capable of communicating with all servers in the 7.x stream
> 3) Bundling a second set of jars is not easily accomplished, but could be possible
> And:
> 4) Using the as7.1.0 jars against eap6.1 in a specific unit test causes eclipse to hang
> The basic code of our test case (once we get rid of the jbt stuff wrapped around it) is basically as follows:
> {code}
> this.client = ModelControllerClient.Factory.create(details.getHost(), details.getManagementPort(),
> getCallbackHandler());
> this.manager = ServerDeploymentManager.Factory.create(client);
> DeploymentPlanBuilder builder = manager.newDeploymentPlan().replace(name, file);
> try {
> DeploymentAction action = builder.getLastAction();
> Future<ServerDeploymentPlanResult> planResult = manager.execute(builder.build());
> // FREEZE HERE
> // This is "DeploymentOperationResult.getStatus() in the stack trace
> ServerDeploymentActionResult actionResult = planResult.get().getDeploymentActionResult(action.getId());
> IStatus status = createStatus(action.getDeploymentUnitUniqueName(), action.getType().name(), actionResult);
> } catch (Exception e) {
> throw new JBoss7ManangerException(e);
> }
> {code}
> The actual stack trace is:
> {code}
> Thread [main] (Suspended)
> owns: RunnableLock (id=461)
> waiting for: ActiveOperationSupport$ActiveOperationImpl<T,A> (id=462)
> Object.wait(long) line: not available [native method]
> ActiveOperationSupport$ActiveOperationImpl<T,A>(Object).wait() line: 503
> ActiveOperationSupport$ActiveOperationImpl<T,A>(AsyncFutureTask<T>).await() line: 192
> ActiveOperationSupport$ActiveOperationImpl<T,A>(AsyncFutureTask<T>).get() line: 266
> AbstractModelControllerClient$DelegatingCancellableAsyncFuture.get() line: 363
> AbstractModelControllerClient$DelegatingCancellableAsyncFuture.get() line: 317
> ServerDeploymentPlanResultFuture.get() line: 76
> ServerDeploymentPlanResultFuture.get() line: 42
> DeploymentOperationResult.getStatus() line: 52
> AS7ManagerTestUtils.waitUntilFinished(IJBoss7DeploymentResult) line: 93
> AS7ManagerIntegrationTest.canReplaceWar() line: 129
> {code}
> The list of jars we are using to communicate with the server are:
> {code}
> jboss-as-controller-client-7.1.0.Final.jar
> jboss-as-protocol-7.1.0.Final.jar
> jboss-dmr-1.1.1.Final.jar
> jboss-logging-3.1.0.GA.jar
> jboss-marshalling-1.3.9.GA.jar
> jboss-remoting-3.2.7.GA.jar
> jboss-sasl-1.0.0.Final.jar
> jboss-threads-2.0.0.GA.jar
> xnio-api-3.0.3.GA.jar
> xnio-nio-3.0.3.GA.jar
> {code}
> It was suggested in irc by ctomc that we simply replace the following jars with new jars from jboss-as 7.2 / eap6.1:
> {code}
> jboss-remoting-3.2.7.GA.jar -> 3.2.15.GA
> xnio-api-3.0.3.GA.jar -> 3.0.7
> xnio-nio-3.0.3.GA.jar -> 3.0.7
> {code}
> This approach also failed, with the following stack trace:
> {code}
> java.lang.NoClassDefFoundError: org/xnio/Cancellable
> (sic)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.<init>(RemotingModelControllerClient.java:59)
> at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:211)
> at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:173)
> {code}
> So it is obvious that jboss-as-controller jar from as-7.1 requires classes that are no longer present in xnio. If this is the case, it would indicate that xnio has REMOVED classes from its jar during an incremental version from 3.0.3 to 3.0.7, which would constitute an API breakage.
> So clearly for us, updating only remoting and xnio does not work. The next possible solution would be to update ALL jars, however, this led to a similar situation when using AS7.2 / Eap 6.1 jars to communicate with an AS 7.0.0 server. Again, similar to what was mentioned above, all tests passed EXCEPT the test above. The test above failed with an almost identical stack trace:
> {code}
> Thread [main] (Suspended)
> owns: RunnableLock (id=160)
> waiting for: ActiveOperationSupport$ActiveOperationImpl<T,A> (id=161)
> Object.wait(long) line: not available [native method]
> ActiveOperationSupport$ActiveOperationImpl<T,A>(Object).wait() line: 503
> ActiveOperationSupport$ActiveOperationImpl<T,A>(AsyncFutureTask<T>).await() line: 192
> ActiveOperationSupport$ActiveOperationImpl<T,A>(AsyncFutureTask<T>).get() line: 266
> AbstractModelControllerClient$DelegatingCancellableAsyncFuture(AbstractDelegatingAsyncFuture<T>).get() line: 100
> ServerDeploymentPlanResultFuture.get() line: 76
> ServerDeploymentPlanResultFuture.get() line: 42
> DeploymentOperationResult.getStatus() line: 52
> AS7ManagerTestUtils.waitUntilFinished(IJBoss7DeploymentResult) line: 93
> AS7ManagerTestUtils.quietlyUndeploy(String, AS71Manager) line: 76
> AS7ManagerIntegrationTest.canReplaceWar() line: 135
> {code}
> No matter how you look at it, the contract has been broken. JBossTools now is looking for a specific set of jars which care capable of communicating with AS7.0, 7.1, 7.2, eap6.0, 6.1, jpp6.0, etc. Without a set of jars that can communicate with all of these servers, our tools will need to implement drastic workarounds or bundle several versions of the app server's jars within it.
> It's interesting to me that the as7.1 jars work against everything except eap6.1, and yet, the eap6.1 jars work against everything except as7.0.0.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (AS7-6779) AS7.1 jars run against as7.2/eap6.1 cause test case (eclipse) to hang
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6779?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6779:
----------------------------------------------
Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 927318|https://bugzilla.redhat.com/show_bug.cgi?id=927318] from NEW to POST
> AS7.1 jars run against as7.2/eap6.1 cause test case (eclipse) to hang
> ---------------------------------------------------------------------
>
> Key: AS7-6779
> URL: https://issues.jboss.org/browse/AS7-6779
> Project: Application Server 7
> Issue Type: Bug
> Components: Remoting
> Reporter: Rob Stryker
> Assignee: Emanuel Muckenhuber
> Priority: Blocker
> Attachments: AS7-6779.out2.txt, AS7-6779.stack.txt, out.zip
>
>
> Somewhere along the line recently, EAP6.1 / AS 7.2 has a regression in remoting or xnio somehow, and this is causing blocking problems for tools.
> Recall:
> 1) JBossTools bundles a set of jars capable of communicating with a running application server
> 2) This single set of jars must be capable of communicating with all servers in the 7.x stream
> 3) Bundling a second set of jars is not easily accomplished, but could be possible
> And:
> 4) Using the as7.1.0 jars against eap6.1 in a specific unit test causes eclipse to hang
> The basic code of our test case (once we get rid of the jbt stuff wrapped around it) is basically as follows:
> {code}
> this.client = ModelControllerClient.Factory.create(details.getHost(), details.getManagementPort(),
> getCallbackHandler());
> this.manager = ServerDeploymentManager.Factory.create(client);
> DeploymentPlanBuilder builder = manager.newDeploymentPlan().replace(name, file);
> try {
> DeploymentAction action = builder.getLastAction();
> Future<ServerDeploymentPlanResult> planResult = manager.execute(builder.build());
> // FREEZE HERE
> // This is "DeploymentOperationResult.getStatus() in the stack trace
> ServerDeploymentActionResult actionResult = planResult.get().getDeploymentActionResult(action.getId());
> IStatus status = createStatus(action.getDeploymentUnitUniqueName(), action.getType().name(), actionResult);
> } catch (Exception e) {
> throw new JBoss7ManangerException(e);
> }
> {code}
> The actual stack trace is:
> {code}
> Thread [main] (Suspended)
> owns: RunnableLock (id=461)
> waiting for: ActiveOperationSupport$ActiveOperationImpl<T,A> (id=462)
> Object.wait(long) line: not available [native method]
> ActiveOperationSupport$ActiveOperationImpl<T,A>(Object).wait() line: 503
> ActiveOperationSupport$ActiveOperationImpl<T,A>(AsyncFutureTask<T>).await() line: 192
> ActiveOperationSupport$ActiveOperationImpl<T,A>(AsyncFutureTask<T>).get() line: 266
> AbstractModelControllerClient$DelegatingCancellableAsyncFuture.get() line: 363
> AbstractModelControllerClient$DelegatingCancellableAsyncFuture.get() line: 317
> ServerDeploymentPlanResultFuture.get() line: 76
> ServerDeploymentPlanResultFuture.get() line: 42
> DeploymentOperationResult.getStatus() line: 52
> AS7ManagerTestUtils.waitUntilFinished(IJBoss7DeploymentResult) line: 93
> AS7ManagerIntegrationTest.canReplaceWar() line: 129
> {code}
> The list of jars we are using to communicate with the server are:
> {code}
> jboss-as-controller-client-7.1.0.Final.jar
> jboss-as-protocol-7.1.0.Final.jar
> jboss-dmr-1.1.1.Final.jar
> jboss-logging-3.1.0.GA.jar
> jboss-marshalling-1.3.9.GA.jar
> jboss-remoting-3.2.7.GA.jar
> jboss-sasl-1.0.0.Final.jar
> jboss-threads-2.0.0.GA.jar
> xnio-api-3.0.3.GA.jar
> xnio-nio-3.0.3.GA.jar
> {code}
> It was suggested in irc by ctomc that we simply replace the following jars with new jars from jboss-as 7.2 / eap6.1:
> {code}
> jboss-remoting-3.2.7.GA.jar -> 3.2.15.GA
> xnio-api-3.0.3.GA.jar -> 3.0.7
> xnio-nio-3.0.3.GA.jar -> 3.0.7
> {code}
> This approach also failed, with the following stack trace:
> {code}
> java.lang.NoClassDefFoundError: org/xnio/Cancellable
> (sic)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.<init>(RemotingModelControllerClient.java:59)
> at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:211)
> at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:173)
> {code}
> So it is obvious that jboss-as-controller jar from as-7.1 requires classes that are no longer present in xnio. If this is the case, it would indicate that xnio has REMOVED classes from its jar during an incremental version from 3.0.3 to 3.0.7, which would constitute an API breakage.
> So clearly for us, updating only remoting and xnio does not work. The next possible solution would be to update ALL jars, however, this led to a similar situation when using AS7.2 / Eap 6.1 jars to communicate with an AS 7.0.0 server. Again, similar to what was mentioned above, all tests passed EXCEPT the test above. The test above failed with an almost identical stack trace:
> {code}
> Thread [main] (Suspended)
> owns: RunnableLock (id=160)
> waiting for: ActiveOperationSupport$ActiveOperationImpl<T,A> (id=161)
> Object.wait(long) line: not available [native method]
> ActiveOperationSupport$ActiveOperationImpl<T,A>(Object).wait() line: 503
> ActiveOperationSupport$ActiveOperationImpl<T,A>(AsyncFutureTask<T>).await() line: 192
> ActiveOperationSupport$ActiveOperationImpl<T,A>(AsyncFutureTask<T>).get() line: 266
> AbstractModelControllerClient$DelegatingCancellableAsyncFuture(AbstractDelegatingAsyncFuture<T>).get() line: 100
> ServerDeploymentPlanResultFuture.get() line: 76
> ServerDeploymentPlanResultFuture.get() line: 42
> DeploymentOperationResult.getStatus() line: 52
> AS7ManagerTestUtils.waitUntilFinished(IJBoss7DeploymentResult) line: 93
> AS7ManagerTestUtils.quietlyUndeploy(String, AS71Manager) line: 76
> AS7ManagerIntegrationTest.canReplaceWar() line: 135
> {code}
> No matter how you look at it, the contract has been broken. JBossTools now is looking for a specific set of jars which care capable of communicating with AS7.0, 7.1, 7.2, eap6.0, 6.1, jpp6.0, etc. Without a set of jars that can communicate with all of these servers, our tools will need to implement drastic workarounds or bundle several versions of the app server's jars within it.
> It's interesting to me that the as7.1 jars work against everything except eap6.1, and yet, the eap6.1 jars work against everything except as7.0.0.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months