The Big Log ID Change: https://github.com/wildfly/wildfly/pull/5906
by David M. Lloyd
It's right there in the topic. James and I have carried out the change
discussed in [1] and elsewhere, and have split all the old "JBAS" codes
into specific "WFLYxxx" codes. The pull request is divided into one
commit per Maven module for easier review.
I request that every subsystem or component maintainer please review the
part of the commit that pertains to their piece, and please post
comments on the PR itself [2].
In addition, I want to discuss a few cases where modules are using
message bundles and loggers from neighboring modules. This is going to
become a problem when we do the distribution split-up.
Finally, one small matter I want to sort out is that we have several
modules which use a project-specific code for IllegalArugmentExceptions
that pertain specifically to null parameters, whereas some do not use a
code for this case and just throw the exception.
My feeling is we should either (a) don't use a code for this kind of
thing, or (b) come up with a "common" module or code space+project code
which every project can reuse, so we just have one code that universally
means "the parameter can't be null".
[1] http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000428.html
[2] https://github.com/wildfly/wildfly/pull/5906
--
- DML
11 years, 8 months
WF 8.0 HTTP Upgrade help needed
by PB
Hi,
I'm testing the HTTP Upgrade feature of WF 8.0 and I'm facing some banal
problem. Basically my ReadListener is NEVER called.
Here's the code:
@WebServlet(urlPatterns = "/upgrade")
public class UpgradeServlet extends HttpServlet {
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
if ("upgrade".equalsIgnoreCase(req.getHeader("Connection"))) {
req.upgrade(EchoHandler.class);
}
}
}
public class EchoHandler implements HttpUpgradeHandler {
@Override
public void init(WebConnection wc) {
try {
ServletInputStream in = wc.getInputStream();
ServletOutputStream out = wc.getOutputStream();
BlockingQueue<String> queue = new LinkedBlockingQueue<String>();
in.setReadListener(new EchoReadListener(queue, in));
out.setWriteListener(new EchoWriteListener(queue, out));
} catch (IOException e) {
throw new IllegalStateException(e);
}
}
public class EchoReadListener implements ReadListener {
@Override
public void onDataAvailable() throws IOException {
while (in.isReady()) {
int length = in.read(buffer);
String input = new String(buffer, 0, length);
if (false == queue.offer(input)) {
System.err.println("'" + input + "' input was ignored");
}
}
}
I'm connecting to WF using telnet and sending the upgrade request:
GET /example-webapp/upgrade HTTP/1.1
Host: localhost
Connection: upgrade
Upgrade: echo
and I'm getting correct response:
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
X-Powered-By: Undertow 1
Server: Wildfly 8
Content-Length: 0
which means that from now on the protocol between my telnet client and WF
is pure TCP.
So, I start typing some text, hit Enter and.... nothing happens.
onDataAvailable() is NEVER called. More so, this makes WF totally
irresponsive - my whole webapp is dead.
I believe, I'm doing something wrong - any ideas what exactly? There is
also a slight chance that Upgrade feature in WF is f****d :)
Anyway, WF should not block even in case my upgraded protocol is not
working correctly?
Many thanks,
Przemyslaw
11 years, 10 months
Undertow 1.0.2 in WildFly 8.0.1?
by Oliver Chong
We were seeing issues with Undertow 1.0.0 bundled in WildFly 8.0.0 properly
handling a client certificate proxied from apache httpd over AJP
(mod_proxy_ajp). The application would seemingly randomly not be able to
retrieve the cert from the request and so respond with a 403.
I've since tried Undertow 1.0.2 and everything seems to be working
correctly now. I noticed that in the Undertow change log there were
changes to AJP parsing and handling of certificates when Apache doesn't
forward the session ID.
We prefer to not have to swap components from those provided in an official
WildFly release. Will WildFly 8.0.1 include Undertow 1.0.2?
Thanks,
Oliver
11 years, 10 months
ConstraintDeclarationException on deployment
by Mike Hostetler
I'm probably one of the many that is moving away from Glassfish to WildFly.
I have done some trivial changes but now Weld is giving validation failures
like the following on some of our EJB3 beans:
javax.validation.ConstraintDeclarationException: HV000151: A method
overriding another method must not alter the parameter constraint
configuration
The worse thing is that only see one at a time: so I fix one, do the
build-redeploy dance, and then see the next one. Most of the problems is
that in the overriding class we use javax.validation.constraints.NotNull
annotation on the parameter, which is what Weld doesn't seem to like.
Obviously these worked in Glassfish.
My first thought is: how can I shut off Weld validation? If that is not
possible (which I'm willing to accept), then how can I see these validation
errors all at once instead of one at a time during deployment?
Thanks
--
Mike Hostetler
http://mike.hostetlerhome.com/
11 years, 10 months
Shut off connection pooling?
by Mike Hostetler
My next migration question --
how do I shut off jdbc connection pooling? We have our own Datasource jar
that takes of that for us, including handling our own unique (read:
"crazy") requirements. That datasource jar is already successfully deployed
in my WildFly container.
Thanks,
--
Mike Hostetler
http://mike.hostetlerhome.com/
11 years, 10 months
Support for PKCS12 keystores in Security Realms
by Marek Żupnik
Hi,
I'm Marek Zupnik. It's my first message for this list but for some time
I've been keeping my eyes on what's happening in wildfly development.
I'm writing regarding to the issue about lack of support for PKCS12
keystores in security realms (https://issues.jboss.org/browse/WFLY-2229). I
wanted to migrate my system to Wildfly but in my case it is a blocking
issue. I have to use keystore in PKCS12 format in which I'm storing, among
others, https private key.
I forked Wildfly on github and made a simple fix for this issue which
consists in additional parameter "keystore-type" for keystore
configuration. Based on this parameter I'm able to create appropriate
keystore type.
Config sample:
<keystore path="keystore.p12" relative-to="jboss.server.config.dir"
keystore-password="xxx" keystore-type="PKCS12" alias="https"/>
The changes are in my fork on github (keystore_type branch):
https://github.com/mzupnik/wildfly/tree/keystore_type
Before I will try to do push request, could you answer me if it is
acceptable solution according to your architecture concept? If not, could
you give me some tips how to resolve it in other way? I care about this fix
before 9. release.
Kind Regards,
Marek Zupnik
11 years, 10 months
