cannot find symbol PROCESS_CHILD_ANNOTATION_INDEX
by Carlo de Wolf
Master does not compile at the moment. Do we have a Hudson instance that
verifies this?
Carlo
===8<===
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.1:compile
(default-compile) on project jboss-as-server: Compilation failure:
Compilation failure:
[ERROR]
/home/carlo/work/jboss-as/server/src/main/java/org/jboss/as/server/deployment/annotation/AnnotationIndexUtils.java:[45,80]
cannot find symbol
[ERROR] symbol : variable PROCESS_CHILD_ANNOTATION_INDEX
[ERROR] location: class org.jboss.as.server.deployment.Attachments
[ERROR]
[ERROR]
/home/carlo/work/jboss-as/server/src/main/java/org/jboss/as/server/mgmt/domain/HostControllerClient.java:[213,62]
[deprecation] getServerModel() in org.jboss.as.server.ServerController
has been deprecated
[ERROR]
[ERROR]
/home/carlo/work/jboss-as/server/src/main/java/org/jboss/as/server/mgmt/domain/HostControllerClient.java:[292,56]
[deprecation] getServerModel() in org.jboss.as.server.ServerController
has been deprecated
[ERROR]
[ERROR]
/home/carlo/work/jboss-as/server/src/main/java/org/jboss/as/server/mgmt/ServerControllerOperationHandler.java:[204,55]
[deprecation] getServerModel() in org.jboss.as.server.ServerController
has been deprecated
[ERROR]
[ERROR]
/home/carlo/work/jboss-as/server/src/main/java/org/jboss/as/server/mgmt/ServerControllerOperationHandler.java:[392,45]
[deprecation] getServerModel() in org.jboss.as.server.ServerController
has been deprecated
[ERROR]
[ERROR]
/home/carlo/work/jboss-as/server/src/main/java/org/jboss/as/server/ManagementInstallationService.java:[54,66]
[deprecation] getServerModel() in org.jboss.as.server.ServerController
has been deprecated
[ERROR]
[ERROR]
/home/carlo/work/jboss-as/server/src/main/java/org/jboss/as/server/deployment/annotation/AnnotationIndexProcessor.java:[79,91]
cannot find symbol
[ERROR] symbol : variable INDEX_IGNORE_PATHS
[ERROR] location: class org.jboss.as.server.deployment.Attachments
15 years, 1 month
EJB 3 Proxies
by Carlo de Wolf
The goal is to provide the functionality as outlined in EJB 3.1 FR 4.3.3
getBusinessObject and getEJB* methods, plus 4.4 Global JNDI Access.
EJB Servitors provide an entry point InvocationDispatcher. Behind this
entry point the local system interceptors are invoked. In essence an EJB
Servitor is a 'singleton' ManagedBean
For the purpose of JNDI the distinction is made between JNDI objects and
true proxies. JNDI objects can be proxies, LinkRef or ObjectFactory. A
true proxy is either a direct link or a lazy link to the servitor via
its InvocationDispatcher interface.
The JNDI names where the JNDI objects are bound are generated by an ejb3
component. Who binds these objects is currently undecided.
The generation of JNDI objects is delegated out of ejb3 to another
construct.
Within an EJB the user can call upon getBusinessObject for example. In
this case a true proxy needs to be returned. Again ejb3 delegates out to
another construct.
Possibly the JNDI object and proxy factories can be co-located within
one component.
Note, there is a risk of overlap with remote invocation. Remote
invocation is explicitly beyond scope of the EJB servitor dispatcher.
Remote proxies are special InvocationDispatchers which can have client-
and server side interceptors. The client side interceptors prepare for
marshaling of the current invocation context (transaction, security
etc). The server side interceptors transform the marshaled context into
the local context equivalent.
In short we need to design a way to bind the EJB views.
Do we really need a service per JNDI binding (as per [1])?
Carlo
[1]
http://community.jboss.org/wiki/JavaEEImplementationTechnicalRequirements
15 years, 1 month
Arquillian + Embedded + Modular Surefire Plugin
by Kabir Khan
I am trying to get the demos that I see working (sar, serviceloader, messaging, jms, jms.client) running again as part of the smoke tests using the forked surefire plugin which loads everything with modular classloading. On the client this works fine, but for IN_CONTAINER tests I am seeing the stack trace at the end.
The basic problem seems to be that Arquillian calls MessagingTestCase.getDeployment() on the client as expected, however it then also calls it on the server once it is deployed which causes this error. Does this really need to happen on the server? Is there a way to disable this?
This then causes ShrinkWrap's ContainerBase to use the TCCL, which is the classloader of the deployment, to search for rg.jboss.as.test.modular.utils.ShrinkWrapUtils which is part of the deployment. URLPackageScanner.scanPackage() finds the url: "vfs:/content/messaging-example.jar/org/jboss/as/test/modular/utils/" which becomes "/content/messaging-example.jar/org/jboss/as/test/modular/utils/" before it is added to the list passed in to handleArchiveByFile(). Since "content/messaging-example.jar/org/jboss/as/test/modular/utils/" does not exist, it all falls over.
org.jboss.arquillian.impl.event.FiredEventException: java.lang.RuntimeException: Could not get Deployment
at org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:68)
at org.jboss.arquillian.impl.context.AbstractEventContext.fire(AbstractEventContext.java:115)
at org.jboss.arquillian.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:99)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:165)
at org.jboss.arquillian.junit.Arquillian$3$1.evaluate(Arquillian.java:189)
at org.jboss.arquillian.junit.Arquillian$MultiStatementExecutor.execute(Arquillian.java:300)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:185)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:128)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at org.junit.runner.JUnitCore.run(JUnitCore.java:136)
at org.jboss.arquillian.junit.JUnitTestRunner.execute(JUnitTestRunner.java:69)
at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:145)
at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodEmbedded(JMXTestRunner.java:114)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262)
at javax.management.StandardMBean.invoke(StandardMBean.java:391)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:288)
at $Proxy18.runTestMethodEmbedded(Unknown Source)
at org.jboss.arquillian.protocol.jmx.JMXMethodExecutor.invoke(JMXMethodExecutor.java:91)
at org.jboss.arquillian.impl.handler.ContainerTestExecuter.callback(ContainerTestExecuter.java:50)
at org.jboss.arquillian.impl.handler.ContainerTestExecuter.callback(ContainerTestExecuter.java:40)
at org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:63)
at org.jboss.arquillian.impl.context.AbstractEventContext.fire(AbstractEventContext.java:115)
at org.jboss.arquillian.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:160)
at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:247)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:210)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.jboss.arquillian.junit.Arquillian$5$1.evaluate(Arquillian.java:228)
at org.jboss.arquillian.junit.Arquillian$MultiStatementExecutor.execute(Arquillian.java:300)
at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:224)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:166)
at org.jboss.arquillian.junit.Arquillian$3$1.evaluate(Arquillian.java:189)
at org.jboss.arquillian.junit.Arquillian$MultiStatementExecutor.execute(Arquillian.java:300)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:185)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:128)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:120)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:103)
at org.apache.maven.surefire.Surefire.run(Surefire.java:169)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:339)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1011)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.modules.Module.run(Module.java:244)
at org.jboss.modules.Main.main(Main.java:178)
Caused by: java.lang.RuntimeException: Could not get Deployment
at org.jboss.arquillian.impl.DeploymentAnnotationArchiveGenerator.generateApplicationArchive(DeploymentAnnotationArchiveGenerator.java:65)
at org.jboss.arquillian.impl.ClientDeploymentGenerator.generate(ClientDeploymentGenerator.java:60)
at org.jboss.arquillian.impl.handler.ArchiveGenerator.callback(ArchiveGenerator.java:52)
at org.jboss.arquillian.impl.handler.ArchiveGenerator.callback(ArchiveGenerator.java:42)
at org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:63)
... 69 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.impl.DeploymentAnnotationArchiveGenerator.generateApplicationArchive(DeploymentAnnotationArchiveGenerator.java:57)
... 73 more
Caused by: java.lang.RuntimeException: Error handling file /content/messaging-example.jar/org/jboss/as/test/modular/utils
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handleArchiveByFile(URLPackageScanner.java:165)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:181)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.scanPackage(URLPackageScanner.java:132)
at org.jboss.shrinkwrap.impl.base.container.ContainerBase.addPackages(ContainerBase.java:1003)
at org.jboss.shrinkwrap.impl.base.container.ContainerBase.addClasses(ContainerBase.java:914)
at org.jboss.shrinkwrap.impl.base.container.ContainerBase.addClass(ContainerBase.java:855)
at org.jboss.as.test.modular.utils.ShrinkWrapUtils.addClasses(ShrinkWrapUtils.java:147)
at org.jboss.as.test.modular.utils.ShrinkWrapUtils.createJavaArchive(ShrinkWrapUtils.java:52)
at org.jboss.as.test.embedded.demos.messaging.MessagingTestCase.createDeployment(MessagingTestCase.java:76)
... 78 more
Caused by: java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:114)
at java.util.zip.ZipFile.<init>(ZipFile.java:131)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handleArchiveByFile(URLPackageScanner.java:149)
... 86 more
15 years, 1 month
"Read" operations
by Brian Stansberry
Kabir,
A couple more comments re: [1] following the discussion in #jboss-as7:
1) Instead of or in addition to the READ_ATTRIBUTE_OF_TYPE op, I was
looking for something like:
{
"op" => "read-children-names",
"op-addr" => [
("profile" => "production")
],
"child-type" => "subsystem"
}
which would then return a list of the names of all subsystems.
2) Assume people are going to have to type some of these a lot, so let's
find short names for these operations:
a) public static final String READ_ATTRIBUTES_OF_TYPE_OPERATION =
"read-attributes-of-type-operation";
"read-attributes-of-type" if the behavior remains the same, else
"read-children-names"
b) public static final String READ_NAMED_ATTRIBUTE_OPERATION =
"read-named-attribute-operation";
"read-attribute"
c) public static final String READ_NODE_DESCRIPTION_OPERATION =
"read-node-description-operation";
"read-resource-description"
d) public static final String READ_OPERATION_OPERATION =
"read-operation-operation";
"read-operation-description"
e) public static final String READ_OPERATIONS_SUMMARY_OPERATION =
"read-operations-summary-operation";
"read-operation-names"
f) public static final String READ_SUB_MODEL_OPERATION =
"read-sub-model-operation";
"read"
For this last one, we could add a required=false "attribute" param, make
the existing "recursive" property required=false, and collapse b) and f)
into a single operation named "read". WDYT?
I have a desire to replace "read" with "get" in all of the above, but
that may be too many years of Java development talking.
[1]
https://github.com/kabir/jboss-as/commit/2fa26198246f0d07b0e48c95dea6728a...
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
15 years, 1 month
AS7 console, RHQ
by Heiko Braun
I was looking at the proposal my alter ego send to this list a couple of weeks ago:
http://www.rhq-project.org/display/RHQ/AS7+console
What I don't understand is, why should there be an interim layer between the AS7 management API's
(configuration, deployment, etc) and the web-UI?
As described, management of the domain model would be another plugin to the RHQ container,
equivalent to any other plugin, like the JMX and HornetQ plugins.
I was expecting that any subsystem (i.e. hornetq) would be directly interfacing the AS7 management API's (domain model, deployment, etc). What's the purpose of having another intermediary layer like the plugin container?
I am trying get a better understanding how all the pieces fit together, especially bearing in mind that we have an
"embedded console" legacy and that AS7 products will be managed by JON, somewhere upstream in the product chain.
On a first glance I did assume that any subsystem directly interfaces the new API's that are currently fleshed out. Instead of retrofit existing plugins on the new API. But maybe that's because I don't see the big picture, especially how this integrates with JON later on. But is this an actual requirement? I guess it all boils down to the question what API customers should get to see, when they want to extend the management capabilities or integrate with it? Will it it be the RHQ plugin API or the new AS7 management API?
Why RHQ in the first place? How does it relate to JON?
An alternative would be: AS7 Management API <-> REST interface <-> Web-UI.
What are the benefits, drawbacks of each approach?
Ike
(formerly know as Heiko Braun, in order to avoid confusion)
15 years, 1 month
Standalone Server: Domain Model
by Heiko Braun
Referring to:
https://community.jboss.org/wiki/DomainManagementModelDesign
"Internally, the object model representing the domain configuration for a standalone server may be quite similar to that shown above. However, the XML configuration schema and perhaps the management API will be simplified to remove extraneous concepts like the ServerGroup. (Whether creating a distinct management API for this use case is appropriate needs discussion. A separate API means clients like JON and the embedded console need to be coded against two APIs in order to cover all use cases.)"
Creating to API's doesn't make sense at all. Instead we should try to collapse the concepts when used standalone. I.e. by referencing a default server group "standalone".
What domain model concepts can you think of that don't match the standalone scenario?
Ike
15 years, 1 month
Integration of managed components (projects)
by Heiko Braun
I need some clarification on this one:
http://community.jboss.org/wiki/DomainRequirements
It says:
"31. Projects must have an internal management API, and not be directly dependent on JMX for their management API.
32. Projects must maintain a management API wrapper over their internal management API.
This is an integration requirement."
- What does management API wrapper mean in this case?
- What's the association between the domain and a managed component?
- How do they interface each other (i.e. notification of state changes)?
Ike
15 years, 1 month