Change CLI to Default to Remoting
by Darran Lofthouse
Hello all,
I am currently working on the following issue: -
https://issues.jboss.org/browse/WFLY-1664
Recent changes to the CLI mean that it is assuming unless told otherwise
that a HTTP Upgrade is going to be used when connecting to the server,
this means that command already used in scripts to connect to servers
are going to fail unless the scheme is included in the URI.
I chatted with David to see if there were any options to auto detect
this and fall back to pure Remoting if the remote side of the connection
is pure Remoting - however of the two options available they were both
fairly hacky or unreliable.
So the alternative is to drop the CLI back to assuming a pure Remoting
connection unless told otherwise.
- Calling connect or starting with -c will still use http-remoting
against the local server as that is defined in the jboss-cli.xml
- Calling connect or --controller with a host and port will assume
connecting directly to remoting.
- Users wanting HTTP upgrade to other servers will need to specify
http-remoting or https-remoting as the scheme when specifying the remote
address.
One other idea that I have had for the CLI if end users do want the
parameter to the connect command to be as short as possible is to add
multiple host aliases to the jboss-cli.xml - that way the protocol host
and port can be specified in the config and the alias passed to the
connect command. Additionally this would allow us to place different
SSL configuration against each host but.
Regards,
Darran Lofthouse.
11 years, 1 month
Implementing enforce-victims-rule in wildfly builds
by David Jorm
Hi All
First I should introduce myself for those who don't know me, as I have not participated in wildfly dev discussions before. I am a security response engineer working for Red Hat, handling security patches for the commercial JBoss products. Recently some colleagues and I have been working on a tool called 'victims'. The victims tool aims to provide a canonical database of known-vulnerable JAR files, along with tools that allow developers and system administrator to determine whether their projects and systems contain any known-vulnerable JARs. The project's about page contains a more detailed explanation:
http://www.victi.ms/about.html
enforce-victims-rule is a maven plugin that walks the dependency tree at build time, and uses the victims database to check whether a project is including any known-vulnerable JARs as dependencies. The plugin is available on maven central:
http://search.maven.org/#artifactdetails|com.redhat.victims|enforce-victi...
Please see the README.md and sample app here for configuration details:
https://github.com/victims/victims-enforcer
I think there would be great value in incorporating this plugin into the wildfly POM(s). It can catch security flaws at build time, eliminating the need for much more work to ship patches for flaws later down the line. It is also designed such that it should not trigger any false positives. There will be false negatives where there are gaps in the database.
What do people think? Is this something you'd consider implementing?
Thanks
--
David Jorm / Red Hat Security Response Team
11 years, 4 months
XSD Validation issues
by Max Rydahl Andersen
Hey,
We got a funky issue in JBIDE-14629 which turns out was reported earlier in WFLY-943
A valid (according to AS) jboss-deployment-structure.xml can't be validated by the schemas in doc/ folder.
Mainly because of the use of "unqualified" instead of "qualified" for elementFormDefault's.
Is this intentional or something that can be fixed so documents actually can be validated and things that
validate can actually be deployed :)
/max
11 years, 4 months
Milestone change, next release is Alpha4
by Jason Greene
Hello Everyone,
Since we still have a few EE7 APIs pending and reacting to feedback from review[1], and this was a key criteria for a Beta release, I have marked the next milestone as Alpha4 instead of Beta1. The original Beta2 release date is now marked Beta1. At this point in time we do not expect any change to the final delivery date.
[1] https://issues.jboss.org/browse/WFLY-469
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
11 years, 4 months
Fwd: jboss-el-api_2.2_spec APIs and Wildfly
by Shelly McGowan
On a related note to this discussion about EL 3.0 APIs:
http://lists.jboss.org/pipermail/jboss-as7-dev/2013-July/008179.html
See below a previous exchange on an attempt to remove EL 2.2 API dependency from WildFly.
Shelly McGowan
JBoss, by Red Hat
> ----- Forwarded Message -----
> From: "Stuart Douglas" <sdouglas(a)redhat.com>
> To: "Shelly McGowan" <smcgowan(a)redhat.com>
> Cc: "Remy Maucherat" <rmaucher(a)redhat.com>
> Sent: Thursday, July 18, 2013 1:00:15 AM
> Subject: Re: jboss-el-api_2.2_spec APIs
>
> I created this class to address a fairly major EL performance issue (that factory finder is invoked on every EL invocation, and it is both slow and acquires locks, which cause lots of contention).
>
> We may need to do a similar performance fix in the org.glassfish EL module, but I am not really sure. Assuming the problem still exists and we remove this fix our JSF performance will drop considerably.
>
> Stuart
>
> ----- Original Message -----
>> From: "Shelly McGowan" <smcgowan(a)redhat.com>
>> To: "Remy Maucherat" <rmaucher(a)redhat.com>
>> Cc: "Stuart Douglas" <sdouglas(a)redhat.com>
>> Sent: Thursday, 18 July, 2013 9:45:01 AM
>> Subject: jboss-el-api_2.2_spec APIs
>>
>>
>>
>> Remy,
>>
>> Currently in WildFly we are using the org.glassfish:javax.el dependency for
>> EL 3.0 APIs and implementation.
>> I'm assuming the plan is to keep this in for at least WildFly 8.0.0.Final
>> releases (and EE 7 certification) due to Beta1 only a few weeks away.
>>
>> I was working on a pull request to remove the EL 2.2 APIs from WildFly and
>> found out I was unable to do that due to a dependency
>> from both the web module and the undertow module on:
>> org.jboss.el.cache.FactoryFinderCache specifically in:
>> undertow/src/main/java/org/wildfly/extension/undertow/deployment/ELExpressionFactoryProcessor.java
>> web/src/main/java/org/jboss/as/web/deployment/ELExpressionFactoryProcessor.java
>>
>> This class is included in the jboss-el-api Specs project API .jar but
>> obviously not part of org.glassfish:javax.el.
>>
>> How do you want to handle this moving forward? For tests purposes, I created
>> an org.wildfly.el module to include only this class as you can see on this
>> branch:
>> https://github.com/smcgowan/wildfly/commit/3c511ea2e74a22215f02d69ff0d07d...
>>
>> [NOTE: there are a couple of unrelated changes in that branch]
>>
>>
>> This work was prompted by some signature test failures I was seeing in TCK.
>> The EL 2.2 APIs being in the distribution were unrelated.
>>
>>
>> Shelly McGowan
>> JBoss, by Red Hat
11 years, 4 months
Handling @TransactionAttribute exceptions
by Gytis Trikleris
Hello,
I need to handle exception when either
TransactionAttributeType.MANDATORY or TransactionAttributeType.NEVER
requirement is not met. It is not a problem for MANDATORY, because
EJBTransactionRequiredException is thrown. However, general EJBException
exception is thrown if unexpected transaction was on the thread.
I wanted to ask what is the best way to detect that EJBException was
caused because of unnecessary transaction? Error code given by the
exception is JBAS014163, but I am not sure if it is safe to rely on
message codes...
Thanks,
Gytis
11 years, 5 months
eclipselink
by Kabir Khan
Hi Scott,
Can you add the eclipselink artifacts from testsuite/compat/pom.xml to http://repository.jboss.org/nexus/content/groups/developer/? It causes problems when I use 'mvn clean install', and my settings.xml is set up to mirror to http://repository.jboss.org/nexus/content/groups/developer. I know it has caused problems for some other people as well.
I've worked around it by disabling the mirror, but I added it on Paul Gier's instruction once upon a time, so I would like to keep it. I am guessing the reason for that mirror setting is to make sure that JBoss projects are totally buildable using the JBoss repository, so that we don't need to rely on third-party ones.
Cheers,
Kabir
11 years, 5 months
Feature showcasing
by Jason Greene
One thing I think we should do for one of the Betas is to showcase some of the new features in WildFly 8. I am hoping for a volunteers to write up a blog or article by then which does a walkthrough of the feature.
So like as an example, the EE concurrency APIs are new to Java EE7, and it would be nice to show how they could be used with the Beta to build interest and momentum for the eventual final release.
Let me know if you are interested!
Thanks
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
11 years, 5 months
WFLY-508, JBeret initial review and integration issues
by David M. Lloyd
On initial review of JBeret we have noticed a number of issues that need
to be addressed. The culmination amounts to a series of questions and
observations here:
#1) Why did we not choose to just use the RI? In other words, what
benefit do we get from JBeret that is not also in the RI? In other,
other words, why should we *use* this code instead of the RI at this
point in time?
#2) Why does JBeret duplicate facilities already present in the WildFly
code base and deployer chain - e.g. annotation indexing, reflection
indexing, thread management, parsing facilities, etc.?
#3) Specific to algorithmic complexity - it appears that jobs are keyed
by ID, yet accessed using a sequential search [1] - this does not scale
well to large numbers of jobs. Is there no better approach?
#4) JAXB seems to be being used to parse XML, which is a departure from
all of our other services which expect parsing to be done during
deployment processing in a more efficient manner. Is there any better
way we can integrate this, preferably not using JAXB?
#5) There are a number of resources present that seem inappropriate for
the production JAR [2] [3]. Is this intentional?
#6) This code base makes extensive use of static state, including static
fields that seem not to be adequately protected for thread-safety, and
at least one static thread pool [4]. This needs to be fixed, as these
kinds of things make embedding difficult or impossible.
[1]
https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/or...
[2]
https://github.com/jberet/jsr352/tree/master/jberet-core/src/main/resourc...
[3]
https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/resourc...
[4]
https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/or...
--
- DML
11 years, 5 months
