Remoting subsystem changes
by Tomaž Cerar
Hi,
as part of fixes for https://issues.jboss.org/browse/AS7-3296
I have changed xml configuration for remoting 1.1
Changes ware made to the way xnio options are configured for
*-outbound-connections.
Now they are aligned with way options are configured for connector.
new xml configuration now looks like this:
<subsystem xmlns="urn:jboss:domain:remoting:1.1">
<connector name="remoting-connector" socket-binding="remoting"/>
<connector name="test-connector" socket-binding="test-remoting">
<properties>
<property name="org.xnio.Options.WORKER_ACCEPT_THREADS"
value="1"/>
</properties>
</connector>
<outbound-connections>
<remote-outbound-connection name="remote-conn1"
outbound-socket-binding-ref="mail-smtp">
<properties>
<property name=
"org.xnio.Options.SASL_POLICY_NOANONYMOUS" value="false"/>
<property name="org.xnio.Options.SSL_ENABLED" value=
"false"/>
</properties>
</remote-outbound-connection>
<local-outbound-connection name="local-conn1"
outbound-socket-binding-ref="mail-smtp">
<properties>
<property name=
"org.xnio.Options.SASL_POLICY_NOANONYMOUS" value="false"/>
<property name="org.xnio.Options.SSL_ENABLED" value=
"false"/>
</properties>
</local-outbound-connection>
</subsystem>
pull request with my changes https://github.com/jbossas/jboss-as/pull/1278
Brian reminded me that this changes should be discusses in broader audience
as many people have worked on remoting subsystem and my have different view
on how things should be done.
So please check if my changes don't break anything and if they are in
general ok.
cheers,
Tomaz
12 years, 10 months
Adding custom subsystem operations to web console
by Siamak Sadeghianfar
Hi,
When creating a custom subsystem in JBoss AS 7.1, a set of operations
are expose through the CLI. However I wonder if it is possible to expose
the same set of operations and attributes in the web console? If not, is
there any plan for it?
Thanks for any help.
Best Regards,
Siamak Sadeghianfar
12 years, 10 months
Deployment phase context dependencies and runtime changes to services
by Jaikiran Pai
I've got a DUP in Phase.PARSE which attaches a service attachment to the
DU by adding a dependency on to the next phase context:
phaseContext.addDeploymentDependency(ServiceName.Foo, myAttachmentKey);
Works fine. The attachment which points to a service is available in the
next phase from the DU. When I deploy a deployment, it passes through
these phases and deploys fine. Now at runtime I use the CLI to change a
writeable attribute's value which triggers a
change/update/reinstallation of the ServiceName.Foo. That's when I start
seeing problems. Due to the stop/start of the ServiceName.Foo service,
the already fully deployed deployment is re-deployed starting from
Phase.MODULE (and skipping the previous phases) because of the
dependency that was added to the phase context on this service. This
causes a whole lot of issues (like missing attachments) because the
deployment has re-started midway through the phases.
The javadoc of DeploymentPhaseContext.addDeploymentDependency says:
/**
* Adds a dependency on the service to the next phase service. The
service value will be make available as an attachment to
* the {@link DeploymentUnit}. This attachment will be removed when the
phase service for the next phase stops.
So should the dependency on the ServiceName.Foo be retained even after
the phase service has completed for the deployment unit? Is this a bug
or the expected behaviour? I wouldn't expect a re-deployment of a
already deployed unit because of changes to a service which is no longer
relevant after the deployment unit has been processed.
-Jaikiran
12 years, 11 months
Logging ids for EJB subsystem (already almost) exhausted!
by Jaikiran Pai
This relates to https://issues.jboss.org/browse/AS7-3454 where Carlo
noticed that in the EJB subsystem (and perhaps in some other subsystem
too) we exceed the numeric range for logging ids listed here
https://community.jboss.org/wiki/LoggingIds. I see a couple of problems
here:
1) The fact that we are already having almost more than 200 message ids
for EJB subsystem alone makes it look like a bit too much IMO. Looking
at many of those messages, they are sometimes related to invalid
arguments being passed to methods and we throwing
IllegalArgumentException with a specific message id. Unfortunately, this
appears to be repeated many times with different ids with a different
message instead of just having a common id/message (perhaps across
subsystems).
2) There are some unused message ids (left around after some refactoring
of code and no longer relevant). Is it too late to clean this up now? I
mean, obviously using an existing message id for a new log message
instead of what it represented earlier isn't a good idea after a catalog
of message ids has been published. But as of now, we don't have such a
catalog published anywhere. So should I go ahead and cleanup some of
these unused message ids?
3) How do I go about this specific issue? Use a new range for more EJB
messages? So we would end up with some EJB messages in the range
14100-14399 and some others in 19100-19399 (an example). Is that
multiple set of ranges for a subsystem a good thing? What happens the
next time we exhaust this range? The other option I see is that there
are some unused message ids between 14143 and 14300. I can refactor the
existing messages (which are falling outside the allocated range) to use
the unused ids, but then it depends on what we decide about #2 above
(i.e. some of the 143xx ids that were used earlier will no longer we
relevant).
-Jaikiran
12 years, 11 months
JSR88 undeployment
by Wolfgang Knauf
Hi to all,
maybe this is a dumb user question, maybe this is a bug report. As I am
not sure, I hope someone with more knowledge can comment on this.
I am experimenting with JSR88 deployment in AS7 (which now has the great
benefit that the deployed app is still alive after a server reboot now ;-) )
My code is based on a JBoss test:
https://source.jboss.org/browse/JBossAS/testsuite/integration/smoke/src/t...
JBoss version is 7.0.1CR1.
My JSR88 deployer code worked fine for JBoss 4.2 to 6, and with some
minor changes (mostly imports) I could port it to AS7. But with AS7
undeploy does not seem to work.
Attached is the output of the JBoss client side at TRACE level.
Everything seems fine, but on the server side, I don't see "app xyz was
undeployed" console output, and "standalone.xml" still contains the
deployed app.
<deployments>
<deployment
name="file:/C:/DOCUME~1/Knuffi/LOCALS~1/Temp/Stateless.ear"
runtime-name="file:/C:/DOCUME~1/Knuffi/LOCALS~1/Temp/Stateless.ear">
<content sha1="260d86890eb6b1716facde0e7e48819fe3c98f83"/>
</deployment>
</deployments>
The only server output is a "remote connection was closed by remote
side" warning message, which also happens on JSR88 deploy.
I can provide you with a full working sample of my small app if
necessary, but this would need a bit of refactoring :-(
Best regards
Wolfgang
12 years, 11 months
multiple instances of AS per VM?
by Scott Marlow
Do we have any use cases where we need to support multiple instances of
the AS per VM? I heard that this was part of the early design but
doesn't seem to be taken advantage of, as far as I know.
In my changes for AS7-2076 (serialization of extended persistence
context), I used a class variable, which would be shared between the
multiple AS instances (if I don't change it). I could switch to using a
service and lookup the service through
CurrentServiceContainer.getServiceContainer().getService() but that also
uses a class variable for tracking the current AS. The advantage of
using CurrentServiceContainer.getServiceContainer(), is better
encapsulation of code that needs to change, if we do run multiple AS
instance per VM at some point.
Scott
12 years, 11 months
quickstarts: permgen space
by Heiko Braun
I do constantly run into PermGen space errors when deploying the login quickstart.
Does somebody experience the same problems?
JAVA_OPTS: -Xms64m -Xmx512m -XX:MaxPermSize=256m -client -d32 -Xverify:none -XX:+UseFastAccessorMethods -XX:+DisableExplicitGC
--
Heiko Braun
Senior Software Engineer
JBoss by Red Hat
http://about.me/hbraun
12 years, 11 months
JNDI integration question
by David Bosschaert
Hi all,
I'm looking at integrating the OSGi JNDI spec [1] with AS7.
Implementations of this spec (which exposes OSGi services via JNDI to
allow JavaEE integration) create a few javax.naming.spi.ObjectFactory
instances to handle some additional namespaces, e.g. osgi:service lookups.
To get this working with AS7 I can call
org.jboss.as.naming.InitialContext.addUrlContextFactory(scheme,
myObjectFactory)
and that works fine.
However, I'm curious, is there a non-JBoss-specific way to do this too
(i.e. part of the JEE naming spec). If there is, I can make the Apache
Aries OSGi-JNDI implementation call this directly and it would avoid the
need for some AS7-specific glue code...
Thanks,
David
[1] Chapter 126 in the 4.2 Enterprise Spec
http://www.osgi.org/Download/Release4V42
12 years, 11 months
