[JBoss JIRA] (WFLY-3197) ExternalContextFactory cuts context from deployment context/requires dependency on module
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-3197?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski commented on WFLY-3197:
------------------------------------------
Ok. I finally got a moment to try it out.
Well, workaround wont work in 100% cases - I'm actually facing one.
Condition that must be met, is that there are no class versions classhes - for instance SecurityContextFactory and JBossSecurityContext. If there are, Proxy ( created from JNDI Ref ) must run in proper CL, in this case, factory module CL which will isolate it from AS7 env - keep all the factory module classes scoped and isolated.
Possibly application could create fake module (jboss-deployment-structure->module ) which would contain required classes from deployment and have dependency on factory module to bring all those classes required for lookup. Just before call/lookup application would have to switch TCCL to this fake module. However this is wrong:
- it moves CL magic into application - this is the original reason I've started to dig ExternalContextFactory.module
- ( I think ) it will make impossible to translate between classes that have two different versions( one in AS7 space second in factory module ) - for instance security packages suffer from this - iirc static methods - org.jboss.security.SecurityContextFactory.createSecurityContext and SecurityContextAssociation.*
> ExternalContextFactory cuts context from deployment context/requires dependency on module
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-3197
> URL: https://issues.jboss.org/browse/WFLY-3197
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Naming
> Affects Versions: 8.0.0.Final, 8.1.0.CR1
> Reporter: Bartosz Baranowski
> Assignee: Bartosz Baranowski
> Fix For: 8.1.0.Final
>
>
> WFLY-2777 changed CCL for context creation(if module is set in external context factory). This essentially cuts context from deployment classes during creation time. This can cause problems when external-context-factory.module classes (ObjectFactories, etc) require deployment classes to be visible from classloader which created context( external-context.module ) and are not found.
> Steps to reproduce:
> 1. define isolated module IM ( with classloader IM_CL )
> 2. create external-context-factory with module set to IM
> 3. create some deployment with interface, for which proxies should be looked up via external-context ( with classloader D_CL ) - deployment has no dependency on IM, since it may contain legacy classes or unwanted dependencies
> 4. lookup and invoke proxy
> Now what will happen is during deployment external-context will be spawned just fine. However, the runtime outcome wont be pleasing.
> Case 1: application and custom context dont do CCL magic
> - invocation happen in deployment CCL, hence IM_CL classes are not visible and no classes required for deserialization can be loaded, this will fail ( return javax.naming.Reference instance, since ObjectFactory from IM_CL cant be found )
> Case 2: application or custom context switch CCL to IM_CL for lookup
> - CCL is set to IM_CL, ObjectFactory can be found, but D_CL classes cant, hence some naming error probably
> Neither of above will work, unless IM_CL and D_CL have some sort of dependency on each other, which just makes module CL configured in external-context-factory irrelevant, since D_CL will require dependency on IM_CL.
> Workaround:
> yes, store IM_CL in context wrapper and upon first invocation obtain CCL( hopefuly D_CL), create agregating CL and set it as CCL for each context invocation.
> Possible fix:
> 1. pass D_CL and IM_CL as part of env to factory, to allow context/context-wrapper to do some magic
> 2. alter ExternalContextFactory and create agregating/delegating CL, which will just iterate over IM_CL and D_CL if present to load proper classes
--
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, 2 months
[JBoss JIRA] (DROOLS-471) Remove repository jboss-deprecated
by Geoffrey De Smet (JIRA)
Geoffrey De Smet created DROOLS-471:
---------------------------------------
Summary: Remove repository jboss-deprecated
Key: DROOLS-471
URL: https://issues.jboss.org/browse/DROOLS-471
Project: Drools
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 6.1.0.Beta2
Reporter: Geoffrey De Smet
Assignee: Michael Biarnes Kiefer
1) In kie-parent-metadata's pom.xml, remove the repository jboss-deprecated:
{code}
<repository>
<id>jboss-deprecated</id>
<name>JBoss Deprecated</name>
<url>https://repository.jboss.org/nexus/content/repositories/deprecated/</url>
<releases>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
{code}
https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom....
2) remove your local repository
3) Do a mvn-all -Dfull build
If it works, commit the change.
If it doesn't, make a list of dependencies that are still coming from the jboss-deprecated repository and make for each dependency a JIRA (or Bugzilla) issue calling to remove it. Tell the module owners who use those deprecated dependencies about the JIRA/BZ and ask them to remove the deprecated dependency.
--
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, 2 months
[JBoss JIRA] (DROOLS-471) Remove repository jboss-deprecated
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-471?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet updated DROOLS-471:
------------------------------------
Description:
1) In kie-parent-metadata's pom.xml, remove the repository jboss-deprecated:
{code}
<repository>
<id>jboss-deprecated</id>
<name>JBoss Deprecated</name>
<url>https://repository.jboss.org/nexus/content/repositories/deprecated/</url>
<releases>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
{code}
https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom....
2) remove your local repository
3) Do a mvn-all.sh -Dfull clean install
If it works, commit the change.
If it doesn't, make a list of dependencies that are still coming from the jboss-deprecated repository and make for each dependency a JIRA (or Bugzilla) issue calling to remove it. Tell the module owners who use those deprecated dependencies about the JIRA/BZ and ask them to remove the deprecated dependency.
was:
1) In kie-parent-metadata's pom.xml, remove the repository jboss-deprecated:
{code}
<repository>
<id>jboss-deprecated</id>
<name>JBoss Deprecated</name>
<url>https://repository.jboss.org/nexus/content/repositories/deprecated/</url>
<releases>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
{code}
https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom....
2) remove your local repository
3) Do a mvn-all -Dfull build
If it works, commit the change.
If it doesn't, make a list of dependencies that are still coming from the jboss-deprecated repository and make for each dependency a JIRA (or Bugzilla) issue calling to remove it. Tell the module owners who use those deprecated dependencies about the JIRA/BZ and ask them to remove the deprecated dependency.
> Remove repository jboss-deprecated
> ----------------------------------
>
> Key: DROOLS-471
> URL: https://issues.jboss.org/browse/DROOLS-471
> Project: Drools
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.Beta2
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
>
> 1) In kie-parent-metadata's pom.xml, remove the repository jboss-deprecated:
> {code}
> <repository>
> <id>jboss-deprecated</id>
> <name>JBoss Deprecated</name>
> <url>https://repository.jboss.org/nexus/content/repositories/deprecated/</url>
> <releases>
> <enabled>true</enabled>
> <updatePolicy>never</updatePolicy>
> </releases>
> <snapshots>
> <enabled>false</enabled>
> </snapshots>
> </repository>
> {code}
> https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom....
> 2) remove your local repository
> 3) Do a mvn-all.sh -Dfull clean install
> If it works, commit the change.
> If it doesn't, make a list of dependencies that are still coming from the jboss-deprecated repository and make for each dependency a JIRA (or Bugzilla) issue calling to remove it. Tell the module owners who use those deprecated dependencies about the JIRA/BZ and ask them to remove the deprecated dependency.
--
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, 2 months
[JBoss JIRA] (WFLY-3252) First HTTPS / SSL request after startup of Wildfly 8.0.0.Final is blocked for many seconds
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3252?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-3252:
-----------------------------------
I send PR to update bouncycastle version to latest https://github.com/wildfly/wildfly/pull/6196
Which should address the ssl engine creation problem, but that is not proper fix.
> First HTTPS / SSL request after startup of Wildfly 8.0.0.Final is blocked for many seconds
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-3252
> URL: https://issues.jboss.org/browse/WFLY-3252
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.Final
> Environment: Win7, Java 1.7.0_51 and 1.8.0
> Reporter: bene.net
> Assignee: Tomaz Cerar
> Priority: Critical
> Labels: Blocked, HTTPS, JAX-RS, Performance, SSL, Start-Up, bouncycastle
> Attachments: server_keystore.jks, standalone-full.xml
>
>
> The first HTTPS / SSL request after startup of Wildfly 8.0.0.Final is blocked for many seconds.
> Please note that subsequent requests perform normally. HTTP requests also perform fine.
> We use curl to call a JAX-RS service (just in case this matters).
> My first thought was, that we had hit the following bug:
> https://issues.jboss.org/browse/XNIO-226?jql=
> However, I can also reproduce the problem with xnio-3.2.2.Final (which contains a fix for bug XNIO-226).
> So I inserted some logging statements in
> {code:title=AbstractAcceptingSslChannel.java}
> System.out.println("calling createSSLEngine...");
> long t1 = System.currentTimeMillis();
> final SSLEngine engine = sslContext.createSSLEngine(JsseSslUtils.getHostNameNoResolve(peerAddress), peerAddress.getPort());
> long t2 = System.currentTimeMillis();
> long duration = t2 - t1;
> System.out.println("createSSLEngine took "+duration+" ms. ");
> {code}
> and in
> {code:title=JsseSslConduitEngine.java}
> case NEED_TASK: {
> Runnable task;
> synchronized (engine) {
> // run the tasks needed for handshaking
> while ((task = engine.getDelegatedTask()) != null) {
> try {
> System.out.println("calling task.run() in handleHandshake...");
> long t1 = System.currentTimeMillis();
> task.run();
> long t2 = System.currentTimeMillis();
> long duration = t2 - t1;
> System.out.println("task.run() in handleHandshake took "+duration+" ms. ");
> } catch (Exception e) {
> throw new IOException(e);
> }
> }
> }
> // caller should try to wrap/unwrap again
> return true;
> }
> {code}
> I found out, that sslContext.createSSLEngine in AbstractAcceptingSslChannel.java is quite slow (468ms) but it is not the cause
> for the blocking request. Instead org.xnio.ssl.JsseSslConduitEngine.handleHandshake(JsseSslConduitEngine.java:512) needs
> 95 seconds to return!!!
> Here is the relevant part from my log file:
> {noformat}
> INFO ; 2014-04-11 18:29:52,115; [Controller Boot Thread ]; JBAS015874: WildFly 8.0.0.Final "WildFly" started in 6477ms - Started 334 of 386 services (107 services are lazy, passive or on-demand); [org.jboss.as.server.BootstrapListener.done(BootstrapListener.java:93)]; ;
> INFO ; 2014-04-11 18:30:05,566; [default I/O-3 ]; calling createSSLEngine...
> ; [org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)]; ;
> INFO ; 2014-04-11 18:30:06,035; [default I/O-3 ]; createSSLEngine took 468 ms.
> ; [org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)]; ;
> INFO ; 2014-04-11 18:30:06,066; [default I/O-3 ]; calling task.run() in handleHandshake...
> ; [org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)]; ;
> INFO ; 2014-04-11 18:31:41,128; [default I/O-3 ]; task.run() in handleHandshake took 95061 ms.
> ; [org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)]; ;
> INFO ; 2014-04-11 18:31:41,133; [default I/O-3 ]; calling task.run() in handleHandshake...
> ; [org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)]; ;
> INFO ; 2014-04-11 18:31:41,145; [default I/O-3 ]; task.run() in handleHandshake took 10 ms.
> ; [org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)]; ;
> INFO ; 2014-04-11 18:31:41,573; [default task-1 ]; SecurityFilter received request. ; [de.head.vetsone.rest_ifc.SecurityFilter.filter(SecurityFilter.java:62)]; ;
> {noformat}
> Using JConsole I could extract the full stacktrace:
> Name: default I/O-2
> State: RUNNABLE
> Total blocked: 0 Total waited: 2
> Stack trace:
> {noformat}
> java.math.BigInteger.oddModPow(BigInteger.java:2700)
> java.math.BigInteger.modPow(BigInteger.java:2443)
> java.math.BigInteger.passesMillerRabin(BigInteger.java:1019)
> java.math.BigInteger.primeToCertainty(BigInteger.java:875)
> java.math.BitSieve.retrieve(BitSieve.java:203)
> java.math.BigInteger.largePrime(BigInteger.java:744)
> java.math.BigInteger.<init>(BigInteger.java:650)
> org.bouncycastle.crypto.generators.DHParametersHelper.generateSafePrimes(Unknown Source)
> org.bouncycastle.crypto.generators.DHParametersGenerator.generateParameters(Unknown Source)
> org.bouncycastle.jce.provider.JDKKeyPairGenerator$DH.generateKeyPair(Unknown Source)
> sun.security.ssl.DHCrypt.generateDHPublicKeySpec(DHCrypt.java:225)
> sun.security.ssl.DHCrypt.<init>(DHCrypt.java:101)
> sun.security.ssl.ServerHandshaker.setupEphemeralDHKeys(ServerHandshaker.java:1350)
> sun.security.ssl.ServerHandshaker.trySetCipherSuite(ServerHandshaker.java:1194)
> sun.security.ssl.ServerHandshaker.chooseCipherSuite(ServerHandshaker.java:1002)
> sun.security.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:724)
> sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:213)
> sun.security.ssl.Handshaker.processLoop(Handshaker.java:925)
> sun.security.ssl.Handshaker$1.run(Handshaker.java:865)
> sun.security.ssl.Handshaker$1.run(Handshaker.java:862)
> java.security.AccessController.doPrivileged(Native Method)
> sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1302)
> - locked sun.security.ssl.SSLEngineImpl@3f3d2d55
> org.xnio.ssl.JsseSslConduitEngine.handleHandshake(JsseSslConduitEngine.java:512)
> - locked sun.security.ssl.SSLEngineImpl@3f3d2d55
> org.xnio.ssl.JsseSslConduitEngine.unwrap(JsseSslConduitEngine.java:595)
> org.xnio.ssl.JsseSslConduitEngine.unwrap(JsseSslConduitEngine.java:543)
> org.xnio.ssl.JsseSslStreamSourceConduit.read(JsseSslStreamSourceConduit.java:89)
> org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127)
> io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:111)
> io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:69)
> io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:38)
> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092)
> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> org.xnio.nio.NioTcpServerHandle.handleReady(NioTcpServerHandle.java:53)
> org.xnio.nio.WorkerThread.run(WorkerThread.java:531)
> {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
12 years, 2 months