[JBoss JIRA] (DROOLS-496) Rules in Drools 6.x cannot use more than 64 patterns
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-496?page=com.atlassian.jira.plugin... ]
Davide Sottara commented on DROOLS-496:
---------------------------------------
A rule that requires more than 64 patterns is usually suspicious.. unless it's a very peculiar use case, there are normally ways to re-engineer the logic to simplify the rule, as you did.
As for the performance comparison, there's no definitive answer to that question.. The actual performance of the engine depends on the combination of rules and the facts, so any average statistics may be quite different - for good or for bad - from your use case. On the other hand, you can easily do a comparison - switching from one engine to the other takes two lines of code.
Please also consider that the rete-oo mode is considered deprecated and may no longer be supported in the future. However, we won't drop the rete-oo mode until this limitation is addressed.
> Rules in Drools 6.x cannot use more than 64 patterns
> ----------------------------------------------------
>
> Key: DROOLS-496
> URL: https://issues.jboss.org/browse/DROOLS-496
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.Beta1
> Reporter: Jörgen Risholt
> Assignee: Mark Proctor
> Priority: Blocker
> Attachments: drools-test_5.6.0.tar, drools-test_6.0.1.tar
>
>
> When trying a script as shown below we can not get it to work with 6.0.1 but with 5.6.0. There seems to be some relation to the number of facts, the more facts the higher probablity that the 6.0.1 version do not trigger. We have made two simple singelthreaded scenarios that I can upload if wanted.
> The examle has a lot of facts, but we notice that from about 50 it seems that the problam may occur.
> rule "TestRule"
> Person(name == "Name0")
> Person(name == "Name1")
> ....
> Person(name == "Name1000")
> then
> System.out.println("Successfully trigged");
> end
> This is the testcode for 5.6.0.Final (work always):
> package drools_test;
> import org.drools.KnowledgeBase;
> import org.drools.builder.KnowledgeBuilder;
> import org.drools.builder.KnowledgeBuilderFactory;
> import org.drools.builder.ResourceType;
> import org.drools.io.ResourceFactory;
> import org.drools.runtime.StatefulKnowledgeSession;
> import drools_test.data.Person;
> public class App {
> private final static int NUMBER_OF_PERSONS = 3000;
> public static void main(String[] args) {
> KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
> kbuilder.add(ResourceFactory.newClassPathResource("rules.drl",
> App.class), ResourceType.DRL);
> KnowledgeBase kb = kbuilder.newKnowledgeBase();
> StatefulKnowledgeSession session = null;
> try {
> session = kb.newStatefulKnowledgeSession();
> for (int i = 0; i < NUMBER_OF_PERSONS; ++i) {
> session.insert(new Person(String.format("Name%s", i)));
> session.fireAllRules();
> }
> session.fireAllRules();
> } finally {
> if (session != null) {
> session.dispose();
> }
> }
> }
> }
> And this is the same code for 6.0.1.Final which always fails:
> package drools_test;
> import org.kie.api.KieServices;
> import org.kie.api.runtime.KieContainer;
> import org.kie.api.runtime.KieSession;
> import drools_test.data.Person;
> public class App
> {
> private final static int NUMBER_OF_PERSONS = 3000;
> public static void main(String[] args)
> {
> KieServices kieServices = KieServices.Factory.get();
> KieContainer kContainer = kieServices.getKieClasspathContainer();
> KieSession session = null;
> try {
> session = kContainer.newKieSession();
> for (int i = 0; i < NUMBER_OF_PERSONS; ++i) {
> session.insert(new Person(String.format("Name%s", i)));
> session.fireAllRules(); // Comment out this line and the rule will fire.
> }
> session.fireAllRules();
> } finally {
> if (session != null) {
> session.dispose();
> }
> }
> }
> }
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3722) IOException: Broken pipe thrown when using RichFaces with Atmosphere 2.2.0
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3722?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-3722:
--------------------------------------
So this is basically a logging problem, generally IOException is logged at DEBUG, but in this case it is not. The underlying exception would just be caused by the long polling connection being closed. This should be fixed with the next undertow update.
> IOException: Broken pipe thrown when using RichFaces with Atmosphere 2.2.0
> --------------------------------------------------------------------------
>
> Key: WFLY-3722
> URL: https://issues.jboss.org/browse/WFLY-3722
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Reporter: Brian Leathem
> Assignee: Stuart Douglas
>
> While working on RF-13753 I upgraded the RichFaces Atmosphere dependency from 1.0.x to 2.2.0. All is functional after the upgrade except an IOException is thrown when I navigate away from a page using Atmosphere (via the RichFaces push component).
> The stacktrace looks like:
> {code}
> 16:35:27,083 ERROR [stderr] (default task-39) Exception in thread "default task-39" java.lang.RuntimeException: java.io.IOException: Broken pipe
> 16:35:27,083 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:527)
> 16:35:27,083 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.AsyncContextImpl$3.run(AsyncContextImpl.java:294)
> 16:35:27,083 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.AsyncContextImpl$6.run(AsyncContextImpl.java:432)
> 16:35:27,083 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(AsyncContextImpl.java:517)
> 16:35:27,084 ERROR [stderr] (default task-39) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 16:35:27,084 ERROR [stderr] (default task-39) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 16:35:27,084 ERROR [stderr] (default task-39) at java.lang.Thread.run(Thread.java:745)
> 16:35:27,084 ERROR [stderr] (default task-39) Caused by: java.io.IOException: Broken pipe
> 16:35:27,084 ERROR [stderr] (default task-39) at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> 16:35:27,084 ERROR [stderr] (default task-39) at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
> 16:35:27,084 ERROR [stderr] (default task-39) at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> 16:35:27,085 ERROR [stderr] (default task-39) at sun.nio.ch.IOUtil.write(IOUtil.java:65)
> 16:35:27,085 ERROR [stderr] (default task-39) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487)
> 16:35:27,085 ERROR [stderr] (default task-39) at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150)
> 16:35:27,085 ERROR [stderr] (default task-39) at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:531)
> 16:35:27,085 ERROR [stderr] (default task-39) at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:256)
> 16:35:27,085 ERROR [stderr] (default task-39) at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> 16:35:27,085 ERROR [stderr] (default task-39) at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100)
> 16:35:27,085 ERROR [stderr] (default task-39) at org.xnio.channels.Channels.flushBlocking(Channels.java:63)
> 16:35:27,085 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:625)
> 16:35:27,085 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:451)
> 16:35:27,086 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:525)
> 16:35:27,086 ERROR [stderr] (default task-39) ... 6 more
> {code}
> There are no richfaces not atmosphere classes in the stacktrace, so I'm not sure how to narrow the problem down.
> A reproducer can be found by building RichFaces from the branch:
> https://github.com/richfaces/richfaces/tree/RF-13753-upgrade-atmosphere
> and deploying the showcase. The push component sample triggers the error when you navigate away from the page:
> http://localhost:8080/showcase/richfaces/component-sample.jsf?demo=push&s...
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3722) IOException: Broken pipe thrown when using RichFaces with Atmosphere 2.2.0
by Brian Leathem (JIRA)
Brian Leathem created WFLY-3722:
-----------------------------------
Summary: IOException: Broken pipe thrown when using RichFaces with Atmosphere 2.2.0
Key: WFLY-3722
URL: https://issues.jboss.org/browse/WFLY-3722
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Undertow)
Reporter: Brian Leathem
Assignee: Stuart Douglas
While working on RF-13753 I upgraded the RichFaces Atmosphere dependency from 1.0.x to 2.2.0. All is functional after the upgrade except an IOException is thrown when I navigate away from a page using Atmosphere (via the RichFaces push component).
The stacktrace looks like:
{code}
16:35:27,083 ERROR [stderr] (default task-39) Exception in thread "default task-39" java.lang.RuntimeException: java.io.IOException: Broken pipe
16:35:27,083 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:527)
16:35:27,083 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.AsyncContextImpl$3.run(AsyncContextImpl.java:294)
16:35:27,083 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.AsyncContextImpl$6.run(AsyncContextImpl.java:432)
16:35:27,083 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(AsyncContextImpl.java:517)
16:35:27,084 ERROR [stderr] (default task-39) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
16:35:27,084 ERROR [stderr] (default task-39) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
16:35:27,084 ERROR [stderr] (default task-39) at java.lang.Thread.run(Thread.java:745)
16:35:27,084 ERROR [stderr] (default task-39) Caused by: java.io.IOException: Broken pipe
16:35:27,084 ERROR [stderr] (default task-39) at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
16:35:27,084 ERROR [stderr] (default task-39) at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
16:35:27,084 ERROR [stderr] (default task-39) at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
16:35:27,085 ERROR [stderr] (default task-39) at sun.nio.ch.IOUtil.write(IOUtil.java:65)
16:35:27,085 ERROR [stderr] (default task-39) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487)
16:35:27,085 ERROR [stderr] (default task-39) at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150)
16:35:27,085 ERROR [stderr] (default task-39) at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:531)
16:35:27,085 ERROR [stderr] (default task-39) at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:256)
16:35:27,085 ERROR [stderr] (default task-39) at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
16:35:27,085 ERROR [stderr] (default task-39) at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100)
16:35:27,085 ERROR [stderr] (default task-39) at org.xnio.channels.Channels.flushBlocking(Channels.java:63)
16:35:27,085 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:625)
16:35:27,085 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:451)
16:35:27,086 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:525)
16:35:27,086 ERROR [stderr] (default task-39) ... 6 more
{code}
There are no richfaces not atmosphere classes in the stacktrace, so I'm not sure how to narrow the problem down.
A reproducer can be found by building RichFaces from the branch:
https://github.com/richfaces/richfaces/tree/RF-13753-upgrade-atmosphere
and deploying the showcase. The push component sample triggers the error when you navigate away from the page:
http://localhost:8080/showcase/richfaces/component-sample.jsf?demo=push&s...
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3464) Nonexistent ldap group causes authentication to fail in security-realm
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3464?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-3464:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1105677, https://bugzilla.redhat.com/show_bug.cgi?id=1105619, https://bugzilla.redhat.com/show_bug.cgi?id=1127938 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1105677)
> Nonexistent ldap group causes authentication to fail in security-realm
> -----------------------------------------------------------------------
>
> Key: WFLY-3464
> URL: https://issues.jboss.org/browse/WFLY-3464
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.1.0.Final
> Reporter: Derek Horton
> Assignee: Darran Lofthouse
>
> The LdapGroupSearcher code will fail if it tries to lookup a group that
> does not exist on the local ldap server.
> This can happen when the ldap systems are configured as trusted domains.
> Even though the security-realm is not configured to use the trusted domain
> (it is configured to only look at a single ldap server), the
> user's entry on one ldap server could point at a group that exists on
> the other (trusted) ldap server.
> The LdapGroupSearcher code attempts to lookup this role and it fails. This
> failure is sent back to the http server which results in an HTTP 500 error
> and leaves the user with no way to authenticate/login.
> There is currently not a way to tell the group searcher code to ignore the
> group/role that cannot be found.
> 2014-06-06 12:44:39,819 TRACE [org.jboss.as.domain.management.security] (XNIO-1 task-1) Group found with distinguishedName=cn=TestManagedRole,ou=People,dc=my-ds-domain,dc=com
> 2014-06-06 12:44:39,821 TRACE [org.jboss.as.domain.management.security] (XNIO-1 task-1) Failure supplementing Subject: javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object]; remaining name 'cn=TestManagedRole,ou=People,dc=my-ds-domain,dc=com'
> at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3112) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3033) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2840) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.c_getAttributes(LdapCtx.java:1332) [rt.jar:1.7.0_45]
> at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:231) [rt.jar:1.7.0_45]
> at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:139) [rt.jar:1.7.0_45]
> at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:127) [rt.jar:1.7.0_45]
> at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.7.0_45]
> at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.7.0_45]
> at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:256) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:191) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:223) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroupEntries(LdapSubjectSupplementalService.java:218) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:195) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:188) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.supplementSubject(LdapSubjectSupplementalService.java:163) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.SecurityRealmService$1.createSubjectUserInfo(SecurityRealmService.java:200) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:155) [wildfly-domain-http-interface-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:120) [wildfly-domain-http-interface-8.1.0.Final.jar:8.1.0.Final]
> at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:110) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:57) [wildfly-domain-http-interface-8.1.0.Final.jar:8.1.0.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3721) CommandDispatcher hides exceptions
by Rich DiCroce (JIRA)
Rich DiCroce created WFLY-3721:
----------------------------------
Summary: CommandDispatcher hides exceptions
Key: WFLY-3721
URL: https://issues.jboss.org/browse/WFLY-3721
Project: WildFly
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: 8.1.0.Final
Reporter: Rich DiCroce
Assignee: Paul Ferraro
The implementations of CommandDispatcher#submitOnCluster and #executeOnCluster completely hide any exceptions that occur while trying to send the command. This makes it very difficult to debug things like serialization exceptions. (Note: In the 8.x branch, the implementation is in ServiceCommandDispatcher. In master, it has moved to ChannelCommandDispatcher, but the code is essentially the same and the issue still exists.)
Instead of hiding the exception, the implementation should expose the exception to the developer in some way. A couple possibilities:
- Don't catch the exception.
- Catch the exception and return a Map with one entry, where the key is the local node and the value is a Future or CommandResponse that contains the exception.
- Catch the exception and return an empty map, but also log the exception.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBASMP-70) Hard deploy is not supported
by Amal Jose (JIRA)
[ https://issues.jboss.org/browse/JBASMP-70?page=com.atlassian.jira.plugin.... ]
Amal Jose updated JBASMP-70:
----------------------------
Description:
In Jboss 5 days we used to use a different plugin - which supports jboss hard -deploy i.e it copies the war to location where deployement scaner of jboss is searching a war...advantage of this particular implementation is that JBOSS need not be up for the plugin to run - once the jboss is up, it will take up the war..
The current implementation does support soft deploy using JBOSS Management API..but there is no hard-deploy goal that used to be supported in JBOSS 5 plugins like http://mojo.codehaus.org/jboss-maven-plugin
Reducing priority as this is possible using other plugins like antrun of maven...
But can JBOSS AS MAVEN plugin support hard deploy (offline Deploy-where jboss instance is not running)
Some online discussions regarding same : http://stackoverflow.com/questions/22936893/jboss-7-x-redeploy-option
was:
In Jboss 5 days we used to use a different plugin - which supports jboss hard -deploy i.e it copies the war to location where deployement scaner of jboss is searching a war...advantage of this particular implementation is that JBOSS need not be up for the plugin to run - once the jboss is up, it will take up the war..
The current implementation does support soft deploy using JBOSS Management API..but there is no hard-deploy goal that used to be supported in JBOSS 5 plugins like http://mojo.codehaus.org/jboss-maven-plugin
Reducing priority as this is possible using other plugins like antrun of maven...
But can JBOSS AS MAVEN plugin support hard deploy (offline Deploy-where jboss instance is not running)
> Hard deploy is not supported
> ----------------------------
>
> Key: JBASMP-70
> URL: https://issues.jboss.org/browse/JBASMP-70
> Project: JBoss AS Maven Plugins
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Amal Jose
> Assignee: James Perkins
> Priority: Minor
>
> In Jboss 5 days we used to use a different plugin - which supports jboss hard -deploy i.e it copies the war to location where deployement scaner of jboss is searching a war...advantage of this particular implementation is that JBOSS need not be up for the plugin to run - once the jboss is up, it will take up the war..
> The current implementation does support soft deploy using JBOSS Management API..but there is no hard-deploy goal that used to be supported in JBOSS 5 plugins like http://mojo.codehaus.org/jboss-maven-plugin
> Reducing priority as this is possible using other plugins like antrun of maven...
> But can JBOSS AS MAVEN plugin support hard deploy (offline Deploy-where jboss instance is not running)
> Some online discussions regarding same : http://stackoverflow.com/questions/22936893/jboss-7-x-redeploy-option
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBASMP-70) Hard deploy is not supported
by Amal Jose (JIRA)
[ https://issues.jboss.org/browse/JBASMP-70?page=com.atlassian.jira.plugin.... ]
Amal Jose updated JBASMP-70:
----------------------------
Description:
In Jboss 5 days we used to use a different plugin - which supports jboss hard -deploy i.e it copies the war to location where deployement scaner of jboss is searching a war...advantage of this particular implementation is that JBOSS need not be up for the plugin to run - once the jboss is up, it will take up the war..
The current implementation does support soft deploy using JBOSS Management API..but there is no hard-deploy goal that used to be supported in JBOSS 5 plugins like http://mojo.codehaus.org/jboss-maven-plugin
Reducing priority as this is possible using other plugins like antrun of maven...
But can JBOSS AS MAVEN plugin support hard deploy (offline Deploy-where jboss instance is not running)
was:
In Jboss 5 days we used to use a different plugin - which supports jboss hard -deploy i.e it copies the war to location where deployement scaner of jboss is searching a war...advantage of this particular implementation is that JBOSS need not be up for the plugin to run - once the jboss is up, it will take up the war..
The current implementation does support soft deploy using JBOSS Management API..but there is no hard-deploy goal that used to supported in JBOSS 5 plugins like http://mojo.codehaus.org/jboss-maven-plugin
Reducing priority as this is possible using other plugins like antrun of maven...But can JBOSS AS MAVEN plugin support hard deploy (offline Deploy-where jboss instance is not running)
> Hard deploy is not supported
> ----------------------------
>
> Key: JBASMP-70
> URL: https://issues.jboss.org/browse/JBASMP-70
> Project: JBoss AS Maven Plugins
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Amal Jose
> Assignee: James Perkins
> Priority: Minor
>
> In Jboss 5 days we used to use a different plugin - which supports jboss hard -deploy i.e it copies the war to location where deployement scaner of jboss is searching a war...advantage of this particular implementation is that JBOSS need not be up for the plugin to run - once the jboss is up, it will take up the war..
> The current implementation does support soft deploy using JBOSS Management API..but there is no hard-deploy goal that used to be supported in JBOSS 5 plugins like http://mojo.codehaus.org/jboss-maven-plugin
> Reducing priority as this is possible using other plugins like antrun of maven...
> But can JBOSS AS MAVEN plugin support hard deploy (offline Deploy-where jboss instance is not running)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBASMP-70) Hard deploy is not supported
by Amal Jose (JIRA)
Amal Jose created JBASMP-70:
-------------------------------
Summary: Hard deploy is not supported
Key: JBASMP-70
URL: https://issues.jboss.org/browse/JBASMP-70
Project: JBoss AS Maven Plugins
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Amal Jose
Assignee: James Perkins
Priority: Minor
In Jboss 5 days we used to use a different plugin - which supports jboss hard -deploy i.e it copies the war to location where deployement scaner of jboss is searching a war...advantage of this particular implementation is that JBOSS need not be up for the plugin to run - once the jboss is up, it will take up the war..
The current implementation does support soft deploy using JBOSS Management API..but there is no hard-deploy goal that used to supported in JBOSS 5 plugins like http://mojo.codehaus.org/jboss-maven-plugin
Reducing priority as this is possible using other plugins like antrun of maven...But can JBOSS AS MAVEN plugin support hard deploy (offline Deploy-where jboss instance is not running)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months