[JBoss JIRA] (WFLY-4194) Deprecate default-stack JGroups subsystem attribute
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-4194?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-4194:
-------------------------------
Description:
The original purpose of the default-stack attribute was to provide a default ChannelFactory implementation. However, with the introduction of fork channels, there are now 2 candidate for a default ChannelFactory:
1. The JChannelFactory of the default stack.
2. The ForkChannelFactory of the default channel.
#2 is the better option - and is what Infinispan transports use by default.
This would require that the stack attribute of a channel is required (currently, it is optional and defaults to the default-stack).
was:
The original purpose of the default-stack attribute was to provide a default ChannelFactory implementation. However, with the introduction of fork channels, there are now 2 candidate for a default ChannelFactory:
1. The JChannelFactory of the default stack.
2. The ForkChannelFactory of the default channel.
#2 is the better option - and is what Infinispan transports use by default.
> Deprecate default-stack JGroups subsystem attribute
> ---------------------------------------------------
>
> Key: WFLY-4194
> URL: https://issues.jboss.org/browse/WFLY-4194
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 9.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> The original purpose of the default-stack attribute was to provide a default ChannelFactory implementation. However, with the introduction of fork channels, there are now 2 candidate for a default ChannelFactory:
> 1. The JChannelFactory of the default stack.
> 2. The ForkChannelFactory of the default channel.
> #2 is the better option - and is what Infinispan transports use by default.
> This would require that the stack attribute of a channel is required (currently, it is optional and defaults to the default-stack).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4194) Deprecate default-stack JGroups subsystem attribute
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-4194:
----------------------------------
Summary: Deprecate default-stack JGroups subsystem attribute
Key: WFLY-4194
URL: https://issues.jboss.org/browse/WFLY-4194
Project: WildFly
Issue Type: Enhancement
Components: Clustering
Affects Versions: 9.0.0.Alpha1
Reporter: Paul Ferraro
Assignee: Paul Ferraro
The original purpose of the default-stack attribute was to provide a default ChannelFactory implementation. However, with the introduction of fork channels, there are now 2 candidate for a default ChannelFactory:
1. The JChannelFactory of the default stack.
2. The ForkChannelFactory of the default channel.
#2 is the better option - and is what Infinispan transports use by default.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4113) 8.2.0.Final build hangs
by Peter Major (JIRA)
[ https://issues.jboss.org/browse/WFLY-4113?page=com.atlassian.jira.plugin.... ]
Peter Major edited comment on WFLY-4113 at 12/19/14 12:38 PM:
--------------------------------------------------------------
This is what I had done:
{noformat}
# Build byteman 2.0.0, since it is not available in any of the repositories defined by jboss-remoting's POM
git clone https://github.com/bytemanproject/byteman.git
cd byteman
git checkout 2.0.0
mvn clean install
# We can build jboss-remoting now
git clone https://github.com/jboss-remoting/jboss-remoting.git
cd jboss-remoting
git checkout 4.0
# Need to build jboss-remoting with english locale, because "Connection refused" is hardcoded in org.jboss.remoting3.test.RemoteChannelTest
LC_ALL=en_US.UTF-8 mvn clean install
{noformat}
After modifying the WildFly pom to include 4.0.7.Final-SNASHOT my build finally finished, only thing to note is that org.jboss.as.domain.management.security.realms.PropertiesAuthenticationDigestedTestCase test case can take around 386.621 seconds to finish.
was (Author: aldaris):
This is what I had done:
{noformat}
# Build byteman 2.0.0, since it is not available in any of the repositories defined by jboss-remoting's POM
git clone https://github.com/bytemanproject/byteman.git
cd byteman
git checkout 2.0.0
mvn clean install
# We can build jboss-remoting now
git clone https://github.com/jboss-remoting/jboss-remoting.git
cd jboss-remoting
git checkout 4.0
# Need to build jboss-remoting with english locale, because "Connection refused" is hardcoded in org.jboss.remoting3.test.RemoteChannelTest
LC_ALL=en_US.UTF-8 mvn clean install
{noformat}
After modifying the WildFly pom to include 4.0.7.Final-SNASHOT my build finaly finished, only thing to note is that org.jboss.as.domain.management.security.realms.PropertiesAuthenticationDigestedTestCase test case can take around 386.621 seconds to finish.
> 8.2.0.Final build hangs
> -----------------------
>
> Key: WFLY-4113
> URL: https://issues.jboss.org/browse/WFLY-4113
> Project: WildFly
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 8.2.0.Final
> Reporter: Peter Major
> Assignee: David Lloyd
> Attachments: jstack.txt
>
>
> When trying to build 8.2.0.Final locally, my build just hangs indefinitely while executing a unit test in the controller module:
> {noformat}
> Running org.jboss.as.controller.ModelControllerClientTestCase
> {noformat}
> Running jstack against the build suggests that there is a deadlock between
> {noformat}
> - waiting to lock <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.closeMessages(RemoteConnectionChannel.java:560)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:542)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:423)
> - locked <0x00000007b8d8e6f8> (a java.util.ArrayDeque)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.sendCloseRequest(RemoteConnectionHandler.java:232)
> {noformat}
> and
> {noformat}
> - waiting to lock <0x00000007b8d8e6f8> (a java.util.ArrayDeque)
> at org.jboss.remoting3.remote.RemoteConnection.send(RemoteConnection.java:122)
> at org.jboss.remoting3.remote.OutboundMessage$1.accept(OutboundMessage.java:154)
> at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:122)
> at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:115)
> at org.xnio.streams.BufferPipeOutputStream.flush(BufferPipeOutputStream.java:139)
> - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream)
> at org.xnio.streams.BufferPipeOutputStream.close(BufferPipeOutputStream.java:157)
> - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream)
> at org.jboss.remoting3.remote.OutboundMessage.close(OutboundMessage.java:283)
> - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream)
> at java.io.FilterOutputStream.close(FilterOutputStream.java:160)
> {noformat}
> Preferably locks should be obtained in the same order across the different code paths to prevent deadlocks.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4113) 8.2.0.Final build hangs
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-4113?page=com.atlassian.jira.plugin.... ]
Romain Pelisse commented on WFLY-4113:
--------------------------------------
@Peter, I've also end up doing that, and ran into the same local issue with JBoss Remoting build [https://issues.jboss.org/browse/REM3-202]. I've pushed a PR to fix that [https://github.com/jboss-remoting/jboss-remoting/pull/33]
> 8.2.0.Final build hangs
> -----------------------
>
> Key: WFLY-4113
> URL: https://issues.jboss.org/browse/WFLY-4113
> Project: WildFly
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 8.2.0.Final
> Reporter: Peter Major
> Assignee: David Lloyd
> Attachments: jstack.txt
>
>
> When trying to build 8.2.0.Final locally, my build just hangs indefinitely while executing a unit test in the controller module:
> {noformat}
> Running org.jboss.as.controller.ModelControllerClientTestCase
> {noformat}
> Running jstack against the build suggests that there is a deadlock between
> {noformat}
> - waiting to lock <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.closeMessages(RemoteConnectionChannel.java:560)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:542)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:423)
> - locked <0x00000007b8d8e6f8> (a java.util.ArrayDeque)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.sendCloseRequest(RemoteConnectionHandler.java:232)
> {noformat}
> and
> {noformat}
> - waiting to lock <0x00000007b8d8e6f8> (a java.util.ArrayDeque)
> at org.jboss.remoting3.remote.RemoteConnection.send(RemoteConnection.java:122)
> at org.jboss.remoting3.remote.OutboundMessage$1.accept(OutboundMessage.java:154)
> at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:122)
> at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:115)
> at org.xnio.streams.BufferPipeOutputStream.flush(BufferPipeOutputStream.java:139)
> - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream)
> at org.xnio.streams.BufferPipeOutputStream.close(BufferPipeOutputStream.java:157)
> - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream)
> at org.jboss.remoting3.remote.OutboundMessage.close(OutboundMessage.java:283)
> - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream)
> at java.io.FilterOutputStream.close(FilterOutputStream.java:160)
> {noformat}
> Preferably locks should be obtained in the same order across the different code paths to prevent deadlocks.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (ELY-129) Choose SASL mechanisms based on better criteria
by David Lloyd (JIRA)
David Lloyd created ELY-129:
-------------------------------
Summary: Choose SASL mechanisms based on better criteria
Key: ELY-129
URL: https://issues.jboss.org/browse/ELY-129
Project: WildFly Elytron
Issue Type: Enhancement
Reporter: David Lloyd
SASL mechanism selection is based on properties right now, that specify only a few very limited criteria.
We should provide a better selection mechanism that allows selection based on the following criteria:
* Specify requirements of the mechanism itself
** Algorithm usage
** Key length (where applicable)
** Parameters similar to existing Sasl ones, like:
*** QOP
*** Forward secrecy
*** Plaintext
*** Active attack susceptibility
*** etc.
* Specify requirements around the mechanism's circumstance
** Restrict by enclosing channel security
*** Require TLS cipher suite parameters (using existing database parameters)
*** Require channel binding
In the end the client or server user should be able specify SASL mechanism usage using expressions that can express things like:
* Use PLAIN only if TLS is in use with AES encryption
* Use EXTERNAL only if TLS is in use
* Use no SASL mechanisms employing weak hash algorithms (MD5 and worse)
* Use only SASL mechanisms employing SHA-256
* Use only SASL mechanisms that provide channel binding and require TLS
* Use only ANONYMOUS
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4113) 8.2.0.Final build hangs
by Peter Major (JIRA)
[ https://issues.jboss.org/browse/WFLY-4113?page=com.atlassian.jira.plugin.... ]
Peter Major edited comment on WFLY-4113 at 12/19/14 12:17 PM:
--------------------------------------------------------------
This is what I had done:
{noformat}
# Build byteman 2.0.0, since it is not available in any of the repositories defined by jboss-remoting's POM
git clone https://github.com/bytemanproject/byteman.git
cd byteman
git checkout 2.0.0
mvn clean install
# We can build jboss-remoting now
git clone https://github.com/jboss-remoting/jboss-remoting.git
cd jboss-remoting
git checkout 4.0
# Need to build jboss-remoting with english locale, because "Connection refused" is hardcoded in org.jboss.remoting3.test.RemoteChannelTest
LC_ALL=en_US.UTF-8 mvn clean install
{noformat}
After modifying the WildFly pom to include 4.0.7.Final-SNASHOT my build finaly finished, only thing to note is that org.jboss.as.domain.management.security.realms.PropertiesAuthenticationDigestedTestCase test case can take around 386.621 seconds to finish.
was (Author: aldaris):
This is what I had done:
{noformat}
# Build byteman 2.0.0, since it is not available in any of the repositories defined by jboss-remoting's POM
git clone https://github.com/bytemanproject/byteman.git
cd byteman
git checkout 2.0.0
mvn clean install
# We can build jboss-remoting now
git clone https://github.com/jboss-remoting/jboss-remoting.git
cd jboss-remoting
git checkout 4.0
# Need to build jboss-remoting with english locale, because "Connection refused" is hardcoded in org.jboss.remoting3.test.RemoteChannelTest
LC_ALL=en_US.UTF-8 mvn clean install
{noformat}
After modifying the WildFly pom to include 4.0.7.Final-SNASHOT, I've got a new hanging test in wildfly-domain-management now instead:
{noformat}
Running org.jboss.as.domain.management.security.realms.PropertiesAuthenticationDigestedTestCase
{noformat}
Now I can only wonder if the release was built without executing tests...
> 8.2.0.Final build hangs
> -----------------------
>
> Key: WFLY-4113
> URL: https://issues.jboss.org/browse/WFLY-4113
> Project: WildFly
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 8.2.0.Final
> Reporter: Peter Major
> Assignee: David Lloyd
> Attachments: jstack.txt
>
>
> When trying to build 8.2.0.Final locally, my build just hangs indefinitely while executing a unit test in the controller module:
> {noformat}
> Running org.jboss.as.controller.ModelControllerClientTestCase
> {noformat}
> Running jstack against the build suggests that there is a deadlock between
> {noformat}
> - waiting to lock <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.closeMessages(RemoteConnectionChannel.java:560)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:542)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:423)
> - locked <0x00000007b8d8e6f8> (a java.util.ArrayDeque)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.sendCloseRequest(RemoteConnectionHandler.java:232)
> {noformat}
> and
> {noformat}
> - waiting to lock <0x00000007b8d8e6f8> (a java.util.ArrayDeque)
> at org.jboss.remoting3.remote.RemoteConnection.send(RemoteConnection.java:122)
> at org.jboss.remoting3.remote.OutboundMessage$1.accept(OutboundMessage.java:154)
> at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:122)
> at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:115)
> at org.xnio.streams.BufferPipeOutputStream.flush(BufferPipeOutputStream.java:139)
> - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream)
> at org.xnio.streams.BufferPipeOutputStream.close(BufferPipeOutputStream.java:157)
> - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream)
> at org.jboss.remoting3.remote.OutboundMessage.close(OutboundMessage.java:283)
> - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream)
> at java.io.FilterOutputStream.close(FilterOutputStream.java:160)
> {noformat}
> Preferably locks should be obtained in the same order across the different code paths to prevent deadlocks.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4113) 8.2.0.Final build hangs
by Peter Major (JIRA)
[ https://issues.jboss.org/browse/WFLY-4113?page=com.atlassian.jira.plugin.... ]
Peter Major commented on WFLY-4113:
-----------------------------------
This is what I had done:
{noformat}
# Build byteman 2.0.0, since it is not available in any of the repositories defined by jboss-remoting's POM
git clone https://github.com/bytemanproject/byteman.git
cd byteman
git checkout 2.0.0
mvn clean install
# We can build jboss-remoting now
git clone https://github.com/jboss-remoting/jboss-remoting.git
cd jboss-remoting
git checkout 4.0
# Need to build jboss-remoting with english locale, because "Connection refused" is hardcoded in org.jboss.remoting3.test.RemoteChannelTest
LC_ALL=en_US.UTF-8 mvn clean install
{noformat}
After modifying the WildFly pom to include 4.0.7.Final-SNASHOT, I've got a new hanging test in wildfly-domain-management now instead:
{noformat}
Running org.jboss.as.domain.management.security.realms.PropertiesAuthenticationDigestedTestCase
{noformat}
Now I can only wonder if the release was built without executing tests...
> 8.2.0.Final build hangs
> -----------------------
>
> Key: WFLY-4113
> URL: https://issues.jboss.org/browse/WFLY-4113
> Project: WildFly
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 8.2.0.Final
> Reporter: Peter Major
> Assignee: David Lloyd
> Attachments: jstack.txt
>
>
> When trying to build 8.2.0.Final locally, my build just hangs indefinitely while executing a unit test in the controller module:
> {noformat}
> Running org.jboss.as.controller.ModelControllerClientTestCase
> {noformat}
> Running jstack against the build suggests that there is a deadlock between
> {noformat}
> - waiting to lock <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.closeMessages(RemoteConnectionChannel.java:560)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:542)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:423)
> - locked <0x00000007b8d8e6f8> (a java.util.ArrayDeque)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.sendCloseRequest(RemoteConnectionHandler.java:232)
> {noformat}
> and
> {noformat}
> - waiting to lock <0x00000007b8d8e6f8> (a java.util.ArrayDeque)
> at org.jboss.remoting3.remote.RemoteConnection.send(RemoteConnection.java:122)
> at org.jboss.remoting3.remote.OutboundMessage$1.accept(OutboundMessage.java:154)
> at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:122)
> at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:115)
> at org.xnio.streams.BufferPipeOutputStream.flush(BufferPipeOutputStream.java:139)
> - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream)
> at org.xnio.streams.BufferPipeOutputStream.close(BufferPipeOutputStream.java:157)
> - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream)
> at org.jboss.remoting3.remote.OutboundMessage.close(OutboundMessage.java:283)
> - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream)
> at java.io.FilterOutputStream.close(FilterOutputStream.java:160)
> {noformat}
> Preferably locks should be obtained in the same order across the different code paths to prevent deadlocks.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-3723) setting the local to english in CLI commands on non-english systems does not produce english output
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3723?page=com.atlassian.jira.plugin.... ]
Romain Pelisse reassigned WFLY-3723:
------------------------------------
Assignee: Romain Pelisse (was: Alexey Loubyansky)
> setting the local to english in CLI commands on non-english systems does not produce english output
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-3723
> URL: https://issues.jboss.org/browse/WFLY-3723
> Project: WildFly
> Issue Type: Bug
> Components: Localization
> Affects Versions: 8.1.0.Final
> Environment: Tested on MacOS running in German
> Reporter: Tom Fonteyne
> Assignee: Romain Pelisse
> Priority: Minor
>
> A German (or french etc...) system must be used to reproduce.
> It is likely this is not limited to MacOS, but I do not have a non-english Linux system available
> An out of the box install of wildfly/EAP:
> Without configuration, the log file is in German as expected.
> Using these CLI comands:
> :read-operation-description(name=stop-servers,locale=de_DE) -> german
> :read-operation-description(name=stop-servers,locale=en_US) -> german
> :read-operation-description(name=stop-servers,locale=fr_FR) -> french
> So we cannot get the CLI to produce english output
> when configuring JAVA_OPTS in domain.conf with:
> JAVA_OPTS="$JAVA_OPTS -Duser.language=en -Duser.country=DE -Duser.encoding=utf-8
> The log is now in English -> works as expected; and:
> :read-operation-description(name=stop-servers,locale=de_DE) -> german
> :read-operation-description(name=stop-servers,locale=en_US) -> english
> So it seems we have a bug where the locale set to start the domain takes precedence over the locale set in the CLI command (but only when English is asked)
> I presume this is because English is the default locale.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (DROOLS-658) External POJOs not shown in Workbench after reopen the project
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-658?page=com.atlassian.jira.plugin... ]
Michael Anstis commented on DROOLS-658:
---------------------------------------
I tried with 6.2.0.CR3 and it seems to work fine.
I uploaded a JAR to the Artifact Repository, created a new Project adding the JAR as a dependency.
In both the Data Object Modeller and a Guided Rule Editor I could use the types in the JAR. In the Data Object Modeller the classes were listed as " - ext - XYZ" (as you state) and in the Guided Rule Editor I could import the type and author a rule with it. I logged out and back in and checked both the Data Object Modeller and Guided Rule Editor. Both worked as they had initially.
> External POJOs not shown in Workbench after reopen the project
> --------------------------------------------------------------
>
> Key: DROOLS-658
> URL: https://issues.jboss.org/browse/DROOLS-658
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.CR2
> Environment: linux 64 bits
> Reporter: Jose Cavieres
> Assignee: Michael Anstis
> Fix For: 6.2.0.CR3
>
> Attachments: reuse.tgz
>
>
> In order to reuse some POJOs, I followed the procedure defined in
> http://mswiderski.blogspot.com/2014/02/reuse-your-business-assets-with-jb...
> and added a POJO to the "reusable project" (named Papito)
> Everything works fine the first time one uses those clases in the "top project" (named Hijita) . POJOs of the "reusable project" are prefixed with the string "- ext -" in the Java editor of the "top project" just as explained in "15.7.6.6.3. Using the external objects" of the document:
> http://docs.jboss.org/drools/release/6.1.0.Final/drools-docs/html/wb.Work...
> The problem is that only happens the first time. If one logout and the login again, the "-ext" classes are no longer shown as valid Types por the POJOs in the "top project"
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years