[JBoss JIRA] (JBASM-43) jsch object can not be created
by ali ahmed (JIRA)
ali ahmed created JBASM-43:
------------------------------
Summary: jsch object can not be created
Key: JBASM-43
URL: https://issues.jboss.org/browse/JBASM-43
Project: JBoss AS Server Manager
Issue Type: Bug
Reporter: ali ahmed
Assignee: Shelly McGowan
create a singleton ejb that contains a scheduler method which tries to create Jsch object (to create a session to list directories). the debug hangs and no exception is thrown.
tried using of jsch-0.1.40 and jsch-0.1.50 and same result
--
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
12 years, 7 months
[JBoss JIRA] (DROOLS-364) ClasspathKieProject fails vfs: path for jar deployments and exploded ear
by Nicolas-Xavier Vanderlinden (JIRA)
[ https://issues.jboss.org/browse/DROOLS-364?page=com.atlassian.jira.plugin... ]
Nicolas-Xavier Vanderlinden updated DROOLS-364:
-----------------------------------------------
Environment: JBoss AS 7.1.1
> ClasspathKieProject fails vfs: path for jar deployments and exploded ear
> ------------------------------------------------------------------------
>
> Key: DROOLS-364
> URL: https://issues.jboss.org/browse/DROOLS-364
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.Final
> Environment: JBoss AS 7.1.1
> Reporter: Nicolas-Xavier Vanderlinden
> Assignee: Mark Proctor
>
> Drools is not able to load kmodule.xml from an exploded ear.
> 17:24:45,116 WARN Unable to load pom.properties tried recursing down from\Project\Geline\jboss-as-7.1.1.Final\standalone\deployments\geline.ear\service-impl-1.4.0-SNAPcontent
> null
> 17:24:45,116 ERROR Unable to build index of kmodule.xml url=vfs:/E:/Project/Geline/jboss-as-7.1.1.Final/standalone/deployments/geline.ear/service-impl-1.4.0-SNAPSHOT.jar/META-INF/kmodule.xml
> null
--
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
12 years, 7 months
[JBoss JIRA] (DROOLS-386) CommandFactoryServiceImpl cannot be cast to CommandFactoryService
by Nicolas-Xavier Vanderlinden (JIRA)
[ https://issues.jboss.org/browse/DROOLS-386?page=com.atlassian.jira.plugin... ]
Nicolas-Xavier Vanderlinden commented on DROOLS-386:
----------------------------------------------------
{code}
private static void loadProvider() {
try {
Class<CommandFactoryService> cls = (Class<CommandFactoryService>) Class.forName( "org.drools.core.command.impl.CommandFactoryServiceImpl" );
setCommandFactoryProvider( cls.newInstance() );
} catch ( Exception e2 ) {
throw new RuntimeException( "Provider org.drools.core.command.impl.CommandFactoryProviderImpl could not be set.",
e2 );
}
}
private static synchronized void setCommandFactoryProvider(CommandFactoryService provider) {
CommandFactory.provider = provider;
}
{code}
{code}
public class CommandFactoryServiceImpl implements KieCommands {
{code}
> CommandFactoryServiceImpl cannot be cast to CommandFactoryService
> -----------------------------------------------------------------
>
> Key: DROOLS-386
> URL: https://issues.jboss.org/browse/DROOLS-386
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.Final
> Environment: JBoss AS 7.1.1
> Reporter: Nicolas-Xavier Vanderlinden
> Assignee: Mark Proctor
>
> Caused by: java.lang.ClassCastException: org.drools.core.command.impl.CommandFactoryServiceImpl cannot be cast to org.drools.command.CommandFactoryService
> at org.drools.command.CommandFactory.loadProvider(CommandFactory.java:372) [knowledge-api-6.0.1.Final.jar:6.0.1.Final]
> CommandFactoryServiceImpl does not implement CommandFactoryService
--
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
12 years, 7 months
[JBoss JIRA] (DROOLS-386) CommandFactoryServiceImpl cannot be cast to CommandFactoryService
by Nicolas-Xavier Vanderlinden (JIRA)
Nicolas-Xavier Vanderlinden created DROOLS-386:
--------------------------------------------------
Summary: CommandFactoryServiceImpl cannot be cast to CommandFactoryService
Key: DROOLS-386
URL: https://issues.jboss.org/browse/DROOLS-386
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.0.0.Final
Environment: JBoss AS 7.1.1
Reporter: Nicolas-Xavier Vanderlinden
Assignee: Mark Proctor
Caused by: java.lang.ClassCastException: org.drools.core.command.impl.CommandFactoryServiceImpl cannot be cast to org.drools.command.CommandFactoryService
at org.drools.command.CommandFactory.loadProvider(CommandFactory.java:372) [knowledge-api-6.0.1.Final.jar:6.0.1.Final]
CommandFactoryServiceImpl does not implement CommandFactoryService
--
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
12 years, 7 months
[JBoss JIRA] (WFLY-2681) HTTP Management Interface Content-Type header is broken
by Dino Tsoumakis (JIRA)
Dino Tsoumakis created WFLY-2681:
------------------------------------
Summary: HTTP Management Interface Content-Type header is broken
Key: WFLY-2681
URL: https://issues.jboss.org/browse/WFLY-2681
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Domain Management
Affects Versions: 8.0.0.CR1
Reporter: Dino Tsoumakis
Assignee: Brian Stansberry
Fix For: 8.0.0.Final
*Problem:*
HTTP Domain Management Interfaces returns invalid Content-Type header:
{code}
Content-Type: application/json;utf-8
{code}
This breaks management for lots of REST clients.
*Proposed solution:*
According to [W3C|https://www.w3.org/International/O-HTTP-charset] and [rfc2616|http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7] the Content-Type header should be:
{code}
Content-Type: application/json; charset=utf-8
{code}
BTW: JBoss 7.1.1 behaviour is ok. It does not send any charset parameter at all.
*Example:*
Request contains the following headers:
{code}
3 > Accept: application/json
3 > Content-Type: application/json
...
{code}
Wildfly 8.0.0.CR1 response after digest authentication is:
{code}
4 < 200
4 < Authentication-Info: nextnonce="EB9WbpMrUuwNMTM4NzY3MDc2NzAxMgXaHXwaKEWPxbxUj1ihuOg="
4 < Connection: keep-alive
4 < Content-Type: application/json;utf-8
4 < Transfer-Encoding: chunked
{code}
JBoss 7.1.1 response after digest authentication is:
{code}
4 < 200
4 < Content-type: application/json
4 < Date: Sat, 21 Dec 2013 23:48:36 GMT
4 < Transfer-encoding: chunked
{code}
--
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
12 years, 7 months
[JBoss JIRA] (WFLY-2680) java:comp/DefaultDataSource doesn't work in persistence.xml
by arjan tijms (JIRA)
arjan tijms created WFLY-2680:
---------------------------------
Summary: java:comp/DefaultDataSource doesn't work in persistence.xml
Key: WFLY-2680
URL: https://issues.jboss.org/browse/WFLY-2680
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: arjan tijms
Having a persistence.xml with the following content fails the deployment on WildFly 8 CR1:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
<persistence-unit name="testPU">
<jta-data-source>java:comp/DefaultDataSource</jta-data-source>
</persistence-unit>
</persistence>
{code}
It results in the following error:
{noformat}
13:51:40,367 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "dynamic-named-query.war")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dynamic-named-query.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.module.dynamic-named-query.dynamic-named-query.DefaultDataSource]"]}
{noformat}
When I proposed the feature for the default data source over at the Java EE JIRA (https://java.net/jira/browse/JAVAEE_SPEC-4) I intended this to work. In the description I hinted that the standard JNDI name would be the standard alternative for {{java:jboss/datasources/ExampleDS}} on JBoss. The latter indeed does work in {{persistence.xml}} using WildFly 8 CR1.
Omitting the {{jta-data-source}} element altogether *does* work, which is great. However, I foresee a lot of users tripping over this in the future and just giving up the idea of using a default data source, especially since the error message is very cryptic for new developers.
In GlassFish 4 using {{java:comp/DefaultDataSource}} in {{persistence.xml}} does work.
See also WFLY-2027 and WFLY-2158
--
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
12 years, 7 months
[JBoss JIRA] (WFLY-2533) Add ability to set default character encoding on a subsystem level
by Markus Karnik (JIRA)
[ https://issues.jboss.org/browse/WFLY-2533?page=com.atlassian.jira.plugin.... ]
Markus Karnik edited comment on WFLY-2533 at 12/22/13 8:18 AM:
---------------------------------------------------------------
I got an error "Message: JBAS014788: Unexpected attribute 'default-encoding' encountered" when try to configure "default-encoding" server-wide by setting:
{code:title=standalone.xml|borderStyle=solid}
<servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only" default-encoding="UTF-8">
{code}
Stacktrace
{noformat}
12:46:02,285 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.CR1.jar:8.0.0.CR1]
at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.CR1.jar:8.0.0.CR1]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.0.CR1.jar:8.0.0.CR1]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[346,137]
Message: JBAS014788: Unexpected attribute 'default-encoding' encountered
{noformat}
probably you missed adding ServletContainerDefinition.DEFAULT_ENCODING to undertow/src/main/java/org/wildfly/extension/undertow/UndertowSubsystemParser_1_0.java? Line 106. jboss-web.xml method works fine.
was (Author: markus.karnik):
I got an error "Message: JBAS014788: Unexpected attribute 'default-encoding' encountered" when try to configure "default-encoding" server-wide by setting:
{code:title=standalone.xml|borderStyle=solid}
<servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only" default-encoding="UTF-8">
{code}
Stacktrace
{noformat}
12:46:02,285 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.CR1.jar:8.0.0.CR1]
at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.CR1.jar:8.0.0.CR1]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.0.CR1.jar:8.0.0.CR1]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[346,137]
Message: JBAS014788: Unexpected attribute 'default-encoding' encountered
{noformat}
propably you missed adding ServletContainerDefinition.DEFAULT_ENCODING to undertow/src/main/java/org/wildfly/extension/undertow/UndertowSubsystemParser_1_0.java? Line 106! jboss-web.xml method works.
> Add ability to set default character encoding on a subsystem level
> ------------------------------------------------------------------
>
> Key: WFLY-2533
> URL: https://issues.jboss.org/browse/WFLY-2533
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Reporter: Stuart Douglas
> Assignee: Tomaz Cerar
> Fix For: 8.0.0.CR1
>
>
> Stuart: the charset one should be pretty simple, just an attribute on <servlet-container?
> Stuart: ideally we would also have it in jboss-web.xml as well
> Stuart: I should also add an option to use the connector encoding
> Stuart: as connectors have their own encoding set
> Stuart: that is used to decode the URL
> Stuart: we should have an option to use the connector encoding as the default encoding
--
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
12 years, 7 months
[JBoss JIRA] (WFLY-2533) Add ability to set default character encoding on a subsystem level
by Markus Karnik (JIRA)
[ https://issues.jboss.org/browse/WFLY-2533?page=com.atlassian.jira.plugin.... ]
Markus Karnik commented on WFLY-2533:
-------------------------------------
I got an error "Message: JBAS014788: Unexpected attribute 'default-encoding' encountered" when try to configure "default-encoding" server-wide by setting:
{code:title=standalone.xml|borderStyle=solid}
<servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only" default-encoding="UTF-8">
{code}
Stacktrace
{noformat}
12:46:02,285 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.CR1.jar:8.0.0.CR1]
at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.CR1.jar:8.0.0.CR1]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.0.CR1.jar:8.0.0.CR1]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[346,137]
Message: JBAS014788: Unexpected attribute 'default-encoding' encountered
{noformat}
propably you missed adding ServletContainerDefinition.DEFAULT_ENCODING to undertow/src/main/java/org/wildfly/extension/undertow/UndertowSubsystemParser_1_0.java? Line 106! jboss-web.xml method works.
> Add ability to set default character encoding on a subsystem level
> ------------------------------------------------------------------
>
> Key: WFLY-2533
> URL: https://issues.jboss.org/browse/WFLY-2533
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Reporter: Stuart Douglas
> Assignee: Tomaz Cerar
> Fix For: 8.0.0.CR1
>
>
> Stuart: the charset one should be pretty simple, just an attribute on <servlet-container?
> Stuart: ideally we would also have it in jboss-web.xml as well
> Stuart: I should also add an option to use the connector encoding
> Stuart: as connectors have their own encoding set
> Stuart: that is used to decode the URL
> Stuart: we should have an option to use the connector encoding as the default encoding
--
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
12 years, 7 months
[JBoss JIRA] (WFLY-334) HA Singleton deployer for applications
by Nico Schlebusch (JIRA)
[ https://issues.jboss.org/browse/WFLY-334?page=com.atlassian.jira.plugin.s... ]
Nico Schlebusch commented on WFLY-334:
--------------------------------------
Good day,
I am on leave and will return to the office on Monday, 6 January 2014. For any urgent matters log a support ticket with support(a)nha.co.za or at telephone 0860142536.
Kind Regards
Nico Schlebusch
The e-mail and attachments are confidential and intended only for selected recipients. If you have received it in error, you may not in any way disclose or rely on the contents. You
may not keep, copy or distribute the e-mail. Should you receive it, immediately notify the sender of the error and delete the e-mail. Also note that this form of communication is
not secure, it can be intercepted, and may not necessarily be free of errors and viruses in spite of reasonable efforts to secure this medium.
> HA Singleton deployer for applications
> --------------------------------------
>
> Key: WFLY-334
> URL: https://issues.jboss.org/browse/WFLY-334
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Clustering, Domain Management
> Reporter: Wolf-Dieter Fink
> Assignee: Paul Ferraro
> Labels: deployers, hasingleton
> Fix For: 8.0.0.Final
>
>
> A HASingleton deployer should be provided in standalone and domain mode.
> To be able to migrate such singleton applications from former AS versions.
--
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
12 years, 7 months