CLI new (generic type) commands
by Alexey Loubyansky
So, I've pushed the prototype for the new approach.
http://community.jboss.org/wiki/GenericTypeCLICommands
Advantages
- any changes in the management model (added/removed operations,
properties, etc) become immediately available in CLI commands without
code changes in the CLI;
- command help content is generated from the description of type,
operations and properties in the management model (so, no text
duplication, localization, etc);
- commands can be added and removed at runtime and customized by the user;
-the total number of cli commands will decrease and they, in a way, will
be better categorized.
Disadvantages
Tab-completion suffers from insufficient info in the management model
about the types, values and relationships/dependencies between the node
and operation properties.
- enumeration values, if the type is boolean, I can do it, but if it's
something else (e.g. tx isolation) the allowed values would have to be
specified in the management model for the type in fixed format;
- exclusive properties, e.g. driver-class/driver-name for datasources.
If I code the data-source command myself I can automatically exclude one
if the other one has been specified;
- referencing properties, e.g. driver-name accepts values that are
registered jdbc driver names, for that to tab-complete, this reference
would have to be described in the model.
There are probably other things that I forgot to mention. I'll follow up
if I remember something.
As always, feedback, ideas, suggestions are welcome.
Thanks,
Alexey
PS: it's not yet in the master as I send it, I did send the pull request
though, so, it's gonna be soon.
14 years, 12 months
transaction integration
by Jonathan Halliday
I've recently created a bunch of JIRAs for the simpler bits of the
transaction integration work. However, there are some design issues that
need discussion before the work can be codified into JIRAs...
First up, distributed transactions. By that I mean ones involving
business logic in more that one JVM. The simpler case of 'distributed'
in the multiple resource manager sense already more or less works.
The transaction system can run in two modes - jta, which does not
support transactions spanning multiple jvms, or jts, which does.
Right now the AS decides which mode to boot depending on the presence of
an ORB, since that is used as the transport for distributed transaction
coordination. This is itself potentially a problem, since it's possible
that a user wants the ORB for non-transaction use only and does not want
to pay the performance penalty for running jts mode transactions that
never actually leave the local jvm. Even for local use the jts is
substantially slower than jta. So, you may want to consider allowing the
currently automated jta/jts choice to be overridden by the user. Another
interesting possibility is to use the module system to run two isolated
copies of the transaciton engine, one in jta and one in jts mode, then
allow applications to determine which they want and bind the JNDI
lookups accordingly. But I digress.
There is an interdependency between the ORB and the transaction system,
in that the ORB runs a set of iniializers at startup and when the jts is
enabled these must include the jts service inializers. However, the
transaction system depends on the ORB... (AS7-1494)
Assuming the user does require distributed transactions and the server
is running magically running with the jts enabled, we come to the
problem of distributed transaction boundary demarcation and context
propagation.
Whilst the transaction control traffic always runs over CORBA, the
business logic, typically EJB calls, may not. As far as I can tell
there is as yet no spec or documentation on what we intend to support
here or how tx context propagation and inflow is intended to work.
There is also the question of the extent to which we'll support tx use
by external or legacy clients, be they Java or CORBA. i.e. client to
server or server to older server, rather than between two AS7 instances.
The ClientUserTransaction proxy arrangement in the old AS pre-dated
the jts integration and never worked cleanly with it. We need to come up
with something better.
Who is handling the requirements and design for this in AS7?
Thanks
Jonathan.
--
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Mark Hegarty (Ireland), Matt Parson
(USA), Charlie Peters (USA)
15 years
How to fast-forward a pull request in github?
by David Bosschaert
Hi all,
When applying a pull request in Github (using the Big Green Button that
says 'Merge Pull Request') this always creates a merge commit which is
something that we generally don't like (I think ;)
How people generally apply pull requests with a fast-forward for a
cleaner commit history? Is there some handy command that people use for
this?
Cheers,
David
15 years
Moving EJB3 code into the AS7 source tree
by Stuart Douglas
Hi Guys,
While looking at some EJB3 stuff I began to wonder just how much stuff from the JBoss EJB3 maven artefacts we actually use. Even though there is a lot of artefacts, it turns out that we use around 75 classes from EJB3, and more than half of them are timer service related (It looks like a lot of the stuff in the EJB3 package is either legacy stuff that is just hanging around).
Given that the majority of the actual EJB logic / implementation is in the AS modules (in the EJB and EE modules), I was wondering if it would be worth merging the whole of EJB into AS7 and dumping the EJB3 aggregator project altogether.
I have a branch that does this here (although this branch has not migrated any tests yet):
https://github.com/stuartwdouglas/jboss-as/tree/remove
Personally I think this would make it much easier to refactor, and would also allow us to remove some adaptor classes between AS7 and EJB3 (e.g. AS7 has to sub class the EJB3 interceptors, rather than EJB3 providing real jboss invocation interceptors).
Stuart
15 years
Single Sign On and Connection pool problems to port application from AS6 to AS7
by Bill Hong (Gong)
Hi,
Our company intends to port our web based product from Weblogic to JBoss. For several months, I've been working on porting our system to JBoss. We've been successfully migrated our application to AS6. However, we failed to port our system to AS7 because of a couple of critical problems. Here are problems we got:
1) We can't find the details about how to configure Single Sign On in AS7. In AS6, it's simply turn on a option in server.xml. Does anyone know if AS7 still supports this option? If yes, how to configure it in standalone.xml/domain.xml?
2) The features to start/stop/reset connection pool is removed from admin console. So how to manage the connection pool now? We need to start/stop/reset connection pool in product environment.
I hope this is appropriate place to ask questions. I would appreciate if anyone can give me some suggestions or clues to address those problems.
Thank you!
Regards,
Bill
________________________________
CONFIDENTIALITY NOTICE
This e-mail message from Delphi Technology, Inc. is intended only for the individual or entity to which it is addressed. This e-mail may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you received this e-mail by accident, please notify the sender immediately and destroy this e-mail and all copies of it.
15 years
Listen to all JBoss logging messages
by David Bosschaert
Hi all,
For a test case I'm looking for a way to simply listen to all the log
messages sent through JBoss logging. Is there a way to do this?
Thanks,
David
15 years
detecting JPA usage in AS7 applications...
by Scott Marlow
Currently, we are injecting JPA related module dependencies into
applications that have valid persistence units in persistence.xml.
This is wrong I think. We probably only need to look for the presence
of @PersistenceUnit @PersistenceContext and same in deployment
descriptors (which we currently also do).
I don't want to inject the JPA dependencies just because there is
persistence unit definition (we can still parse it and have it available
for use).
This might help us deploy native Hibernate applications that don't use
EE JPA.
Scott
15 years
IMPORTANT TCCL & JAXP Changes!
by Jason T. Greene
Hello Everyone,
While we still want to avoid using TCCL for anything but interacting
with thirdparty components or the SDK [1], there are some changes that
have been made to the current master that make it easier to work with.
To discourage use in AS, and prevent the wrong classloader from ever
being used, in many contexts (e.g. service lifeycle methods) we used to
null the TCCL. Unfortunately due to (yet another) bug in various JAXP
API implementations, a null TCCL, would trigger this problem:
https://issues.jboss.org/browse/AS7-1630
It also made using JAXP from a service or a management operation a
little unwieldy since you had to push/pop TCCL yourself, as decribed in [1].
To address these issues we now ALWAYS set TCCL to the defining
classloader of the component in the following cases:
- MSC Service lifecycle (start, stop)
- Listener callbacks
- MSC Lifecycle Context Execution Tasks
- Operation Handler invocations (includes all subsystem logic)
What does this mean to you?
1. If you are writing code that is executing in a service or as part of
your subsystem you no longer need to worry about setting the TCCL, it
will be set to your module classloader for you. You can therefore use
JAXP or any other service loader style framework without worrying about
this.
2. If you are writing code that is executed on behalf of an EE request,
then TCCL will STILL point to the spec required deployment classloader.
You MUST still push/pop the TCCL as described in [1] when using JAXP or
any other service loader framework.
If you have any questions about this, feel free to ping me about it.
[1] http://community.jboss.org/wiki/ModuleCompatibleClassloadingGuide
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
15 years
