[JBoss JIRA] (WFLY-6835) Vault.sh misleading output
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6835?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-6835:
----------------------------------------
If we go for CLI commands, there should be two examples, one for a standalone server, one for a host controller. Difference is a preceding /host=the_host in the command address.
> Vault.sh misleading output
> --------------------------
>
> Key: WFLY-6835
> URL: https://issues.jboss.org/browse/WFLY-6835
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Minor
>
> Vault.sh advise to insert vault xml snippet as follows:
> {code}
> Vault Configuration in AS7 config file:
> ********************************************
> ...
> </extensions>
> <vault>
> <vault-option name="KEYSTORE_URL" value="EAP_HOME/vault/vault.keystore"/>
> <vault-option name="KEYSTORE_PASSWORD" value="MASK-5dOaAVafCSd"/>
> <vault-option name="KEYSTORE_ALIAS" value="vault"/>
> <vault-option name="SALT" value="1234abcd"/>
> <vault-option name="ITERATION_COUNT" value="120"/>
> <vault-option name="ENC_FILE_DIR" value="EAP_HOME/vault/"/>
> </vault><management> ...
> ********************************************
> {code}
> 1. User can insert this snippet on wrong place. See forum link for example. Pobably CLI command would be more suitable?
> {code}
> /core-service=vault:add(vault-options=[("KEYSTORE_URL" => "PATH_TO_KEYSTORE"),("KEYSTORE_PASSWORD" => "MASKED_PASSWORD"),("KEYSTORE_ALIAS" => "ALIAS"),("SALT" => "SALT"),("ITERATION_COUNT" => "ITERATION_COUNT"),("ENC_FILE_DIR" => "ENC_FILE_DIR")])
> {code}
> 2. There is still reference to AS7
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2052) Timer: make timer thread pool and timer queue configurable
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2052?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2052.
----------------------------
Resolution: Done
> Timer: make timer thread pool and timer queue configurable
> ----------------------------------------------------------
>
> Key: JGRP-2052
> URL: https://issues.jboss.org/browse/JGRP-2052
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> The timer ({{TimeScheduler3}}) currently has the thread pool enabled by default and the pool's queue is always on. Add 2 properties:
> # {{timer_thread_pool.enabled}}: enables or disables the timer's thread pool and
> # {{timer.queue_enabled}}: enables or disables the thread pool's queue.
> The timer has a runner thread which continually removes tasks scheduled for execution (from a {{DelayQueue}}) and dispatches the tasks to the thread pool. If the pool is disabled (#1), then it is the runner thread which executes the task directly. This makes sense for instance, when the timer only has non-blocking tasks. An example for a blocking task is a retransmission, which might block on the send side due to insufficient credits. The timer's thread pool is by default _enabled_, but it can now be disabled to reduce the threads running.
> Enabling the thread pool, but disabling the timer's queue means that the pool will allocate threads up to max-threads immediately, rather than queuing the tasks.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-355) Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin... ]
Petr Široký commented on DROOLS-355:
------------------------------------
* I tried to run the test in this PR https://github.com/droolsjbpm/drools/pull/834 on JDK 9 and that works as expected.
* I _think_ it should also work with module-info.java (assuming the jaxb-xjc is modularized -- or present in the unnamed module). But this needs to be tested.
* WildFly migrated to {{org.glassfish.jaxb}} groupId (which still contains the same com.sun.* packages), https://github.com/wildfly/wildfly/blob/10.0.0.Final/pom.xml#L1462
* I agree that using com.sun packages is far from ideal, but if it works, it is much less of an issue
> Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-355
> URL: https://issues.jboss.org/browse/DROOLS-355
> Project: Drools
> Issue Type: Task
> Affects Versions: 6.0.0.Final
> Reporter: Geoffrey De Smet
> Assignee: Petr Široký
> Priority: Blocker
>
> By importing com.sun.tools.xjc, 3 problems arise:
> * OSGi and Karaf trip over it.
> {code}
> [WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final)
> {code}
> * JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013.
> * IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this?
> Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now.
> Where do we use it?
> {code}
> Targets
> String 'com.sun.tools.xjc'
> Found usages (38 usages found)
> drools-compiler (7 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler (1 usage found)
> pom.xml (1 usage found)
> (246: 15) com.sun.tools.xjc.*;resolution:=optional,
> org.drools.compiler.builder.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (18: 8) import com.sun.tools.xjc.Options;
> org.drools.compiler.runtime.pipeline.impl (5 usages found)
> DroolsJaxbHelperProviderImpl.java (5 usages found)
> (77: 8) import com.sun.tools.xjc.BadCommandLineException;
> (78: 8) import com.sun.tools.xjc.ErrorReceiver;
> (79: 8) import com.sun.tools.xjc.ModelLoader;
> (80: 8) import com.sun.tools.xjc.Options;
> (81: 8) import com.sun.tools.xjc.model.Model;
> drools-core (2 usages found)
> org.drools.core.builder.conf.impl (2 usages found)
> JaxbConfigurationImpl.java (2 usages found)
> (28: 8) import com.sun.tools.xjc.Language;
> (34: 8) import com.sun.tools.xjc.Options;
> kie-internal (6 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal (1 usage found)
> pom.xml (1 usage found)
> (27: 15) com.sun.tools.xjc;resolution:=optional,
> org.kie.internal.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (23: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.kie.internal.builder.help (2 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (1 usage found)
> (30: 8) import com.sun.tools.xjc.Options;
> knowledge-api (8 usages found)
> org.drools.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (21: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.drools.builder.help (3 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (2 usages found)
> (32: 8) import com.sun.tools.xjc.Language;
> (33: 8) import com.sun.tools.xjc.Options;
> org.drools.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (16: 8) import com.sun.tools.xjc.Options;
> org.drools.impl.adapters (1 usage found)
> JaxbConfigurationAdapter.java (1 usage found)
> (3: 8) import com.sun.tools.xjc.Options;
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2052) Timer: make timer thread pool and timer queue configurable
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2052?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2052:
---------------------------
Description:
The timer ({{TimeScheduler3}}) currently has the thread pool enabled by default and the pool's queue is always on. Add 2 properties:
# {{timer_thread_pool.enabled}}: enables or disables the timer's thread pool and
# {{timer.queue_enabled}}: enables or disables the thread pool's queue.
The timer has a runner thread which continually removes tasks scheduled for execution (from a {{DelayQueue}}) and dispatches the tasks to the thread pool. If the pool is disabled (#1), then it is the runner thread which executes the task directly. This makes sense for instance, when the timer only has non-blocking tasks. An example for a blocking task is a retransmission, which might block on the send side due to insufficient credits. The timer's thread pool is by default _enabled_, but it can now be disabled to reduce the threads running.
Enabling the thread pool, but disabling the timer's queue means that the pool will allocate threads up to max-threads immediately, rather than queuing the tasks.
was:
Currently the timer thread pool always has the queue enabled; the user can only define a max queue size.
Change this to make a queue configurable, e.g. if we want a 0 or 1 min core threads size and a large max-size, and no queue enabled.
This would enable users to play with small timer thread pool sizes; as a matter of fact, there would be _no timer threads_ if no tasks are running.
> Timer: make timer thread pool and timer queue configurable
> ----------------------------------------------------------
>
> Key: JGRP-2052
> URL: https://issues.jboss.org/browse/JGRP-2052
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> The timer ({{TimeScheduler3}}) currently has the thread pool enabled by default and the pool's queue is always on. Add 2 properties:
> # {{timer_thread_pool.enabled}}: enables or disables the timer's thread pool and
> # {{timer.queue_enabled}}: enables or disables the thread pool's queue.
> The timer has a runner thread which continually removes tasks scheduled for execution (from a {{DelayQueue}}) and dispatches the tasks to the thread pool. If the pool is disabled (#1), then it is the runner thread which executes the task directly. This makes sense for instance, when the timer only has non-blocking tasks. An example for a blocking task is a retransmission, which might block on the send side due to insufficient credits. The timer's thread pool is by default _enabled_, but it can now be disabled to reduce the threads running.
> Enabling the thread pool, but disabling the timer's queue means that the pool will allocate threads up to max-threads immediately, rather than queuing the tasks.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-355) Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet edited comment on DROOLS-355 at 7/15/16 9:23 AM:
------------------------------------------------------------------
Some notes:
- Java 9 without the use of module-info.java might not crash on the com.sun import, because it's not coming from the JDK but from a normal dependency jaxb-xjc. In such a case, a com.sun import seems to be ok (*)
- Java 9 with the use of a module-info.java should be tested. (*)
- According to the maven metadata, the sun groupId dependency got changed to a glassfish groupId dependency. See http://mvnrepository.com/search?q=xjc and http://mvnrepository.com/artifact/org.glassfish.jaxb/jaxb-xjc
- (*) Sun is dead. Long term the package name com.sun.bind is unsustainable. We should not need it in our public API like we do now...
was (Author: ge0ffrey):
Some notes:
- Java 9 without the use of module-info.java might not crash on the com.sun import, because it's not coming from the JDK but from a normal dependency. In such a case, a com.sun import seems to be ok (*)
- Java 9 with the use of a module-info.java should be tested. (*)
- According to the maven metadata, the sun groupId dependency got changed to a glassfish groupId dependency. See http://mvnrepository.com/search?q=xjc and http://mvnrepository.com/artifact/org.glassfish.jaxb/jaxb-xjc
- (*) Sun is dead. Long term the package name com.sun.bind is unsustainable. We should not need it in our public API like we do now...
> Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-355
> URL: https://issues.jboss.org/browse/DROOLS-355
> Project: Drools
> Issue Type: Task
> Affects Versions: 6.0.0.Final
> Reporter: Geoffrey De Smet
> Assignee: Petr Široký
> Priority: Blocker
>
> By importing com.sun.tools.xjc, 3 problems arise:
> * OSGi and Karaf trip over it.
> {code}
> [WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final)
> {code}
> * JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013.
> * IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this?
> Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now.
> Where do we use it?
> {code}
> Targets
> String 'com.sun.tools.xjc'
> Found usages (38 usages found)
> drools-compiler (7 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler (1 usage found)
> pom.xml (1 usage found)
> (246: 15) com.sun.tools.xjc.*;resolution:=optional,
> org.drools.compiler.builder.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (18: 8) import com.sun.tools.xjc.Options;
> org.drools.compiler.runtime.pipeline.impl (5 usages found)
> DroolsJaxbHelperProviderImpl.java (5 usages found)
> (77: 8) import com.sun.tools.xjc.BadCommandLineException;
> (78: 8) import com.sun.tools.xjc.ErrorReceiver;
> (79: 8) import com.sun.tools.xjc.ModelLoader;
> (80: 8) import com.sun.tools.xjc.Options;
> (81: 8) import com.sun.tools.xjc.model.Model;
> drools-core (2 usages found)
> org.drools.core.builder.conf.impl (2 usages found)
> JaxbConfigurationImpl.java (2 usages found)
> (28: 8) import com.sun.tools.xjc.Language;
> (34: 8) import com.sun.tools.xjc.Options;
> kie-internal (6 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal (1 usage found)
> pom.xml (1 usage found)
> (27: 15) com.sun.tools.xjc;resolution:=optional,
> org.kie.internal.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (23: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.kie.internal.builder.help (2 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (1 usage found)
> (30: 8) import com.sun.tools.xjc.Options;
> knowledge-api (8 usages found)
> org.drools.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (21: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.drools.builder.help (3 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (2 usages found)
> (32: 8) import com.sun.tools.xjc.Language;
> (33: 8) import com.sun.tools.xjc.Options;
> org.drools.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (16: 8) import com.sun.tools.xjc.Options;
> org.drools.impl.adapters (1 usage found)
> JaxbConfigurationAdapter.java (1 usage found)
> (3: 8) import com.sun.tools.xjc.Options;
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-355) Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet edited comment on DROOLS-355 at 7/15/16 9:23 AM:
------------------------------------------------------------------
Some notes:
- Java 9 without the use of module-info.java might not crash on the com.sun import, because it's not coming from the JDK but from a normal dependency jaxb-xjc. In such a case, a com.sun import seems to be ok (*)
- Java 9 with the use of a module-info.java should be tested. (*)
- According to the maven metadata, the sun groupId dependency got changed to a glassfish groupId dependency. See http://mvnrepository.com/search?q=xjc and http://mvnrepository.com/artifact/org.glassfish.jaxb/jaxb-xjc
- (*) Sun is dead. Long term the package name com.sun.bind is unsustainable. We should not need it in our public API like we do now...
- Glassfish is dead (or as good as).
was (Author: ge0ffrey):
Some notes:
- Java 9 without the use of module-info.java might not crash on the com.sun import, because it's not coming from the JDK but from a normal dependency jaxb-xjc. In such a case, a com.sun import seems to be ok (*)
- Java 9 with the use of a module-info.java should be tested. (*)
- According to the maven metadata, the sun groupId dependency got changed to a glassfish groupId dependency. See http://mvnrepository.com/search?q=xjc and http://mvnrepository.com/artifact/org.glassfish.jaxb/jaxb-xjc
- (*) Sun is dead. Long term the package name com.sun.bind is unsustainable. We should not need it in our public API like we do now...
> Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-355
> URL: https://issues.jboss.org/browse/DROOLS-355
> Project: Drools
> Issue Type: Task
> Affects Versions: 6.0.0.Final
> Reporter: Geoffrey De Smet
> Assignee: Petr Široký
> Priority: Blocker
>
> By importing com.sun.tools.xjc, 3 problems arise:
> * OSGi and Karaf trip over it.
> {code}
> [WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final)
> {code}
> * JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013.
> * IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this?
> Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now.
> Where do we use it?
> {code}
> Targets
> String 'com.sun.tools.xjc'
> Found usages (38 usages found)
> drools-compiler (7 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler (1 usage found)
> pom.xml (1 usage found)
> (246: 15) com.sun.tools.xjc.*;resolution:=optional,
> org.drools.compiler.builder.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (18: 8) import com.sun.tools.xjc.Options;
> org.drools.compiler.runtime.pipeline.impl (5 usages found)
> DroolsJaxbHelperProviderImpl.java (5 usages found)
> (77: 8) import com.sun.tools.xjc.BadCommandLineException;
> (78: 8) import com.sun.tools.xjc.ErrorReceiver;
> (79: 8) import com.sun.tools.xjc.ModelLoader;
> (80: 8) import com.sun.tools.xjc.Options;
> (81: 8) import com.sun.tools.xjc.model.Model;
> drools-core (2 usages found)
> org.drools.core.builder.conf.impl (2 usages found)
> JaxbConfigurationImpl.java (2 usages found)
> (28: 8) import com.sun.tools.xjc.Language;
> (34: 8) import com.sun.tools.xjc.Options;
> kie-internal (6 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal (1 usage found)
> pom.xml (1 usage found)
> (27: 15) com.sun.tools.xjc;resolution:=optional,
> org.kie.internal.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (23: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.kie.internal.builder.help (2 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (1 usage found)
> (30: 8) import com.sun.tools.xjc.Options;
> knowledge-api (8 usages found)
> org.drools.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (21: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.drools.builder.help (3 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (2 usages found)
> (32: 8) import com.sun.tools.xjc.Language;
> (33: 8) import com.sun.tools.xjc.Options;
> org.drools.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (16: 8) import com.sun.tools.xjc.Options;
> org.drools.impl.adapters (1 usage found)
> JaxbConfigurationAdapter.java (1 usage found)
> (3: 8) import com.sun.tools.xjc.Options;
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-355) Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet commented on DROOLS-355:
-----------------------------------------
Some notes:
- Java 9 without the use of module-info.java might not crash on the com.sun import, because it's not coming from the JDK but from a normal dependency. In such a case, a com.sun import seems to be ok (*)
- Java 9 with the use of a module-info.java should be tested. (*)
- According to the maven metadata, the sun groupId dependency got changed to a glassfish groupId dependency. See http://mvnrepository.com/search?q=xjc and http://mvnrepository.com/artifact/org.glassfish.jaxb/jaxb-xjc
- (*) Sun is dead. Long term the package name com.sun.bind is unsustainable. We should not need it in our public API like we do now...
> Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-355
> URL: https://issues.jboss.org/browse/DROOLS-355
> Project: Drools
> Issue Type: Task
> Affects Versions: 6.0.0.Final
> Reporter: Geoffrey De Smet
> Assignee: Petr Široký
> Priority: Blocker
>
> By importing com.sun.tools.xjc, 3 problems arise:
> * OSGi and Karaf trip over it.
> {code}
> [WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final)
> {code}
> * JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013.
> * IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this?
> Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now.
> Where do we use it?
> {code}
> Targets
> String 'com.sun.tools.xjc'
> Found usages (38 usages found)
> drools-compiler (7 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler (1 usage found)
> pom.xml (1 usage found)
> (246: 15) com.sun.tools.xjc.*;resolution:=optional,
> org.drools.compiler.builder.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (18: 8) import com.sun.tools.xjc.Options;
> org.drools.compiler.runtime.pipeline.impl (5 usages found)
> DroolsJaxbHelperProviderImpl.java (5 usages found)
> (77: 8) import com.sun.tools.xjc.BadCommandLineException;
> (78: 8) import com.sun.tools.xjc.ErrorReceiver;
> (79: 8) import com.sun.tools.xjc.ModelLoader;
> (80: 8) import com.sun.tools.xjc.Options;
> (81: 8) import com.sun.tools.xjc.model.Model;
> drools-core (2 usages found)
> org.drools.core.builder.conf.impl (2 usages found)
> JaxbConfigurationImpl.java (2 usages found)
> (28: 8) import com.sun.tools.xjc.Language;
> (34: 8) import com.sun.tools.xjc.Options;
> kie-internal (6 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal (1 usage found)
> pom.xml (1 usage found)
> (27: 15) com.sun.tools.xjc;resolution:=optional,
> org.kie.internal.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (23: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.kie.internal.builder.help (2 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (1 usage found)
> (30: 8) import com.sun.tools.xjc.Options;
> knowledge-api (8 usages found)
> org.drools.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (21: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.drools.builder.help (3 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (2 usages found)
> (32: 8) import com.sun.tools.xjc.Language;
> (33: 8) import com.sun.tools.xjc.Options;
> org.drools.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (16: 8) import com.sun.tools.xjc.Options;
> org.drools.impl.adapters (1 usage found)
> JaxbConfigurationAdapter.java (1 usage found)
> (3: 8) import com.sun.tools.xjc.Options;
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months