[JBoss JIRA] (WFLY-1094) Use own JSSE Provider for http Connector
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-1094?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-1094:
-----------------------------------
The patch is not usable as-is because the management model has to remain compatible, thus the schema rev has to be bumped up at a minimum.
When it comes to security providers, we should be allowing:
* Providers to be specified by provider name (search system class path)
* Providers to be specified by module name (use ServiceLoader on given module for the first acceptable {{Provider}} of the right type)
* Providers to be specified by module name + provider name (use ServiceLoader on given module for a {{Provider}} with the given ID)
* Providers to be specified by module name + class name (load the {{Provider}} subclass directly by name and class loader)
This allows users to install alternative providers (e.g. BouncyCastle or whatever) as modules. We *should* also provide some way to specify the security providers that are available to deployments on a global and per-deployment basis.
> Use own JSSE Provider for http Connector
> ----------------------------------------
>
> Key: WFLY-1094
> URL: https://issues.jboss.org/browse/WFLY-1094
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Hauke Mehrtens
> Labels: https, jsse, ssl
> Attachments: ssl-protocol.patch
>
>
> We are using our own JSSE Provider implementation for TLS to add support for HTTPS with preshared key to one http connector, while the others still use the default JSSE provider.
> In JBoss 5 we added sslProtocol="RFC4279", while RFC4279 is the name of our provider, to one Connector entry in the file server/default/deploy/jbossweb.sar/server.xml. This option is not available in JBoss 7.1 any more and we could not find a way to make one connector use our provider while the others are using the default one.
> To fix this issue for use we used the attached patch. We would like to get this patch into the next version of JBoss, so we do not have to modify the source code by our self any more. This patch was tested with JBoss 7.1.2, but it still applies against the master branch. If we should do any changed to the patch or if you want to get it in an other form please inform us.
> With this patch we are able to specify our JSSE provider like this:
> {code:xml}
> <connector name="httpspsk" protocol="HTTP/1.1" scheme="https" socket-binding="httpspsk" secure="true">
> <ssl name="ssl" key-alias="intended purpose ssl test from bremen online services" password="123456" certificate-key-file="${jboss.server.config.dir}/governikus_ssl.jks" protocol="ALL" keystore-type="JKS" ssl_protocol="RFC4279"/>
> </connector>
> {code}
> This is related to Red Hat Customer Portal support case 00721624 "Additional JSSE Provider on socket bindings and connectors"
--
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, 8 months
[JBoss JIRA] (LOGMGR-68) periodic-rotating-file-handler not rotating
by Alexander Yerenkow (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-68?page=com.atlassian.jira.plugin.... ]
Alexander Yerenkow commented on LOGMGR-68:
------------------------------------------
I made a bit of investigations, and found out that setting HOUR without AM_PM, and call after that getTimeInMillis will reset time to 12:00, instead of keeping it at 00:00.
Probably would be better to move HALF_DAY case in separate case: , to make all consistent and probably fix my bug.
It appears that roll never happen due to:
for log events from 24 apr to 25 apr 00:00 next roll time is set far in future - 12:00 25 apr. But when it arrives (25 apr from 00 till 25 apr 12:00), the roll time set again in future - now in 26 apr 00:00.
> periodic-rotating-file-handler not rotating
> -------------------------------------------
>
> Key: LOGMGR-68
> URL: https://issues.jboss.org/browse/LOGMGR-68
> Project: JBoss Log Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.4.0.Final
> Environment: FreeBSD hostname 10.0-CURRENT FreeBSD 10.0-CURRENT #3 r242434M
> Reporter: Alexander Yerenkow
> Assignee: David Lloyd
>
> During day there could be few restarts of JBoss 7.2.0
> If there was one, next day logs aren't rotated.
> edb.log (contains record from 22 apr till now)
> edb.log.2013-04-12 (contains record from 06 apr till 12)
> edb.log.2013-04-17 (contains record from 13 apr till 17)
> edb.log.2013-04-19 (contains record from 18 apr till 19)
> Can't see clear system;
> Here's my config:
> <periodic-rotating-file-handler name="EDB" autoflush="true">
> <formatter>
> <pattern-formatter pattern="%d %-5p [%c] (%t:%x) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="edb.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="true"/>
> </periodic-rotating-file-handler>
> This all worked as charm in 7.1.1 / 7.1.3.
> Should I run some tests/ gather some info to fix this?
--
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, 8 months
[JBoss JIRA] (WFLY-1094) Use own JSSE Provider for http Connector
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-1094?page=com.atlassian.jira.plugin.... ]
David Lloyd updated WFLY-1094:
------------------------------
Description:
We are using our own JSSE Provider implementation for TLS to add support for HTTPS with preshared key to one http connector, while the others still use the default JSSE provider.
In JBoss 5 we added sslProtocol="RFC4279", while RFC4279 is the name of our provider, to one Connector entry in the file server/default/deploy/jbossweb.sar/server.xml. This option is not available in JBoss 7.1 any more and we could not find a way to make one connector use our provider while the others are using the default one.
To fix this issue for use we used the attached patch. We would like to get this patch into the next version of JBoss, so we do not have to modify the source code by our self any more. This patch was tested with JBoss 7.1.2, but it still applies against the master branch. If we should do any changed to the patch or if you want to get it in an other form please inform us.
With this patch we are able to specify our JSSE provider like this:
{code:xml}
<connector name="httpspsk" protocol="HTTP/1.1" scheme="https" socket-binding="httpspsk" secure="true">
<ssl name="ssl" key-alias="intended purpose ssl test from bremen online services" password="123456" certificate-key-file="${jboss.server.config.dir}/governikus_ssl.jks" protocol="ALL" keystore-type="JKS" ssl_protocol="RFC4279"/>
</connector>
{code}
This is related to Red Hat Customer Portal support case 00721624 "Additional JSSE Provider on socket bindings and connectors"
was:
We are using our own JSSE Provider implementation for TLS to add support for HTTPS with preshared key to one http connector, while the others still use the default JSSE provider.
In JBoss 5 we added sslProtocol="RFC4279", while RFC4279 is the name of our provider, to one Connector entry in the file server/default/deploy/jbossweb.sar/server.xml. This option is not available in JBoss 7.1 any more and we could not find a way to make one connector use our provider while the others are using the default one.
To fix this issue for use we used the attached patch. We would like to get this patch into the next version of JBoss, so we do not have to modify the source code by our self any more. This patch was tested with JBoss 7.1.2, but it still applies against the master branch. If we should do any changed to the patch or if you want to get it in an other form please inform us.
With this patch we are able to specify our JSSE provider like this:
<connector name="httpspsk" protocol="HTTP/1.1" scheme="https" socket-binding="httpspsk" secure="true">
<ssl name="ssl" key-alias="intended purpose ssl test from bremen online services" password="123456" certificate-key-file="${jboss.server.config.dir}/governikus_ssl.jks" protocol="ALL" keystore-type="JKS" ssl_protocol="RFC4279"/>
</connector>
This is related to Red Hat Customer Portal support case 00721624 "Additional JSSE Provider on socket bindings and connectors"
> Use own JSSE Provider for http Connector
> ----------------------------------------
>
> Key: WFLY-1094
> URL: https://issues.jboss.org/browse/WFLY-1094
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Hauke Mehrtens
> Labels: https, jsse, ssl
> Attachments: ssl-protocol.patch
>
>
> We are using our own JSSE Provider implementation for TLS to add support for HTTPS with preshared key to one http connector, while the others still use the default JSSE provider.
> In JBoss 5 we added sslProtocol="RFC4279", while RFC4279 is the name of our provider, to one Connector entry in the file server/default/deploy/jbossweb.sar/server.xml. This option is not available in JBoss 7.1 any more and we could not find a way to make one connector use our provider while the others are using the default one.
> To fix this issue for use we used the attached patch. We would like to get this patch into the next version of JBoss, so we do not have to modify the source code by our self any more. This patch was tested with JBoss 7.1.2, but it still applies against the master branch. If we should do any changed to the patch or if you want to get it in an other form please inform us.
> With this patch we are able to specify our JSSE provider like this:
> {code:xml}
> <connector name="httpspsk" protocol="HTTP/1.1" scheme="https" socket-binding="httpspsk" secure="true">
> <ssl name="ssl" key-alias="intended purpose ssl test from bremen online services" password="123456" certificate-key-file="${jboss.server.config.dir}/governikus_ssl.jks" protocol="ALL" keystore-type="JKS" ssl_protocol="RFC4279"/>
> </connector>
> {code}
> This is related to Red Hat Customer Portal support case 00721624 "Additional JSSE Provider on socket bindings and connectors"
--
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, 8 months
[JBoss JIRA] (LOGMGR-68) periodic-rotating-file-handler not rotating
by Alexander Yerenkow (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-68?page=com.atlassian.jira.plugin.... ]
Alexander Yerenkow commented on LOGMGR-68:
------------------------------------------
I run a quick test against PeriodicRotatingFileHandler, specifically I tried to see which values it will give me for different file timestamps:
System.out.println("now = " + Calendar.getInstance().getTime());
for(int i = 0; i < 36; i++)
{
now -= 12*3600*1000;
calcNextRollover(now);
}
this code, plus
System.out.println("calendar = " + calendar.getTime());
at the end of
private void calcNextRollover(final long fromTime) {
All this produced this:
now = Wed Apr 24 22:55:41 EEST 2013
calendar = Thu Apr 25 00:00:00 EEST 2013
calendar = Wed Apr 24 12:00:00 EEST 2013
calendar = Wed Apr 24 00:00:00 EEST 2013
calendar = Tue Apr 23 12:00:00 EEST 2013
calendar = Tue Apr 23 00:00:00 EEST 2013
calendar = Mon Apr 22 12:00:00 EEST 2013
calendar = Mon Apr 22 00:00:00 EEST 2013
calendar = Sun Apr 21 12:00:00 EEST 2013
...
So, it seems for me that somehow 12-hours not really fixed.
Could this be due to Timezone?
> periodic-rotating-file-handler not rotating
> -------------------------------------------
>
> Key: LOGMGR-68
> URL: https://issues.jboss.org/browse/LOGMGR-68
> Project: JBoss Log Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.4.0.Final
> Environment: FreeBSD hostname 10.0-CURRENT FreeBSD 10.0-CURRENT #3 r242434M
> Reporter: Alexander Yerenkow
> Assignee: David Lloyd
>
> During day there could be few restarts of JBoss 7.2.0
> If there was one, next day logs aren't rotated.
> edb.log (contains record from 22 apr till now)
> edb.log.2013-04-12 (contains record from 06 apr till 12)
> edb.log.2013-04-17 (contains record from 13 apr till 17)
> edb.log.2013-04-19 (contains record from 18 apr till 19)
> Can't see clear system;
> Here's my config:
> <periodic-rotating-file-handler name="EDB" autoflush="true">
> <formatter>
> <pattern-formatter pattern="%d %-5p [%c] (%t:%x) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="edb.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="true"/>
> </periodic-rotating-file-handler>
> This all worked as charm in 7.1.1 / 7.1.3.
> Should I run some tests/ gather some info to fix this?
--
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, 8 months
[JBoss JIRA] (LOGMGR-68) periodic-rotating-file-handler not rotating
by Alexander Yerenkow (JIRA)
Alexander Yerenkow created LOGMGR-68:
----------------------------------------
Summary: periodic-rotating-file-handler not rotating
Key: LOGMGR-68
URL: https://issues.jboss.org/browse/LOGMGR-68
Project: JBoss Log Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 1.4.0.Final
Environment: FreeBSD hostname 10.0-CURRENT FreeBSD 10.0-CURRENT #3 r242434M
Reporter: Alexander Yerenkow
Assignee: David Lloyd
During day there could be few restarts of JBoss 7.2.0
If there was one, next day logs aren't rotated.
edb.log (contains record from 22 apr till now)
edb.log.2013-04-12 (contains record from 06 apr till 12)
edb.log.2013-04-17 (contains record from 13 apr till 17)
edb.log.2013-04-19 (contains record from 18 apr till 19)
Can't see clear system;
Here's my config:
<periodic-rotating-file-handler name="EDB" autoflush="true">
<formatter>
<pattern-formatter pattern="%d %-5p [%c] (%t:%x) %s%E%n"/>
</formatter>
<file relative-to="jboss.server.log.dir" path="edb.log"/>
<suffix value=".yyyy-MM-dd"/>
<append value="true"/>
</periodic-rotating-file-handler>
This all worked as charm in 7.1.1 / 7.1.3.
Should I run some tests/ gather some info to fix this?
--
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, 8 months
[JBoss JIRA] (WFLY-1094) Use own JSSE Provider for http Connector
by Hauke Mehrtens (JIRA)
[ https://issues.jboss.org/browse/WFLY-1094?page=com.atlassian.jira.plugin.... ]
Hauke Mehrtens commented on WFLY-1094:
--------------------------------------
Is there any way to speed up resolving this Issue? If the patch should be changed in any way or if it should be supplied in an other way please inform me about this.
> Use own JSSE Provider for http Connector
> ----------------------------------------
>
> Key: WFLY-1094
> URL: https://issues.jboss.org/browse/WFLY-1094
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Hauke Mehrtens
> Labels: https, jsse, ssl
> Attachments: ssl-protocol.patch
>
>
> We are using our own JSSE Provider implementation for TLS to add support for HTTPS with preshared key to one http connector, while the others still use the default JSSE provider.
> In JBoss 5 we added sslProtocol="RFC4279", while RFC4279 is the name of our provider, to one Connector entry in the file server/default/deploy/jbossweb.sar/server.xml. This option is not available in JBoss 7.1 any more and we could not find a way to make one connector use our provider while the others are using the default one.
> To fix this issue for use we used the attached patch. We would like to get this patch into the next version of JBoss, so we do not have to modify the source code by our self any more. This patch was tested with JBoss 7.1.2, but it still applies against the master branch. If we should do any changed to the patch or if you want to get it in an other form please inform us.
> With this patch we are able to specify our JSSE provider like this:
> <connector name="httpspsk" protocol="HTTP/1.1" scheme="https" socket-binding="httpspsk" secure="true">
> <ssl name="ssl" key-alias="intended purpose ssl test from bremen online services" password="123456" certificate-key-file="${jboss.server.config.dir}/governikus_ssl.jks" protocol="ALL" keystore-type="JKS" ssl_protocol="RFC4279"/>
> </connector>
> This is related to Red Hat Customer Portal support case 00721624 "Additional JSSE Provider on socket bindings and connectors"
--
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, 8 months
[JBoss JIRA] (WFLY-976) Multi-JSF doesn't understand new modules structure
by Glenn Kastrinos (JIRA)
[ https://issues.jboss.org/browse/WFLY-976?page=com.atlassian.jira.plugin.s... ]
Glenn Kastrinos commented on WFLY-976:
--------------------------------------
Any 2.x I just need to use the additional tomahawk library for some specific MyFaces components, but any version of MyFaces should work with that (there are many tomahawk versions, I had been trying to implement tomahawk-1.1.9.jar before running into all the JBOSS 7.0 errors and backpedalling). Whatever is easiest. 2.1.11 is just great thank you.
> Multi-JSF doesn't understand new modules structure
> --------------------------------------------------
>
> Key: WFLY-976
> URL: https://issues.jboss.org/browse/WFLY-976
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Reporter: Stan Silvert
> Assignee: Stan Silvert
>
> With the new modules structure, Multi-JSF is looking for JSF implementations in the root of the modules directory instead of in modules/system/layers/base. The reason is that Multi-JSF relies on the module.path property which points to the root by default.
> The workaround is to go ahead and install the new JSF impl wherever you wish and add that directory to JBOSS_MODULEPATH in the startup script.
> See https://community.jboss.org/wiki/DesignOfAS7Multi-JSFFeature#comment-11789
--
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, 8 months
[JBoss JIRA] (WFLY-117) Add and deploy does not fail if runtimeName already exists
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-117?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler updated WFLY-117:
--------------------------------
Comment: was deleted
(was: Done)
> Add and deploy does not fail if runtimeName already exists
> ----------------------------------------------------------
>
> Key: WFLY-117
> URL: https://issues.jboss.org/browse/WFLY-117
> Project: WildFly
> Issue Type: Bug
> Components: OSGi, Server
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Fix For: 8.0.0.Alpha1
>
>
> The ServerDeploymentHelper has this code
> {code}
> public String deploy(String runtimeName, InputStream input) throws ServerDeploymentException {
> ServerDeploymentActionResult actionResult;
> try {
> DeploymentPlanBuilder builder = deploymentManager.newDeploymentPlan();
> builder = builder.add(runtimeName, input).andDeploy();
> DeploymentPlan plan = builder.build();
> DeploymentAction action = builder.getLastAction();
> Future<ServerDeploymentPlanResult> future = deploymentManager.execute(plan);
> ServerDeploymentPlanResult planResult = future.get();
> actionResult = planResult.getDeploymentActionResult(action.getId());
> } catch (Exception ex) {
> throw new ServerDeploymentException(ex);
> }
> if (actionResult.getDeploymentException() != null)
> throw new ServerDeploymentException(actionResult);
> return runtimeName;
> }
> {code}
> which does not fail if the runtimeName already exists
> There is a debug log like this
> {code}
> 11:11:25,103 DEBUG [org.jboss.as.controller.management-operation] (pool-4-thread-1) JBAS014616: Operation ("add") failed - address: ([("deployment" => "v200.jar")]) - failure description: "JBAS014803: Duplicate resource [(\"deployment\" => \"v200.jar\")]"
> {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, 8 months