[JBoss JIRA] (JGRP-1712) FRAG / FRAG2: CONFIG event overrides user-configured frag_size value
by Bela Ban (JIRA)
Bela Ban created JGRP-1712:
------------------------------
Summary: FRAG / FRAG2: CONFIG event overrides user-configured frag_size value
Key: JGRP-1712
URL: https://issues.jboss.org/browse/JGRP-1712
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Minor
Fix For: 3.4
When we have multiple FRAG or FRAG2 in the same stack (with different IDs), then each fragmentation protocol sends a CONFIG event (with {{frag_size}}) up and down the stack. When this event is received by a different frag protocol, then it will set its own {{frag_size}}, overriding the previously set value.
Investigate whether we still need the CONFIG event.
--
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
11 years, 2 months
[JBoss JIRA] (JBASMP-52) jboss-as:deploy deploys ear but doesn't deploy contained ejb module
by Matías Blasi (JIRA)
Matías Blasi created JBASMP-52:
----------------------------------
Summary: jboss-as:deploy deploys ear but doesn't deploy contained ejb module
Key: JBASMP-52
URL: https://issues.jboss.org/browse/JBASMP-52
Project: JBoss AS Maven Plugins
Issue Type: Bug
Components: deploy
Affects Versions: 7.4.Final
Environment: Linux hostname 3.7.10-gentoo #1 SMP Fri Aug 30 17:01:59 ART 2013 x86_64 Intel(R) Core(TM) i5-2467M CPU @ 1.60GHz GenuineIntel GNU/Linux
Reporter: Matías Blasi
Assignee: James Perkins
I have a simple ear application (build with maven-ear-plugin).
This application contains just a persistence-unit definition (persistence.xml) and a ejb-module.
The ejb module is another maven build, containing some ejb3, handled with maven-ejb-plugin.
The ear file is correctly built:
myapp.ear
|
+ META-INF/application.xml
+ lib/allmylibs.jar
+ myejb.jar
When trying to deploy the ear with the jboss-as:deploy, the application is deployed (the persistence unit deployment logs in server.log), but no ejb is registered, anyway, no errors in log, and BUILD SUCCESFUL after mvn command.
Finally, an ear file is present under $JBOSS_HOME/standalone/data/content
The strange thing is that if I get that generated ear file, I can succesfully deploy it through the management console, or by copying it to a folder scanned by a deployment-scanner (in both cases the ejbs are correctly deployed)
Nothing found in google! :(
I tried with all the plugin version from 7.1.1 to 7.4.
Also a lot of tries with different maven-ear-plugin and maven-jboss-as-plugin configuration options.... no lucky after two days of work.
Regards,
Matías.
--
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
11 years, 2 months
[JBoss JIRA] (JBAS-9548) JBoss 5.0 log file is stopped getting updated after a while
by Ramesh Kodali (JIRA)
Ramesh Kodali created JBAS-9548:
-----------------------------------
Summary: JBoss 5.0 log file is stopped getting updated after a while
Key: JBAS-9548
URL: https://issues.jboss.org/browse/JBAS-9548
Project: Application Server 3 4 5 and 6
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: JBossAS-5.0.1.GA
Environment: Java 2.6, JBoss 5.1
Reporter: Ramesh Kodali
Assignee: Alessio Soldano
We are using log back xml to configure application specific log file and copied the log back XML in JBoss class path. After server restarts, JBoss is generating the log files successfully. It was working from some time even in production. Recently we have noticed a weird issue in our dev environment that, application logs are writing in to log file and stopped writing after a while. We have to restart the JBoss to get back the Log files status. This issue seems coming continuously now a days. I would like to know is it some thing related to JBoss or more of environment issue.
Here below the log back configuration we had
<appender name="FILE"
class="ch.qos.logback.core.rolling.RollingFileAppender">
<File>${jboss.server.log.dir}/cbs2.log</File>
<Append>true</Append>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<FileNamePattern>${jboss.server.log.dir}/cbs2.%d{yyyy-MM-dd}.%i.log.gz
</FileNamePattern>
<timeBasedFileNamingAndTriggeringPolicy
class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
<maxFileSize>200MB</maxFileSize>
</timeBasedFileNamingAndTriggeringPolicy>
</rollingPolicy>
<layout class="ch.qos.logback.classic.PatternLayout">
<Pattern>%d{yyyy-MM-dd;HH:mm:ss.SSS} [%thread] %-5level %logger{36} [%M:%L]
[%X{id}->%X{bcId}:%X{userId}:%X{loginId}] - %msg%n</Pattern>
</layout>
</appender>
--
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
11 years, 2 months
[JBoss JIRA] (WFLY-2208) CLI over HTTP should switch to / be redirected to https automatically.
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-2208:
--------------------------------------
Summary: CLI over HTTP should switch to / be redirected to https automatically.
Key: WFLY-2208
URL: https://issues.jboss.org/browse/WFLY-2208
Project: WildFly
Issue Type: Enhancement
Components: CLI, Domain Management
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 8.0.0.Beta1
When using the native interface a TLS upgrade was already automatically in place once a keystore was added to the linked realm.
With the switch to http with an upgrade there is no automatic switch to https.
--
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
11 years, 2 months
[JBoss JIRA] (WFLY-2207) CLI Unable to connect using https-remoting address.
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-2207:
--------------------------------------
Summary: CLI Unable to connect using https-remoting address.
Key: WFLY-2207
URL: https://issues.jboss.org/browse/WFLY-2207
Project: WildFly
Issue Type: Bug
Components: CLI
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Priority: Critical
Fix For: 8.0.0.Beta1
The CLI is failing to connect over https with the following: -
{code}
[disconnected /] connect https-remoting://localhost:9993
The controller is not available at localhost:9993: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
{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
11 years, 2 months