Difficulty with ImportHandler#importClass()
by Patrick Garner
It looks like there is a class loader issue with
ImportHandler#importClass(). It's unable to load classes in
WEB-INF/classes. After seeking help in JBoss Community, Jaikiran Pai
suggested I contact the webdev list. Here is the link to the discussion:
https://developer.jboss.org/thread/249727
Any thoughts/ insights you may provide would be so helpful.
Regards,
Pat
10 years
WFLY-3512 - disable datasource undeploy application
by Claudio Miranda
Hi, related to WFLY-3512, disable a datasource used by some
application, undeploy the application, tested in 8.1 and 9.0 snapshot.
I saw that org.jboss.as.connector.subsystems.datasources.DataSourceDisable
(connector module) is called, but there is no previous check about
deployments that uses it.
How can datasource subsystem get to know the deployment dependencies
for resources (datasource and resource adapter) ?
Is there a listener mechanism where datasource subsystem can listen to
deploy enablement, and check the resources dependencies ? This way,
datasource subsystem can have a lista of dependency and check it
before disable/remove of datasources.
1. https://issues.jboss.org/browse/WFLY-3512
--
Claudio Miranda
claudio(a)claudius.com.br
http://www.claudius.com.br
10 years
About last week's core release...
by David M. Lloyd
Last Friday I prepared the wildfly-core 1.0.0.Alpha10 release. It's in
a staging repo up on Nexus right now - however, Brontes was down (as was
the entire Brno data center, due to maintenance, I hear) so I was unable
to do a clean test of WildFly with the updated core, thus the release
hasn't happened.
We'll shoot for early this week. If however the testing fails, then
there will likely be no "last week" release, and instead we'll try again
this Friday.
--
- DML
10 years, 1 month
WildFly Elytron Discussions
by Darran Lofthouse
As we are a small team of engineers distributed across multiple
timezones we have decided to move our discssions from IRC to HipChat, to
chat about Elytron use the wildfly-elytron room.
If you do not have access to HipChat guest access is available here
http://www.hipchat.com/gKoTFkUyg
Regards,
Darran Lofthouse.
10 years, 1 month
Behavior of javax.servlet.ServletResponse#isCommitted
by Pedro Igor Silva
Hi,
I'm using latest build from wildfly upstream/master.
Would like to know if there is an issue on how Undertow recognize that a response is already commited or not.
My code is setting a header and sending an error like that
response.setHeader(REQUIRES_AUTHENTICATION_HEADER_NAME, AUTHENTICATION_SCHEME_NAME);
response.sendError(HttpServletResponse.SC_UNAUTHORIZED);
and isCommited is always returning "false" after that. To change this behavior I have to force a flush, so isCommited returns true.
Both WildFly 8.1.0.Final and EAP behave differently and isCommited returns "true" without requiring a manual flush. Is this an issue ?
Regards.
Pedro Igor
10 years, 1 month
Re: [wildfly-dev] smoke testing failure
by Peter Cai
It should be some environmental issue.
I can successfully run the smoke test on Windows 8,
And the JVM is:
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
Regards
On Mon, Oct 13, 2014 at 8:35 PM, Peter Cai <qutpeter(a)gmail.com> wrote:
> OS: Linux dev-01 3.13.0-27-generic #50-Ubuntu SMP Thu May 15 18:06:16 UTC
> 2014 x86_64 x86_64 x86_64 GNU/Linux (Ubuntu 14.04 desktop)
>
> JVM:
> java version "1.7.0_51"
> Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
>
> My guess is environmental issue as well. But can't find anything so far.
>
> Regards,
> Peter
>
>
>
> On Mon, Oct 13, 2014 at 8:29 PM, Tomaž Cerar <tomaz.cerar(a)gmail.com>
> wrote:
>
>> os? jvm? arch?
>>
>> looking at our nightly jobs whole testsuite passes on our CI with JDK7 &
>> 8 on windows and on linux.
>>
>> I am guessing it must be environmental issue.
>>
>> On Mon, Oct 13, 2014 at 11:47 AM, Peter Cai <qutpeter(a)gmail.com> wrote:
>>
>>> Hi,
>>>
>>> It looks like that the current HEAD of Wildfly will failed when running
>>> smoke testing with the following information:
>>>
>>> Results :
>>>
>>> Failed tests:
>>>
>>> ServerInModuleDeploymentTestCase.testDeploymentStreamApi:93->testDeployments:614
>>> expected:<[c767c5d5e516f6e04ec69f5a0f8ccdc0d63e6fa5,
>>> 342ae7aec9bff370e3de8704ed9642a718986e61]> but
>>> was:<[342ae7aec9bff370e3de8704ed9642a718986e61]>
>>>
>>> Any cues?
>>>
>>> Regards,
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>
10 years, 1 month
