[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 Marco Rietveld (JIRA)
[ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin... ]
Marco Rietveld edited comment on DROOLS-355 at 8/24/16 2:14 AM:
----------------------------------------------------------------
Notes:
- {{Castor}} is not a viable alternative because of licensing issues
- {{XStream}} can not handle XSDs
- {{XmlBeans}} contains `com.sun.javadoc.*` imports, which cause problems on Java 8
-- as well as OSGi problems, I suspect
-- and the jar is also 2.7M..
-- and it's broken (if you try to go around the {{com.sun.javadoc.*}} imports)
- {{JIBX}} is possible, but it doesn't look good because
-- Dependency tree is not in order (would have to exclude `bcel` 5.1 and force include `bcel 6.0` because bcel < 6.0 can not handle java 8)
--- Having `bcel` in the dep tree is a big minus in the first place..
-- internal XSD compilation infrastructure does not like it would lend itself to being used in this use case
--- no easily used points for substituting an in-memory filesystem instead of the real filesystem
was (Author: marco.rietveld):
Notes:
- {{Castor}} is not a viable alternative because of licensing issues
- {{XStream}} can not handle XSDs
- {{XmlBeans}} contains `com.sun.javadoc.*` imports, which cause problems on Java 8
-- as well as OSGi problems, I suspect
-- and the jar is also 2.7M..
- {{JIBX}} is possible, but it doesn't look good because
-- Dependency tree is not in order (would have to exclude `bcel` 5.1 and force include `bcel 6.0` because bcel < 6.0 can not handle java 8)
--- Having `bcel` in the dep tree is a big minus in the first place..
-- internal XSD compilation infrastructure does not like it would lend itself to being used in this use case
--- no easily used points for substituting an in-memory filesystem instead of the real filesystem
> 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: Marco Rietveld
> 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, 8 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 Marco Rietveld (JIRA)
[ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin... ]
Marco Rietveld edited comment on DROOLS-355 at 8/24/16 2:13 AM:
----------------------------------------------------------------
Notes:
- {{Castor}} is not a viable alternative because of licensing issues
- {{XStream}} can not handle XSDs
- {{XmlBeans}} contains `com.sun.javadoc.*` imports, which cause problems on Java 8
-- as well as OSGi problems, I suspect
-- and the jar is also 2.7M..
- {{JIBX}} is possible, but it doesn't look good because
-- Dependency tree is not in order (would have to exclude `bcel` 5.1 and force include `bcel 6.0` because bcel < 6.0 can not handle java 8)
--- Having `bcel` in the dep tree is a big minus in the first place..
-- internal XSD compilation infrastructure does not like it would lend itself to being used in this use case
--- no easily used points for substituting an in-memory filesystem instead of the real filesystem
was (Author: marco.rietveld):
Notes:
- {{Castor}} is not a viable alternative because of licensing issues
- {{XStream}} can not handle XSDs
- {{XmlBeans}} contains `com.sun.javadoc.*` imports, which cause problems on Java 8
- as well as OSGi problems, I suspect
- {{JIBX}} is possible, but it doesn't look good because
-- Dependency tree is not in order (would have to exclude `bcel` 5.1 and force include `bcel 6.0` because bcel < 6.0 can not handle java 8)
--- Having `bcel` in the dep tree is a big minus in the first place..
-- internal XSD compilation infrastructure does not like it would lend itself to being used in this use case
--- no easily used points for substituting an in-memory filesystem instead of the real filesystem
> 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: Marco Rietveld
> 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, 8 months
[JBoss JIRA] (JGRP-2097) Add Channel back
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2097?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2097 at 8/24/16 2:05 AM:
---------------------------------------------------------
Instead of making JChannel extend Channel (this would have required a lot of changes), the following changes were made:
* Channel is not an abstract class any longer, but a real class
* A Channel is created with a ref to a JChannel
* All methods which were previously abstract are now non-abstract and delegate to the JChannel ref
* Code which returned a JChannel now need to return a Channel with a ref to JChannel, e.g. {{return new Channel(jchannel)}}.
was (Author: belaban):
Instead of making JChannel extend Channel (this would have required a lot of changes), the following changes were made:
* Channel is not an abstract class any longer, but a real class
* A Channel is created with a ref to a JChannel
* All methods which were previously abstract are now non-abstract and delegate to the JChannel ref
* Code which returned a JChannel now need to return a Channel with a ref to JChannel, e.g. `return new Channel(jchannel)`
> Add Channel back
> ----------------
>
> Key: JGRP-2097
> URL: https://issues.jboss.org/browse/JGRP-2097
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Channel was removed, but this broke existing apps. Re-introduce Channel and mark it as deprecated.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2097) Add Channel back
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2097?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2097:
--------------------------------
Instead of making JChannel extend Channel (this would have required a lot of changes), the following changes were made:
* Channel is not an abstract class any longer, but a real class
* A Channel is created with a ref to a JChannel
* All methods which were previously abstract are now non-abstract and delegate to the JChannel ref
> Add Channel back
> ----------------
>
> Key: JGRP-2097
> URL: https://issues.jboss.org/browse/JGRP-2097
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Channel was removed, but this broke existing apps. Re-introduce Channel and mark it as deprecated.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2097) Add Channel back
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2097?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2097 at 8/24/16 2:04 AM:
---------------------------------------------------------
Instead of making JChannel extend Channel (this would have required a lot of changes), the following changes were made:
* Channel is not an abstract class any longer, but a real class
* A Channel is created with a ref to a JChannel
* All methods which were previously abstract are now non-abstract and delegate to the JChannel ref
* Code which returned a JChannel now need to return a Channel with a ref to JChannel, e.g. `return new Channel(jchannel)`
was (Author: belaban):
Instead of making JChannel extend Channel (this would have required a lot of changes), the following changes were made:
* Channel is not an abstract class any longer, but a real class
* A Channel is created with a ref to a JChannel
* All methods which were previously abstract are now non-abstract and delegate to the JChannel ref
> Add Channel back
> ----------------
>
> Key: JGRP-2097
> URL: https://issues.jboss.org/browse/JGRP-2097
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Channel was removed, but this broke existing apps. Re-introduce Channel and mark it as deprecated.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2097) Add Channel back
by Bela Ban (JIRA)
Bela Ban created JGRP-2097:
------------------------------
Summary: Add Channel back
Key: JGRP-2097
URL: https://issues.jboss.org/browse/JGRP-2097
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.0
Channel was removed, but this broke existing apps. Re-introduce Channel and mark it as deprecated.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months