Updates to Arquillian OSGi
by Thomas Diesler
Hi Aslak,
there have been several updates to the arq osgi container - accumulated
in this pull request
https://github.com/arquillian/arquillian-container-osgi/pull/11
You may want to consume these and create the related upstream tags.
Alternatively, we could change the SCM reference in the POM and make
jbosgi the upstream home of this component. In which case you would not
have to do these chores any more.
How would you like to handle this?
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
12 years, 2 months
JBAS010985: unrecognized type 36
by Heiko Braun
On a recent build I see these in the logs :
[Server:server-one] Caused by: java.io.IOException: JBAS010985: unrecognized type 36
[Server:server-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:110) [jboss-as-protocol-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
Any ideas what might be causing this?
12 years, 2 months
Exception with connectionfactory lookup from remote client
by Deshpande, Prasad
Hi Guys,
I'm trying to lookup connectionfactory which is usually bound to java:/JmsXA in remote standalone client & here is the stack I'm getting...
javax.naming.NamingException: Failed to lookup [Root exception is java.io.NotSerializableException: org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl]
at org.jboss.naming.remote.client.ClientUtil.namingException(ClientUtil.java:36)
at org.jboss.naming.remote.protocol.v1.Protocol$1.execute(Protocol.java:101)
at org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1.lookup(RemoteNamingStoreV1.java:73)
at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:61)
at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:65)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at com.banctec.process.client.logviewer.helpers.JMSSubscription.setupSubscription(JMSSubscription.java:100)
at com.banctec.process.client.logviewer.LogViewerController.setupJMS(LogViewerController.java:195)
at com.banctec.process.client.logviewer.LogViewerController.loginProcess(LogViewerController.java:176)
at com.banctec.process.client.logviewer.processroot.LoginDialog.okPressed(LoginDialog.java:211)
at org.eclipse.jface.dialogs.Dialog.buttonPressed(Dialog.java:365)
at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:506)
at org.eclipse.swt.widgets.TypedListener.handleEvent(Unknown Source)
at org.eclipse.swt.widgets.EventTable.sendEvent(Unknown Source)
at org.eclipse.swt.widgets.Widget.sendEvent(Unknown Source)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Unknown Source)
at org.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:668)
at org.eclipse.jface.window.Window.open(Window.java:648)
at com.banctec.process.client.logviewer.LogViewerController.login(LogViewerController.java:112)
at com.banctec.process.client.logviewer.processroot.ProcessRoot.initNode(ProcessRoot.java:71)
at com.banctec.process.client.logviewer.MainFrame$TreeChangedListener.selectionChanged(MainFrame.java:407)
at org.eclipse.jface.viewers.Viewer$2.run(Viewer.java:159)
at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:615)
at org.eclipse.core.runtime.Platform.run(Platform.java:747)
at org.eclipse.jface.viewers.Viewer.fireSelectionChanged(Viewer.java:157)
at org.eclipse.jface.viewers.StructuredViewer.updateSelection(StructuredViewer.java:1394)
at org.eclipse.jface.viewers.StructuredViewer.handleSelect(StructuredViewer.java:693)
at org.eclipse.jface.viewers.StructuredViewer$4.widgetSelected(StructuredViewer.java:718)
at org.eclipse.jface.util.OpenStrategy.fireSelectionEvent(OpenStrategy.java:180)
at org.eclipse.jface.util.OpenStrategy.access$3(OpenStrategy.java:175)
at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:324)
at org.eclipse.swt.widgets.EventTable.sendEvent(Unknown Source)
at org.eclipse.swt.widgets.Widget.sendEvent(Unknown Source)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Unknown Source)
at org.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source)
at com.banctec.process.client.logviewer.MainFrame.run(MainFrame.java:323)
at com.banctec.process.client.logviewer.LogViewerController.start(LogViewerController.java:93)
at com.banctec.process.client.logviewer.LogViewerMain.<init>(LogViewerMain.java:95)
at com.banctec.process.client.logviewer.LogViewerMain.main(LogViewerMain.java:112)
Caused by: java.io.NotSerializableException: org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1057)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1013)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:992)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:879)
at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1057)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1013)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:879)
at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
at org.jboss.naming.remote.protocol.v1.Protocol$1$2.write(Protocol.java:135)
at org.jboss.naming.remote.protocol.v1.WriteUtil.write(WriteUtil.java:61)
at org.jboss.naming.remote.protocol.v1.Protocol$1.handleServerMessage(Protocol.java:125)
at org.jboss.naming.remote.protocol.v1.RemoteNamingServerV1$MessageReciever$1.run(RemoteNamingServerV1.java:70)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: an exception which occurred:
in field cachedConnectionManager
in field cm
in object org.hornetq.ra.HornetQRAConnectionFactoryImpl@5126db0<mailto:org.hornetq.ra.HornetQRAConnectionFactoryImpl@5126db0>
________________________________
BancTec Limited.
Registered Office: Jarman House, Mathisen Way, Poyle Road, Colnbrook, Berkshire SL3 0HF. Incorporated in England & Wales : 1283512. VAT : GB 228 4783 38.
12 years, 2 months
Testsuite simplification (runs faster!)
by Ondrej Zizka
Hi,
I've simplified the testsuite.
Before, it's execution plan was a bit chaotic - things being wildly
copied around without much design in it.
Now it works recursively as it should.
That means:
testsuite/ copies from build/target/... or -Djboss.dist, and
configures things used uniformly by whole testsuite: IP, datasource,
users, etc.
Then, in every submodule:
- AS is copied from ../target/jbossas to target/jbossas, and makes
it's own changes;
- target/jbossas is copied to target/jbossas-something; those are
the instance(s) to be run.
The pom.xml's have changed a lot, so now I need someone to review and
merge it before it gets too complicated to resolve rebase conflicts.
Thanks,
Ondra
12 years, 2 months
AS 7 as a service to local users
by Carlo de Wolf
We had an interesting discussion on #fedora-java in which Max proposed a
feature to allow any user to deploy to the running AS 7 instance.
I think we all agree that ultimately this is a multi-tenancy issue. But
for now we could settle on having user permissions on deployment repo
operations.
What are other peoples thoughts?
Carlo
12 years, 2 months
Changed arguments…can we do better ? :P
by Max Rydahl Andersen
Hey,
Going over the AS7.1 server and how startup arguments has changed we noticed besides the -logmodule not being needed
the following two was added:
-Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
Does the -Djava.awt.headless=true have any function besides maybe give a few milliseconds faster startup ?
(asking since this prevents you to launch (for debugging purposes) hsqldb admin and other swing based "inspection" tools)
And last I asked about adding jboss.modules.system.pkgs= arguments to better support common tools that uses java agents such as JProfiler, yourkit, byteman and others
it was said we shouldn't add these specific ones since then we were choosing one over the other ;)
Any reason why byte man gets added and not the others ?
And couldn't we solve this in a better way by having jboss modules look for a property file to pick these up instead of command line arguments ?
i.e. anything found in <cwd>/jboss-modules.properties is added to system properties before it starts loading its actual module + treat jboss.modules.arguments as additional arguments ?
Can't remove the need for -Djava.awt.headless but would remove need for many of the other custom settings.
I can submit a patch that does this if interested.
/max
http://about.me/maxandersen
12 years, 2 months
Parallel initialization of more web applications in EAR
by Marek Novotny
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi AS developers,
I am exploring the behavior of parallel initialization of web
application in EAR. More concretely more than one web application in EAR.
I know that spec doesn't define the initialization order of EAR
submodules, but the parallel initialization of web application is new in
AS7 and this breaks the backward compatibility for existing enterprise
applications with multiple wars inside. New Java Enterprise application
6 configuration setting <initialize-in-order>true</initialize-in-order>
set up in application.xml can enable proper initialization flow, but
without it is not possible to deploy.
Could somebody shed light on parallel web applicaiton init? Original
forum post https://community.jboss.org/message/635123
And details could be seen also at
https://issues.jboss.org/browse/JBSEAM-4856?focusedCommentId=12662448&pag...
Cheers,
- --
Marek Novotny
- --
JBoss Seam and WFK Productization Lead
Red Hat Czech s.r.o.
Purkynova 99
612 45 Brno
Email: mnovotny(a)redhat.com
Office phone: +420 532 294 287, ext. 82-62 087
mobile: +420 608 509 230
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8nEsgACgkQU4HO8G8hNxV0jgCfXmgIy5a5mUctcy35Xg8SIky+
ubkAoOrmfoF7ByaQjUX4Wbfu+3w5sAH1
=Uv1K
-----END PGP SIGNATURE-----
12 years, 2 months
master/trunk snapshot issues for CLI and -ds.xml
by Max Rydahl Andersen
Hi,
I wanted to try out AS7 master tonight to test out the new -ds.xml features but I ran into a bunch of issues;
and since it seem to be such basic issues I didn't want to pollute jira upfront.
Is any of this expected currently:
A) jboss-cli --connect just freezes
B) jboss-cli --gui loads UI but NPE's and clicking causes more errors
C) deploying -ds.xml with xadatasource fails after logging a lot of errors/warnings about private api
"[org.jboss.as.dependency.private] (MSC service thread 1-1) JBAS018567: Deployment "deployment.wonka.war" is using a private module ("<x.y.z>") which may be changed or removed in future versions without notice"
D) deploying -ds.xml without xadatasource seem to work but once app is trying to access logs gets filled with more:
[org.jboss.as.dependency.private] (MSC service thread 1-1) JBAS018567: Deployment "deployment.wonka.war" is using a private module ("org.jboss.iiop-client:main") which may be changed or removed in future versions without notice
E) I can't figure out how to reference it in persistence.xml or resource lookups.
Using the datasource name, i.e. java:jboss/datasources/DeployedDS does not work in persistence.xml
Tried both with -ds.xml inside and outside war.
note, I did nothing special - just a servlet and a CDI bean + persistence.xml; trying to keep it as simple as possible.
should I open lira's or is master considered non-functional in these areas at the moment ? :)
/max
http://about.me/maxandersen
12 years, 2 months
Invalid assumption across most subsystem deployments
by Thomas Diesler
Folks,
here is a friendly reminder that your DUPs must take OSGi deployments
into consideration. So if you mark a given DU as of type foo, you must
make sure that foo is also supported as an OSGi bundle deployment.
I constantly fix DUPs that assume that every deployment is a module
deployment. Here is the latest one
Caused by: java.lang.NullPointerException
at
org.jboss.as.jaxrs.deployment.JaxrsScanningProcessor.deploy(JaxrsScanningProcessor.java:101)
at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113)
Generally, I don't mind fixing those since I cannot assume that you even
know/care what an OSGi bundle deployment is ;-)
However, on our way to x.y.z.Final we probably want to avoid these basic
errors.
What do you need to do is to check that a given DU does not contain a
valid OSGi Manifest before you mark it as "your type"
public void deploy(final DeploymentPhaseContext phaseContext)
throws DeploymentUnitProcessingException {
DeploymentUnit deploymentUnit =
phaseContext.getDeploymentUnit();
if(deploymentUnit.hasAttachment(Attachments.OSGI_MANIFEST)) {
return;
}
if(deploymentUnit.getName().toLowerCase().endsWith(WAR_EXTENSION)) {
DeploymentTypeMarker.setType(DeploymentType.WAR,
deploymentUnit);
}
}
Please take a minute to review your "entry point" DUP and make sure it
ignores OSGi deployments if you are not prepared to handle them.
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
12 years, 2 months
