[JBoss JIRA] (WFLY-2592) A server-to-server communication via outbound connection is not working
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/WFLY-2592?page=com.atlassian.jira.plugin.... ]
Wolf-Dieter Fink commented on WFLY-2592:
----------------------------------------
What you mean by remoting (native) is there a difference for the configuration of the outbound-connection (I did not found any hint in the docs).
Not 100% sure, but there should be no firewall in between and I've used ejb-multi-server example before which include outbound-connection and scoped-context for the same ejb-ejb invocation.
The scoped context works fine with the same ports.
Maybe I need to enlarge my example a bit and use scoped-context as well, but again is there a difference regarding (native) remoting?
> A server-to-server communication via outbound connection is not working
> -----------------------------------------------------------------------
>
> Key: WFLY-2592
> URL: https://issues.jboss.org/browse/WFLY-2592
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB, Remoting
> Affects Versions: 8.0.0.Beta1
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
> Priority: Critical
> Labels: ejb, remoting
> Attachments: networktraffic, server-client.log, server-server.log
>
>
> A ejb invocation from a SLSB is configured similar to AS7 (EAP6) to call a remote server fail in WildFly with the ERROR message " EJBCLIENT000025: No EJB receiver available for handling".
> The logfiles of client(server) and remote-server are attached, also a WireShark dump of the related network traffic.
> A standalone client at the same machine is able to call the remote application.
--
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, 3 months
[JBoss JIRA] (WFLY-2699) liferay portal does not work
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2699?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-2699:
--------------------------------------
I think I know what may be causing this. Is there any chance that liferay is setting both:
Transfer-Encoding: chunked
Content-Length: x
headers?
It looks like Undertow does not handle this situation correctly, according to the RFC in this case the content-length should be ignored, which Undertow is not doing. I will fix upstream, which will hopefully resolve the issue.
> liferay portal does not work
> ----------------------------
>
> Key: WFLY-2699
> URL: https://issues.jboss.org/browse/WFLY-2699
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Michał Zegan
> Assignee: Stuart Douglas
>
> Hello.
> I have commpiled the full wildfly package and set gerrit, jenkins, and the nexus repo manager on it, all works perfectly.
> The problem:
> I tried to deploy liferay on the same instance.
> I did everything and then deployed the webapp.
> The deploy was successful, but it didn't work.
> I have the appserver behind apache reverse proxy, trying to load a page displays error 502 proxy error.
> I checked with telnet what happens by telnetting to the backend appserver and sending a GET request for /.
> The response was incorrect, I got the expected document but without the status line and headers, that makes it clear why apache sait error 502.
> Liferay probably works with jboss as 7 and tomcat/etc, so I think undertow must have something to do with 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
12 years, 3 months
[JBoss JIRA] (WFLY-2706) ServletContext.getServerInfo: Undertow instead of JBoss or Wildfly
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2706?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-2706.
----------------------------------
Resolution: Done
> ServletContext.getServerInfo: Undertow instead of JBoss or Wildfly
> ------------------------------------------------------------------
>
> Key: WFLY-2706
> URL: https://issues.jboss.org/browse/WFLY-2706
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: CentOS, OpenJDK7
> Reporter: Andre Pankraz
> Assignee: Stuart Douglas
>
> javax.servlet.ServletContext.getServerInfo() identifies Wildfly with:
> "Undertow" and not with JBoss or Wildfly. Is this intentional?
> Some frameworks or extensions (e.g. JavaMelody) use this server info to provide application server specific behaviour.
> So Wildfly (or the newer JBoss AS) is quite different to past versions and this must not be the wrong step to tell something different here, but providing the embedded Servlet Container "Undertow" as response might not be intentional?
> I would suggest to show something with "JBoss" even though Wildfly is the community version name (BTW great move...who wants to have wild flies in his data center...where is our swatter)
> JavaMelody example code, triggered by HttpSessionListener.contextInitialized(ServletContextEvent event) -> initServletContext(event.getServletContext()):
> void initServletContext(ServletContext context) {
> assert context != null;
> this.servletContext = context;
> final String serverInfo = servletContext.getServerInfo();
> jboss = serverInfo.contains("JBoss") ;
> glassfish = serverInfo.contains("GlassFish")
> || serverInfo.contains("Sun Java System Application Server");
> weblogic = serverInfo.contains("WebLogic");
> jonas = System.getProperty("jonas.name") != 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, 3 months
[JBoss JIRA] (WFLY-2589) ReadTransformedResourceOperation should set include-defaults=false when calling read-resource
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2589?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-2589:
-----------------------------------
Fix Version/s: 8.0.0.Final
> ReadTransformedResourceOperation should set include-defaults=false when calling read-resource
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-2589
> URL: https://issues.jboss.org/browse/WFLY-2589
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Beta1
> Reporter: Kabir Khan
> Assignee: Brian Stansberry
> Fix For: 8.0.0.Final
>
>
> This needs further investigation, but it seems to mean that we have a lot of ModelFixers used in the wrong situation. i.e. the when transforming resources, attributes that should be undefined reach the transformers as defined with the default value set instead.
> This needs a bit of thinking about [~jmesnil] mentioned this a few weeks ago as well. I'd like to see if he remembers before fixing
--
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, 3 months
[JBoss JIRA] (WFLY-2866) PersistentResourceXMLDescription does not marshal default attribute values
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-2866:
--------------------------------------
Summary: PersistentResourceXMLDescription does not marshal default attribute values
Key: WFLY-2866
URL: https://issues.jboss.org/browse/WFLY-2866
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Domain Management
Affects Versions: 8.0.0.CR1
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 8.0.0.Final
When PersistentResourceXMLDescription marshals a resource's attributes, it will not marshal a value stored in the model if it matches the attribute's default value.
We should marshal the value provided by the user. Otherwise we will change the config file from what the user provided for reasons unrelated to management actions initiated by the user.
DefaultAttributeMarshaller marshals default values.
--
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, 3 months
[JBoss JIRA] (WFLY-2027) EE Default DataSource is not working
by Guido Granobles (JIRA)
[ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.... ]
Guido Granobles commented on WFLY-2027:
---------------------------------------
@Arun
Thank you for your help, I did the changes in my persistence.xml as you suggested and it's working fine now. I can see that it should have at least one default datasource. After that, I can have more datasources with other names.
> EE Default DataSource is not working
> ------------------------------------
>
> Key: WFLY-2027
> URL: https://issues.jboss.org/browse/WFLY-2027
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
> Affects Versions: 8.0.0.Alpha4
> Reporter: Lincoln Baxter III
> Assignee: Eduardo Martins
> Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
> {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database
> in the operational environment (see Section EE.2.6, “Database”). The Java EE
> Product Provider must also provide a preconfigured, default data source for use by
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a
> DataSource resource reference to the default data source using the lookup element
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to
> the product's default data source.
> For example, the following will map to a preconfigured data source for the
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <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://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persis...">
> <persistence-unit name="default" transaction-type="JTA">
> </persistence-unit>
> </persistence>{code}
> Results in:
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> ... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code} <persistence-unit name="default" transaction-type="JTA">
> <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
> <exclude-unlisted-classes>false</exclude-unlisted-classes>
> </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__]
> service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE]
> {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, 3 months
[JBoss JIRA] (JBRULES-3723) 'IDEOGRAPHIC SPACE' (U+3000) in DSL fails
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3723?page=com.atlassian.jira.plug... ]
Edson Tirelli resolved JBRULES-3723.
------------------------------------
Assignee: Edson Tirelli (was: Mark Proctor)
Fix Version/s: 6.0.0.Alpha1
Resolution: Done
This was fixed about a year ago with the following commit:
https://github.com/droolsjbpm/drools/commit/17f4280
> 'IDEOGRAPHIC SPACE' (U+3000) in DSL fails
> -----------------------------------------
>
> Key: JBRULES-3723
> URL: https://issues.jboss.org/browse/JBRULES-3723
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: drools-compiler-DSL
> Affects Versions: 5.5.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Edson Tirelli
> Fix For: 6.0.0.Alpha1
>
>
> When DSL contains ' ' (='IDEOGRAPHIC SPACE' (U+3000)), DSLMapLexer fails with "DSL lexer error" (Internally, it's a NoViableAltException). IDEOGRAPHIC SPACE is commonly used in Japan so please allow it to use. It doesn't mean that I want to use IDEOGRAPHIC SPACE as an alternative to ASCII whitespace. Just to use it as same as usual unicode characters.
--
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, 3 months
[JBoss JIRA] (WFLY-2865) AttributeTransformationRule "ignored" if op is discarded
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-2865:
--------------------------------------
Summary: AttributeTransformationRule "ignored" if op is discarded
Key: WFLY-2865
URL: https://issues.jboss.org/browse/WFLY-2865
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Domain Management
Affects Versions: 8.0.0.CR1
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 8.0.0.Final
Imagine a scenario like the following:
```
parent.addChildResource(RemotingEndpointResource.ENDPOINT_PATH)
.getAttributeBuilder()
.setDiscard(DiscardAttributeChecker.UNDEFINED, RemotingEndpointResource.ATTRIBUTES)
.addRejectCheck(RejectAttributeChecker.DEFINED, RemotingEndpointResource.ATTRIBUTES.toArray(new AttributeDefinition[RemotingEndpointResource.ATTRIBUTES.size()]))
.end() .addOperationTransformationOverride(ModelDescriptionConstants.ADD)
.inheritResourceAttributeDefinitions() .setCustomOperationTransformer(OperationTransformer.DISCARD)
.end()
```
The idea is to discard "add" if any parameter is defined, reject otherwise. The legacy slave can ignore the whole resource if it isn't really configured by the user, but any detail config by the user must result in failure.
Problem is AttributeTransformationRule will do a "reject" when it gets a prepared response from the slave, but using setCustomOperationTransformer(OperationTransformer.DISCARD) means the op will be discarded, so there will be no prepared response and thus no rejection.
Solution is to have AttributeTransformationRule register a OperationResultTransformer that deals with this situation.
--
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, 3 months