Proposal for improving handling complex types in CLI
by Tomaž Cerar
Hi guys,
there ware some discussions on how we should improve handling complex types
of attribute bit better in CLI.
For most part that was about Map & List types.
After some discussions with few of you I came up with plan / ideas what all
options are there for us to improve on.
you can see current state of proposed enhancements at
https://gist.github.com/ctomc/91055a6f4e7502dcd130
In short, I propose to add set of map-* and list-* global operations and
improve :read-attribute & :write-attribute
with EL like syntax for reading / updating map, list and generic complex
attributes.
Let me know what you think about it, especially Console & CLI folks.
--
tomaz
10 years, 6 months
Customizing a provisioned server
by Stuart Douglas
Hi everyone,
Work on the provisioning tool is now well underway, so I would like to
revisit something I mentioned in my original email, which is allowing
the provisioning tool to customize a provisioned server.
I think there are a few options here, some more palatable than others.
In no particular order:
1) Customize the XML directly
Using this approach we would just directly customize the XML
configuration files. This would basically require the use of XSLT
(yuck), or require us to basically invent our own version of XSLT (even
more yuck). Even though this approach will work, and will be fairly easy
to implement, I think it would really suck from an end-user point of
view, and I think we should discount it.
2) Allow the user to provide CLI commands to customise the server
This is by far my favorite approach. The provisioning file would just
contain a list of CLI commands, and would execute them in order. I think
this is by far the most intuitive, and the CLI is well documented.
3) Allow the user to provide DMR operations to customize the server
Similar to 2, but allow the user to provide DMR or JSON operations to
customize the server. I think this is not nearly as nice as 2, as users
are much more likely to be familiar with the CLI rather than DMR.
I think 2 is by far the best approach, however it does open up the
question of how and when to execute the operations. I think the easiest
way to do this would be to just start the server in admin only mode on a
custom port (so it will not interfere with any existing running Wildfly
instances), and just execute the CLI commands in admin only mode.
Does this all sound reasonable?
Stuart
10 years, 8 months
Embedding a WF instance in the CLI
by Brian Stansberry
Moving a thread to the dev list.
This is about some prototyping I've been doing on weekends 'cause I'm
bored with my regular tasks. I've been playing with direct local
administration of a WF installation via the CLI without requiring a
socket-based connection. The general use case is initial setup type
activities where the user doesn't want to have to launch a WF server or
HC process and potentially have it be visible on the network.
https://issues.jboss.org/browse/WFLY-3288 is one use case; another is a
desire some folks have expressed in being able to do configuration
without first having to edit any xml to avoid port conflicts on 9990 or
9999.
This isn't a major initiative or big priority or anything at this point.
Just something I find interesting and perhaps you will too.
On 5/14/14, 8:54 AM, Alexey Loubyansky wrote:
> Neat :) Yes, figuring out the module path is biting everywhere.
> For file system path command line arguments there is a specialized
> FileSystemPathArgument.
>
Thanks; I'll switch to that.
>
> On 05/13/2014 10:54 PM, Brian Stansberry wrote:
>> Copying Heiko Braun as he expressed some interest in the topic.
>>
>> BTW, I played with this a bit more last weekend and was able to start an
>> embedded server inside the CLI easily enough. See [1] for very raw
>> prototype stuff. You can run bin/jboss-cli.sh (no -c) and then
>>
>> [disconnected/] embed-server
>>
>> There are a couple issues I see, besides the HC stuff I mentioned in my
>> last message.
>>
>> 1) If the CLI is started in a non-modular environment via java -jar
>> bin/client/jboss-cli-client.jar, we'd have to shade jboss-modules into
>> the jar. And then the embed-server command would need params specifying
>> the location of JBOSS_HOME, possibly module path etc. But it could embed
>> a server installed in any accessible filesystem location.
>>
>> But what I did at [1] is based on bin/jboss-cli.sh, where the CLI is
>> running from a WF dist in a modular environment and the embedded server
>> modules are coming from the CLI's own module path. It would be more
>> effort to support embedding a server based on some other module path.
>> Maybe it's no big deal; maybe it's really hard. :)
>>
>> 2) The console logging from the embedded server goes to stdout mixed in
>> with the CLI output. Maybe that's good, maybe it's bad.
>>
>> [1] https://github.com/bstansberry/wildfly/tree/cli-embed
>>
>> On 4/28/14, 10:04 AM, Brian Stansberry wrote:
>>> I was poking around at this for an hour or so over the weekend.
>>>
>>> The standalone case seems pretty straightforward. Seems the existing
>>> embedded server API could work readily enough. The
>>> org.jboss.as.embedded.StandaloneServer interface already provides a
>>> ModelControllerClient.
>>>
>>> The domain case is much harder, as the CLI wants a HostController, not a
>>> ProcessController. I'd really like this to use an in-VM client, not a
>>> remote one, so I don't like having the CLI embed a PC and then the HC is
>>> an external process. My thoughts of the morning are to allow inverting
>>> the HC/PC relationship for this kind of usage. That is, remove
>>> controlling the HC lifecycle from the charge of the PC component. CLI
>>> launches HC, and then the HC creates an in-process PC-ish component (not
>>> a separate process) to manage the server lifecycles. There could be all
>>> sorts of problems with that; it's just the thought for the morning.
>>>
>>> On 4/25/14, 11:49 AM, Alexey Loubyansky wrote:
>>>> Embedding the AS is the best starting point to achieve that! And more
>>>> fun, I agree :)
>>>>
>>>> On 04/25/2014 06:28 PM, Darran Lofthouse wrote:
>>>>> And to think my reason for opening the Jira was just for a common
>>>>> way to
>>>>> mask password inputs where java.io.Console is not available ;-)
>>>>>
>>>>> On 25/04/14 17:09, Brian Stansberry wrote:
>>>>>> On 4/25/14, 10:40 AM, Alexey Loubyansky wrote:
>>>>>>> Wow! Indeed :)
>>>>>>>
>>>>>>> There could be an embedded scope - true, i.e. commands available
>>>>>>> only
>>>>>>> this mode, like add-user, module mgmt related stuff, etc.
>>>>>>
>>>>>> Those commands wouldn't need to be only in that mode though. The
>>>>>> implementation of all of them would be based in the server; the
>>>>>> "client"
>>>>>> aspect of the CLI would just use the management interface. The
>>>>>> difference between an embedded mode and what we have now would
>>>>>> just be
>>>>>> in how the "client" side gets its ModelControllerClient -- what we
>>>>>> have
>>>>>> now vs starting an embedded server and getting some sort of in-vm
>>>>>> client.
>>>>>>
>>>>>>> But it would still mean the server/controller would have to actually
>>>>>>> provide implementations of that functionality and expose it to the
>>>>>>> management tools like the CLI in the embedded mode.
>>>>>>
>>>>>> Yep.
>>>>>>
>>>>>>> I like this idea as a concept - direct local management. W/o any
>>>>>>> remote
>>>>>>> connect/re-connect/disconnect burden.
>>>>>>>
>>>>>>> Extending the CLI with custom modules is on the list too. It's
>>>>>>> probably
>>>>>>> easier to implement at this point.
>>>>>>>
>>>>>>
>>>>>> Likely so, but maybe less fun. ;) I copied you on a PRD-related
>>>>>> thread
>>>>>> where I briefly get into this general area too.
>>>>>>
>>>>>>> Alexey
>>>>>>>
>>>>>>> On 04/25/2014 05:00 PM, Brian Stansberry wrote:
>>>>>>>> Hi Alexey,
>>>>>>>>
>>>>>>>> Wanted to point the discussion on this JIRA out to you as it gets
>>>>>>>> into
>>>>>>>> some fairly fundamental brainstorming that you may find
>>>>>>>> interesting.
>>>>>>>>
>>>>>>>>
>>>>>>>> -------- Original Message --------
>>>>>>>> Subject: [JBoss JIRA] (WFLY-3288) Update add-user to use AESH or
>>>>>>>> move it
>>>>>>>> into the CLI
>>>>>>>> Date: Fri, 25 Apr 2014 09:44:35 -0400 (EDT)
>>>>>>>> From: Darran Lofthouse (JIRA) <issues(a)jboss.org>
>>>>>>>> To: brian.stansberry(a)redhat.com
>>>>>>>>
>>>>>>>>
>>>>>>>> [
>>>>>>>> https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin....
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ]
>>>>>>>>
>>>>>>>> Darran Lofthouse commented on WFLY-3288:
>>>>>>>> ----------------------------------------
>>>>>>>>
>>>>>>>> That could be very interested, won't go into too much detail in
>>>>>>>> this
>>>>>>>> Jira as it is not directly related shortly I am switching to the
>>>>>>>> SSL
>>>>>>>> related tasks we have outstanding including the out of the box
>>>>>>>> enablement we talked about in Brno - managing an embedded instance
>>>>>>>> could
>>>>>>>> be useful there as well to get it all op based.
>>>>>>>>
>>>>>>>> I can see this task may end up coming back my way combined with the
>>>>>>>> other stuff ;-)
>>>>>>>>
>>>>>>>>> Update add-user to use AESH or move it into the CLI
>>>>>>>>> ---------------------------------------------------
>>>>>>>>>
>>>>>>>>> Key: WFLY-3288
>>>>>>>>> URL: https://issues.jboss.org/browse/WFLY-3288
>>>>>>>>> Project: WildFly
>>>>>>>>> Issue Type: Feature Request
>>>>>>>>> Security Level: Public(Everyone can see)
>>>>>>>>> Components: Domain Management, Scripts
>>>>>>>>> Reporter: Darran Lofthouse
>>>>>>>>> Fix For: Awaiting Volunteers
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Within the add-user utility it is difficult to handle situations
>>>>>>>>> where
>>>>>>>>> we do not have access to a java.io.Console which is the easiest
>>>>>>>>> way to
>>>>>>>>> handle password reading without an echo to the user e.g. in Cygwin
>>>>>>>>> Switching to AESH would allow us to use the implementation
>>>>>>>>> there to
>>>>>>>>> handle this.
>>>>>>>>> Alternatively it may actually make sense to make add-user a
>>>>>>>>> special
>>>>>>>>> mode of the CLI, we may at some point want to switch to runtime
>>>>>>>>> operations being executed on the server so porting to the CLI
>>>>>>>>> could be
>>>>>>>>> the first step to make this possible.
>>>>>>>>> Overall this is going to require further discussion so the
>>>>>>>>> comments
>>>>>>>>> here are just a starting point.
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
>>
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
10 years, 8 months
Jigsaw early-access builds updated (JDK 9 build 40)
by Rory O'Donnell
Hi Jason/Tomaz,
JDK 9 Early Access with Project Jigsaw build b40 is available for
download at :
https://jdk9.java.net/jigsaw/
The goal of Project Jigsaw [2] is to design and implement a standard module
system for the Java SE Platform, and to apply that system to the
Platform itself
and to the JDK.
The main change in this build is that it includes the jrt: file-system
provider,
so it now implements all of the changes described in JEP 220.
Please refer to Project Jigsaw's updated project pages [2] & [4] and Mark
Reinhold's update [5] for further details.
We are very interested in your experiences testing this build. Comments,
questions, and suggestions are welcome on the jigsaw-dev
<http://mail.openjdk.java.net/mailman/listinfo/jigsaw-dev> mailing list or
through bug reports via bugs.java.com <http://bugs.java.com/>.
Note: If you haven’t already subscribed to that mailing list then please do
so first, otherwise your message will be discarded as spam.
Rgds, Rory
[1] https://jdk9.java.net/jigsaw/
[2] http://openjdk.java.net/projects/jigsaw/
[3] http://openjdk.java.net/jeps/220
[4] http://openjdk.java.net/projects/jigsaw/ea
[5]
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2014-November/004014.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
10 years, 10 months
IMPORTANT: First overview of changes to jboss-ejb-client 3.0 for WildFly 10 (probably)
by David M. Lloyd
I don't want to commit this to a specific WildFly release but I guess
and hope it'll come in around WildFly 10 or so (definitely not 9).
As previously discussed, the EJB client architecture is undergoing the
following substantial changes:
• Introduction of URIAffinity, and URI-based invocation
• Expansion of the 'ejb' JNDI initial context to auto-associate the
PROVIDER_URL as the URI affinity for looked-up proxies
• Elimination of all "nested" EJB client context functionality
• Integration with Elytron for client identity management
• Deferral to Remoting for automatic connection management
• Unification of client configuration, so the Elytron authentication
client, Remoting connection management, remote transaction client, and
EJB client configurations all can be configured in one file or
deployment descriptor
As such, I've introduced a 2.x branch for upstream where continued
development of the 2.x series will take place. The "master" branch is
being re-purposed towards this new development, targeted for 3.x of this
library.
There are a number of compatibility considerations from 2.x to 3.x.
Most (I hope) existing client code (which avoids specialized manual
configuration or nested client contexts) should continue to function
as-is, with the following exceptions:
• The following classes and interfaces are currently removed in my
working copy:
• ClusterContext - replaced with discovery (?)
• ClusterNodeManager - replaced with discovery
• ClusterNodeSelector - replaced with discovery
• DeploymentNodeSelector - replaced with discovery
• ContextSelector - replaced with general selector class
• ConstantContextSelector
• IdentityEJBClientContextSelector
• ThreadLocalContextSelector
• EJBClientContextInitializer - no replacement
• DefaultInterceptorsClientContextInitializer
• TransactionRecoveryContextInitializer
• EJBClientContextIdentifier - no replacement
• NamedEJBClientContextIdentifier
• DefaultCallbackHandler - no replacement
• EJBClientConfiguration - replaced with context builder
• PropertiesBasedEJBClientConfiguration
• EJBClientContextListener - no replacement
• EJBClientInterceptor.Registration - no replacement (interceptor
set cannot be changed)
• EJBClient*TransactionContext - replaced by
wildfly-transaction-client facility
• EJBReceiverContext - no replacement
• ReceiverInterceptor - no replacement (internal class)
• ALL public classes in the org.jboss.ejb.client.remoting package
including ReconnectHandler
• The following changes will be made to these core classes and interfaces:
• EJBClient
• Added more createSession() variants to support new affinity types
• Change createSession() methods to throw CreateException instead
of Exception
• Remove createProxy() and createSession() variants which accept
EJBClientContextIdentifier
• Remove getEJBClientContextIdentifierFor() method
• Attachable
• Remove getAttachments() method
• EJBClientContext
• No longer implements Closeable
• Remove close() method
• Remove all static create() methods, replaced with Builder class
• Remove finalize() method
• Remove getClusterContext(), getEJBClientConfiguration(),
getOrCreateClusterContext(), removeCluster()
• Remove selector-related methods, replaced with general Selector
class
• Remove register*() and unregister*() methods (providers are
added to Builder)
• Remove require() method which accepts EJBClientContextIdentifier
• Add getInvocationTimeout() method
• Affinity
• Add forUri() factory method
• EJBClientInvocationContext
• Add getCompressionLevel(), isClientAsync(), and isIdempotent()
query methods
• Remove finalize()
• EJB*Locator classes
• Additional constructors which also accept an affinity
• Additional "copy" constructors which accept a locator and
affinity, to change the target affinity
• EJBReceiver class
• openSession() method changed to accept a stateless EJB locator
• Constructor changed to no args
• Remove all send*() and other methods related to transactions
• Remove associate(), getNodeName(), [de]registerModule(), exists()
• EJBReceiverInvocationContext
• Remove retryInvocation() method
• Remove getEjbReceiverContext() method
• Remove getNodeName() method
• EJBMetaDataImpl
• Deprecated, changed to not use raw types
• RequestSendFailedException
• Replaced constructor with standard exception four-constructor setup
• The following API classes are added:
• EJBClientPermission - a general permission class
• AbstractEJBMetaData - type-safe hierarchical version of
EJBMetaDataImpl
• EJBClientContext.Builder - forwards-compatible builder for
EJBClientContext
• EJBDiscoveryProvider - an interface to provide pluggable discovery
• EJBTransportProvider - an interface to provide URI-compatible
transport (factory for EJBReceivers)
• URIAffinity - a type of affinity which has a URI for a target
Note in particular that most of the cluster-support infrastructure is
presently removed with no replacement. It is my hope and intent that
the discovery infrastructure will be able to take over this function.
How much of the code will be new, compared to how much of the code can
be forward-ported and reintroduced from 2.x, remains to be discussed.
At present, the plan is for wire compatibility to be supported for 2.x
clients talking to 3.x servers and vice-versa.
Transaction handling will be relegated to a separate
wildfly-transaction-client API. However the getUserTransaction(node)
method will continue to be supported as a deprecated delegation to the
transaction-client API. In addition, when talking to a 2.x server, it
is expected that a wildfly-transaction-client SPI implementation will
piggyback on the existing EJB protocol transaction messages.
If any of these API changes seems unacceptable, now is the time to
discuss it. All the code that was removed was determined to be tied too
tightly to the previous location or configuration strategy, and thus
couldn't sensibly be supported going forward. I have hopefully been
adequately upfront about what I intended to remove or support going
forward. In addition, by supporting the 2.x client, most migration
concerns can hopefully be mitigated. But it's possible that some
classes or methods could indeed be reintroduced with sensible semantics
and in such a way as to not cause problems; if you have any thoughts
along these lines, please share them and we can discuss them on a
case-by-case basis.
I've pushed up the proposed baseline 3.0 API at
https://github.com/dmlloyd/jboss-ejb-client/tree/uri_invocation for
review. I intend for pull requests that are relevant to both old and
new code bases to be applied to both if possible, to avoid increasing
the incompatibility window even further.
--
- DML
10 years, 10 months
JBAS011592 the logging subsystem requires the log manager to be org.jboss.logmanager.LogManager
by Max Rydahl Andersen
Heya,
In tools and around arquillian I'm seeing more and more of $subject
error that I can't figure out the cause of.
I've found https://issues.jboss.org/browse/WFLY-3152 which David
responds the error message is clear.
I might be clear, but I can't figure out why starting wildfly the exact
same way will in one case result in this
error but then on second start it just works.
I first thought that our tools might not be setting the LogManager
(which it does not), but when I look at standalone.sh
in the same server there is also no setting of this property hence
afaics the server is being obtuse.
The answer in all cases seem to have been "have tried restarting it?"
and then things starts working, until it doesn't - and
then we restart again.
Any idea on what is going on here ?
Thanks,
/max
http://about.me/maxandersen
10 years, 11 months
Regression in Java EE 7 HOL
by Arun Gupta
Java EE 7 HOL is failing to deploy on WildFly 8.2:
12:08:38,801 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8)
MSC000001: Failed to start service
jboss.deployment.unit."movieplex7-1.0-SNAPSHOT.war".WeldStartService:
org.jboss.msc.service.StartException in service
jboss.deployment.unit."movieplex7-1.0-SNAPSHOT.war".WeldStartService:
Failed to start service
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
[jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[rt.jar:1.8.0_20]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[rt.jar:1.8.0_20]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-000072: Bean
declaring a passivating scope must be passivation capable. Bean: Managed
Bean [class org.javaee7.movieplex7.booking.Booking] with qualifiers
[@Default @Any @Named]
at org.jboss.weld.bean.ManagedBean.checkType(ManagedBean.java:203)
at
org.jboss.weld.bean.AbstractBean.initializeAfterBeanDiscovery(AbstractBean.java:105)
at
org.jboss.weld.bean.ManagedBean.initializeAfterBeanDiscovery(ManagedBean.java:113)
at
org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136)
at
org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127)
at
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
at
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[rt.jar:1.8.0_20]
... 3 more
Its complaining for the bean defined at:
https://github.com/javaee-samples/javaee7-hol/blob/master/solution/moviep...
This has worked, and is still working fine, on WildFly 8.1.
Thoughts ?
Arun
10 years, 11 months
WFCORE-276 - :whoami(verbose=true) Fails for user with no roles.
by Darran Lofthouse
Hello Alexey / Brian,
Just trying to get to the bottom of a failure where
:whoami(verbose=true) is being performed by a user in the CLI with no
roles and the following error is received and looking for some ideas.
"WFLYCTL0313: Unauthorized to execute operation
'read-operation-description' for resource '[]' -- "WFLYCTL0332:
Permission denied""
The call to the :whoami operation would be fine except as there is a
parameter the CLI is attempting to validate the parameters by making a
call to read-operation-description and it is that call that is failing.
Personally I think this operation working is important as it enables
some debugging of role assignment, i.e. if a user has not been granted
the expected roles this call helps provide some information about that.
So unless we are going to say the user should not be calling whoami we
broadly have two options: -
1 - Make a special case in the CLI and skip the
read-operation-description call.
2 - Access control changes to make it possible to call
read-operation-description for the whoami operation.
Regards,
Darran Lofthouse.
10 years, 11 months
About client-side configuration
by David M. Lloyd
I'm currently working on reorganizing most of our client-side components
to support URI-based connection and invocation for the following services:
• JBoss Remoting
• EJB Client
• Remote Naming (JNDI)
• Remote Transactions
• Elytron (remote authentication)
Each of these components will require a separate chunk of configuration.
The works in progress presently will rely on separated XML files for
each of these things (which in many/most cases will be reusable
in-container as deployment descriptors).
I think you see where I'm going with this.
I'm kicking around the idea of doing something kind of similar to the
unified configuration idea we tried out in WildFly, where there's one
namespaced configuration file with each component picking up its piece
via some registration process.
The upside is, (optionally?) one client-side configuration file for
everything, even things we haven't written yet.
The downside is having another common dependency for everything that
consumes client configuration. Though we *could* make it optional
(which in turn has another downside that we can't really unify our
parsing, which has some benefits like consistent error reporting,
xinclude support, and pretty substantial code deduplication, among
(probably) other things).
I'm leaning towards just going ahead with it and creating a small
wildfly-client-configuration project which parses a "wildfly-client.xml"
file and does the business.
Any thoughts, opinions, additional reasons not to do this?
--
- DML
10 years, 11 months
