[JBoss JIRA] (DROOLS-472) Drools Eclipse plugin can't recognize third party classes
by Jinghai Rao (JIRA)
Jinghai Rao created DROOLS-472:
----------------------------------
Summary: Drools Eclipse plugin can't recognize third party classes
Key: DROOLS-472
URL: https://issues.jboss.org/browse/DROOLS-472
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: * OS: Mac OS X 10.9.2
* Eclipse Kepler
* Drool Eclipse Plugin - JBoss Drools Core 6.0.1Final. (I don't have problem with Drools Core 5.6.0Final)
* Java SE 1.7
* Drools Runtime 6.0.1
Reporter: Jinghai Rao
Assignee: Mark Proctor
Whenever I use classes from any third party jar files (not in JRE System Library and Drools Library), I got error messages in Eclipse IDE.
At the place where I import the class, the error message is "Only a type can be imported. ... resolves to a package".
At the place where I use the class, the error message is "... cannot be resolved to a type".
However, I have included the jar file in classpath. The project can also be executed successfully even with the error message in IDE.
Below is my development environment:
* OS: Mac OS X 10.9.2
* Eclipse Kepler
* Drool Eclipse Plugin - JBoss Drools Core 6.0.1Final. (I don't have problem with Drools Core 5.6.0Final)
* Java SE 1.7
* Drools Runtime 6.0.1
!https://lh5.googleusercontent.com/-gltHnzUIUg4/U1qbEzVd_LI/AAAAAAAAEYw/mKxE2jv-VVc/w1796-h1168-no/Screen+Shot+2014-04-25+at+10.20.36+AM.png!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 4 months
[JBoss JIRA] (WFLY-3290) Cannot use a cluster name other than "ejb"
by Chris Stillwell (JIRA)
[ https://issues.jboss.org/browse/WFLY-3290?page=com.atlassian.jira.plugin.... ]
Chris Stillwell updated WFLY-3290:
----------------------------------
Attachment: helloworld-test.zip
The helloworld-test.zip file contains the source for a simple Stateless session bean, the deployment ear, the standalone.conf, and standalone-ha.xml files I used to test this issue.
standalone01-ha.xml adds a remote-outbound-connection named helloworld-connection. The cluster name remains "ejb".
standalone02-ha.xml is the same as standalone01-ha.xml, but changes the cluster name to ejb-helloworld.
standalone.conf is modified to set the helloworldServer1 variable used in the helloworld outbound-socket-binding in the standalone01 & 02 configs and to override the variables jboss.bind.address.management, jboss.bind.address, and jboss.default.multicast.address.
When the ear is deployed using the standalone01-ha.xml configuration the cluster will be formed. However, when using the standalone02-ha.xml configuration the cluster will not be formed.
> Cannot use a cluster name other than "ejb"
> ------------------------------------------
>
> Key: WFLY-3290
> URL: https://issues.jboss.org/browse/WFLY-3290
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Chris Stillwell
> Assignee: Paul Ferraro
> Priority: Critical
> Attachments: helloworld-test.zip
>
>
> When deploying a clustered session bean the cluster will form only if the cluster name is "ejb". If the standalone-ha.xml is modified to use a different cluster name then the cluster will not form.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 4 months
[JBoss JIRA] (WFLY-3290) Cannot use a cluster name other than "ejb"
by Chris Stillwell (JIRA)
Chris Stillwell created WFLY-3290:
-------------------------------------
Summary: Cannot use a cluster name other than "ejb"
Key: WFLY-3290
URL: https://issues.jboss.org/browse/WFLY-3290
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: 8.0.0.Final
Reporter: Chris Stillwell
Assignee: Paul Ferraro
Priority: Critical
When deploying a clustered session bean the cluster will form only if the cluster name is "ejb". If the standalone-ha.xml is modified to use a different cluster name then the cluster will not form.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 4 months
[JBoss JIRA] (WFLY-3289) Intermittent failures in PassworkMaskingTestCase
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-3289:
--------------------------------------
Summary: Intermittent failures in PassworkMaskingTestCase
Key: WFLY-3289
URL: https://issues.jboss.org/browse/WFLY-3289
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security, Test Suite
Affects Versions: 8.1.0.CR1
Reporter: Brian Stansberry
Assignee: Peter Skopek
PasswordMaskingTestCase fails intermittently. See, for example, http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=14404&buildTyp...
The log shows this:
05:55:56,496 ERROR [org.jboss.as.arquillian.container.ServerSetupObserver] (main) Setup task failed during setup. Offending class 'org.jboss.as.test.integration.security.passwordmasking.PasswordMaskingTestCase$PasswordMaskingTestCaseSetup@4b584d': java.lang.RuntimeException: Problem creating VaultSession:
at org.jboss.as.test.integration.security.common.VaultHandler.<init>(VaultHandler.java:168)
at org.jboss.as.test.integration.security.common.VaultHandler.<init>(VaultHandler.java:180)
at org.jboss.as.test.integration.security.common.VaultHandler.<init>(VaultHandler.java:188)
at org.jboss.as.test.integration.security.passwordmasking.PasswordMaskingTestCase$PasswordMaskingTestCaseSetup.setup(PasswordMaskingTestCase.java:91)
at org.jboss.as.arquillian.container.ServerSetupObserver.handleBeforeDeployment(ServerSetupObserver.java:116)
at sun.reflect.GeneratedMethodAccessor33.invoke(Unknown Source)
. . .
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Caused by: java.lang.Exception: Exception encountered:
at org.jboss.as.security.vault.VaultSession.initSecurityVault(VaultSession.java:173)
at org.jboss.as.security.vault.VaultSession.startVaultSession(VaultSession.java:191)
at org.jboss.as.test.integration.security.common.VaultHandler.<init>(VaultHandler.java:166)
... 103 more
Caused by: org.jboss.security.vault.SecurityVaultException: javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher
at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:210)
at org.jboss.as.security.vault.VaultSession.initSecurityVault(VaultSession.java:170)
... 105 more
Caused by: javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher
at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:750)
at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:676)
at com.sun.crypto.provider.PBECipherCore.doFinal(PBECipherCore.java:422)
at com.sun.crypto.provider.PBEWithMD5AndDESCipher.engineDoFinal(PBEWithMD5AndDESCipher.java:316)
at javax.crypto.Cipher.doFinal(Cipher.java:2087)
at org.jboss.security.plugins.PBEUtils.decode(PBEUtils.java:72)
at org.jboss.security.plugins.PBEUtils.decode64(PBEUtils.java:81)
at org.picketbox.plugins.vault.PicketBoxSecurityVault.decode(PicketBoxSecurityVault.java:362)
at org.picketbox.plugins.vault.PicketBoxSecurityVault.loadKeystorePassword(PicketBoxSecurityVault.java:339)
at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:204)
... 106 more
Per discussion at http://lists.jboss.org/pipermail/wildfly-dev/2014-April/002064.html I am going to @Ignore this test and it is subject to being removed 3 weeks after 8.1.0.Final if not corrected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-3104) datasource created with console cannot be enabled
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3104?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-3104:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1079241
> datasource created with console cannot be enabled
> -------------------------------------------------
>
> Key: WFLY-3104
> URL: https://issues.jboss.org/browse/WFLY-3104
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.0.0.Final
> Environment: Wildfly 8.0.0 Final
> Reporter: Gabriele Garuglieri
> Assignee: Stefano Maestri
>
> Consider the following cli file:
> {noformat}
> /subsystem=datasources/data-source=fai-bfsa:add( \
> driver-name=PostgresJDBCDriver, \
> driver-class="org.postgresql.Driver", \
> jndi-name=java:jboss/jdbc/fai-bfsa, \
> connection-url=jdbc:postgresql://tpg0001:5432/xfgb01, \
> max-pool-size=20, \
> min-pool-size=10, \
> new-connection-sql="select 1", \
> check-valid-connection-sql="select 1", \
> user-name=uuuuu, \
> password=uuuuu, \
> background-validation=false, \
> validate-on-match=false, \
> enabled=false, \
> jta=true, \
> use-ccm=true, \
> share-prepared-statements=false, \
> )
> {noformat}
> This is reflected into standalone-full.xml as:
> {code:xml}
> <datasource jta="true" jndi-name="java:jboss/jdbc/fai-bfsa" pool-name="fai-bfsa" enabled="false" use-ccm="true">
> <connection-url>jdbc:postgresql://tpg0001:5432/xfgb01</connection-url>
> <driver-class>org.postgresql.Driver</driver-class>
> <driver>PostgresJDBCDriver</driver>
> <new-connection-sql>select 1</new-connection-sql>
> <pool>
> <min-pool-size>10</min-pool-size>
> <max-pool-size>20</max-pool-size>
> </pool>
> <security>
> <user-name>uuuuu</user-name>
> <password>uuuuu</password>
> </security>
> <validation>
> <check-valid-connection-sql>select 1</check-valid-connection-sql>
> <validate-on-match>false</validate-on-match>
> <background-validation>false</background-validation>
> </validation>
> <statement>
> <share-prepared-statements>false</share-prepared-statements>
> </statement>
> </datasource>
> {code}
> I can now enable and disable that datasource both via cli or console without problem.
> If i create the same datasource via console, with the very same attributes, producing the very same standalone-full.xml (i have diffed them), i cannot enable it nether via cli nor console because i get the following error:
> {noformat}
> 14:33:00,230 ERROR [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer] (MSC service thread 1-3) Error during the deployment of java:jboss/jdbc/fai-bfsa: java.lang.IllegalStateException
> at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.getTransactionIntegration(AbstractDataSourceService.java:409)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.createMcf(AbstractDataSourceService.java:461)
> at org.jboss.jca.deployers.common.AbstractDsDeployer.deployDataSource(AbstractDsDeployer.java:430)
> at org.jboss.jca.deployers.common.AbstractDsDeployer.createObjectsAndInjectValue(AbstractDsDeployer.java:283)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.deploy(AbstractDataSourceService.java:310)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:124)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> 14:33:00,236 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.data-source.java:jboss/jdbc/fai-bfsa: org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/jdbc/fai-bfsa: JBAS010433: Error during the deployment of fai-bfsa
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:131)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS010432: Unable to start the ds because it generated more than one cf
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:126)
> ... 5 more
> 14:33:00,242 INFO [org.jboss.as.controller] (XNIO-4 task-2) JBAS014774: Servicestatus report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.data-source.reference-factory.fai-bfsa (missing) dependents:[service jboss.naming.context.java.jboss.jdbc.fai-bfsa]
> service jboss.data-source-config.fai-bfsa (missing) dependents: [service jboss.data-source.java:jboss/jdbc/fai-bfsa]
> JBAS014777: Services which failed to start: service jboss.data-source.java:jboss/jdbc/fai-bfsa
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-3274) connector values are not available like "requestCount , maxTime, bytesReceived etc " in wildfly (domain mode) 8.0.0.Final
by Rituraj Sinha (JIRA)
[ https://issues.jboss.org/browse/WFLY-3274?page=com.atlassian.jira.plugin.... ]
Rituraj Sinha commented on WFLY-3274:
-------------------------------------
Thanks Jaikiran for replying i am getting the below while running the include-runtime
http-listener=default] :read-resource(include-runtime=true)
{
"outcome" => "success",
"result" => {
"allow-encoded-slash" => false,
"always-set-keep-alive" => true,
"buffer-pipelined-data" => true,
"buffer-pool" => "default",
"certificate-forwarding" => false,
"decode-url" => true,
"enabled" => true,
"max-buffered-request-size" => 16384,
"max-cookies" => 200,
"max-header-size" => 51200,
"max-headers" => 200,
"max-parameters" => 1000,
"max-post-size" => 10485760L,
"proxy-address-forwarding" => false,
"record-request-start-time" => false,
"redirect-socket" => "https",
"socket-binding" => "http",
"url-charset" => "UTF-8",
"worker" => "default"
}
}
it doesn't contain the value we are looking for ...
> connector values are not available like "requestCount , maxTime, bytesReceived etc " in wildfly (domain mode) 8.0.0.Final
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3274
> URL: https://issues.jboss.org/browse/WFLY-3274
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Reporter: Rituraj Sinha
> Assignee: Tomaz Cerar
>
> while using jboss 7.2.0 we were able to fetch above values from the cli command as
> {noformat}
> [domain@test.com:9999 subsystem=web] ls
> configuration valve default-virtual-server=default-host native=false
> connector virtual-server instance-id=${jboss.node.name}
> [domain@test.com:9999 connector] ls
> ajp http
> [domain@test.com:9999 connector] cd http
> [domain@test.com:9999 connector] pwd
> /profile=ha/subsystem=web/connector=http
> [domain@test.com:9999 connector=http] ls
> configuration max-connections=undefined proxy-port=undefined
> ssl max-post-size=2097152 redirect-port=443
> bytesReceived= max-save-post-size=4096 requestCount=
> bytesSent= maxTime= scheme=http
> enable-lookups=false name=http secure=false
> enabled=true processingTime= socket-binding=http
> errorCount= protocol=HTTP/1.1 virtual-server=undefined
> executor=undefined proxy-name=undefined
> {noformat}
>
> Now we have moved to wildfly8 and trying to look for the same values in underetow( as there is no "web" subsystem in wildfly8)
> as below
> {noformat}
> [domain@test2.com:9990 subsystem=undertow] ls
> buffer-cache server default-servlet-container=default statistics-enabled=false (Here there is no connector attribute available as this was in jboss 7.2.0 )
> configuration servlet-container default-virtual-host=default-host
> error-page default-server=default-server instance-id=${jboss.node.name}
> {noformat}
>
> but the listners(HTTP, AJP and HTTPS ) are defined in the server attribute...hence going into server attribute we get the below as
> {noformat}
> [domain@test2.com:9990 server=default-server] ls
> ajp-listener host http-listener https-listener default-host=default-host servlet-container=default
> {noformat}
> after getting into http-listener we get the below
> {noformat}
> [domain@test2.com:9990 http-listener=default] ls
> allow-encoded-slash=false certificate-forwarding=false max-cookies=200 max-post-size=10485760 socket-binding=http
> always-set-keep-alive=true decode-url=true max-header-size=51200 proxy-address-forwarding=false url-charset=UTF-8
> buffer-pipelined-data=true enabled=true max-headers=200 record-request-start-time=false worker=default
> buffer-pool=default max-buffered-request-size=16384 max-parameters=1000 redirect-socket=https
> {noformat}
>
> Can someone please look into it ..?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-3288) Update add-user to use AESH or move it into the CLI
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-3288:
----------------------------------------
That could be very interested, won't go into too much detail in this Jira as it is not directly related shortly I am switching to the SSL related tasks we have outstanding including the out of the box enablement we talked about in Brno - managing an embedded instance could be useful there as well to get it all op based.
I can see this task may end up coming back my way combined with the other stuff ;-)
> Update add-user to use AESH or move it into the CLI
> ---------------------------------------------------
>
> Key: WFLY-3288
> URL: https://issues.jboss.org/browse/WFLY-3288
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management, Scripts
> Reporter: Darran Lofthouse
> Fix For: Awaiting Volunteers
>
>
> Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
> Switching to AESH would allow us to use the implementation there to handle this.
> Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
> Overall this is going to require further discussion so the comments here are just a starting point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-3288) Update add-user to use AESH or move it into the CLI
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-3288:
----------------------------------------
Yes, that's possible. My main concern though is the CLI is a remote tool and one that can manage a domain, so if it does something that won't work remotely or with a domain it should not involve a random end user experience the way the current "module" commands do.
If the regular management API would support updating these properties files, then the CLI could just add high level wrappers over those low level ops. That would be great. But if we *also* drop the existing add-user.sh scripts and only support the CLI, then the user has to launch a server process (perhaps in --admin-only) in order to manipulate users. That's annoying.
One thing I've been thinking about for this kind of problem is being able to launch an embedded AS inside the CLI. This could handle any sort of initial configuration task. The user instead of doing -c on the command line or "connect" in the shell uses "embed" or something, with appropriate other params. The CLI launches an embedded AS and connects via a non-remoting based interface. Thereafter the commands are the same as if the server was remote.
> Update add-user to use AESH or move it into the CLI
> ---------------------------------------------------
>
> Key: WFLY-3288
> URL: https://issues.jboss.org/browse/WFLY-3288
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management, Scripts
> Reporter: Darran Lofthouse
> Fix For: Awaiting Volunteers
>
>
> Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
> Switching to AESH would allow us to use the implementation there to handle this.
> Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
> Overall this is going to require further discussion so the comments here are just a starting point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (DROOLS-329) ClassFormatException when compile template with latest JDK8 (b114)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-329?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated DROOLS-329:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1078146, https://bugzilla.redhat.com/show_bug.cgi?id=1091383 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1078146)
> ClassFormatException when compile template with latest JDK8 (b114)
> ------------------------------------------------------------------
>
> Key: DROOLS-329
> URL: https://issues.jboss.org/browse/DROOLS-329
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final, 6.0.0.CR5
> Environment: Ubuntu linux, latest JDK1.8 (b114) downloaded from https://jdk8.java.net/download.html
> Reporter: Marek Posolda
> Assignee: Mark Proctor
> Fix For: 5.5.1.Final, 6.1.0.Final
>
>
> When trying to run code for compile templates with latest JDK8 (For instance this example https://github.com/droolsjbpm/drools/blob/master/drools-examples/src/main... )
> it will throw an exception like this:
> {code}
> Exception in thread "main" java.lang.RuntimeException: java.lang.RuntimeException: wrong class format
> at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:148)
> at org.drools.template.parser.DefaultTemplateRuleBase.<init>(DefaultTemplateRuleBase.java:62)
> at org.drools.template.parser.TemplateDataListener.<init>(TemplateDataListener.java:74)
> at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:95)
> at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:81)
> at org.drools.examples.templates.SimpleRuleTemplateExample.buildKBase(SimpleRuleTemplateExample.java:84)
> at org.drools.examples.templates.SimpleRuleTemplateExample.executeExample(SimpleRuleTemplateExample.java:49)
> at org.drools.examples.templates.SimpleRuleTemplateExample.main(SimpleRuleTemplateExample.java:43)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
> Caused by: java.lang.RuntimeException: wrong class format
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:263)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:203)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:102)
> at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:122)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1188)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromVariantTypeSignature(LookupEnvironment.java:1244)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeArgumentsFromSignature(LookupEnvironment.java:1031)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1193)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethod(BinaryTypeBinding.java:495)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethods(BinaryTypeBinding.java:577)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:327)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:640)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:619)
> at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:295)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:133)
> at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:183)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:465)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:519)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:368)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:444)
> at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:752)
> at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:464)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler.compile(EclipseJavaCompiler.java:389)
> at org.drools.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49)
> at org.drools.rule.builder.dialect.java.JavaDialect.compileAll(JavaDialect.java:371)
> at org.drools.compiler.DialectCompiletimeRegistry.compileAll(DialectCompiletimeRegistry.java:46)
> at org.drools.compiler.PackageRegistry.compileAll(PackageRegistry.java:102)
> at org.drools.compiler.PackageBuilder.compileAll(PackageBuilder.java:1006)
> at org.drools.compiler.PackageBuilder.compileAllRules(PackageBuilder.java:842)
> at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:831)
> at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:441)
> at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:419)
> at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:139)
> ... 12 more
> Caused by: org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException
> at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:372)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.createNameEnvironmentAnswer(EclipseJavaCompiler.java:287)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:258)
> ... 45 more
> {code}
> Workaround, which worked for me is to switch to Janino compiler (See Workaround description)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-3288) Update add-user to use AESH or move it into the CLI
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-3288:
----------------------------------------
Maybe the CLI could support plug-in modules of some sort so if add-user is available it can 'expose' it. But that is probably heading more into general plans for the CLI.
> Update add-user to use AESH or move it into the CLI
> ---------------------------------------------------
>
> Key: WFLY-3288
> URL: https://issues.jboss.org/browse/WFLY-3288
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management, Scripts
> Reporter: Darran Lofthouse
> Fix For: Awaiting Volunteers
>
>
> Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
> Switching to AESH would allow us to use the implementation there to handle this.
> Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
> Overall this is going to require further discussion so the comments here are just a starting point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months