[Design of JBoss Web Services] - trouble deploying web service endpoint
by scooter4j
We have a web services app that is currently running on Oracle App Server (boo, hiss). Checking out what would be necessary to migrate to JBoss. Using JBoss 4.2.2GA for test. I've modified all the appropriate descriptor files as far as I know, created a Service Endpoint Interface, set things up to expose the endpoint as an ejb and deployed... I get the following error:
15:53:12,326 WARN [verifier] EJB spec violation:
Bean : WSEntrySE
Method : public abstract RequestWS; getRequests(String, String, RequestCriteriaWS) throws RemoteException
Section: 7.11.59
Warning: No warning message found, please file a Bug report.
Note that I've looked at the spec (EJB 2.1) and I don't see a section 7.11.59. I'm stumped here b/c there is no information other than that shown above... we are migrating from ejb2.0, so I don't know if there is some issue related to that....
help??
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4148023#4148023
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4148023
16 years, 7 months
[Design of JBoss ESB] - Re: Maven ESB plugin
by Andre1001
Hi Tom/Beve,
I've been trying to automate some ESB tests with Maven.
Questions:
- There seems to be two Maven plugins which package .esb files (jboss-maven-plugin and jboss-packaging-maven-plugin). Which one is the "official"?
- How do you guys automate deploy and undeploy by JMX? I've been trying with the following pom, but without sucess. Harddeploy works, but just copy the package to /deploy directory.
pom.xml
<plugin>
| <groupId>org.codehaus.mojo</groupId>
| <artifactId>jboss-maven-plugin</artifactId>
| <version>1.3.1</version>
| <executions>
| <execution>
| <id>undeploy</id>
| <phase>clean</phase>
| <goals>
| <goal>undeploy</goal>
| </goals>
| </execution>
| <execution>
| <id>harddeploy</id>
| <phase>package</phase>
| <goals>
| <goal>harddeploy</goal>
| </goals>
| </execution>
| </executions>
| <configuration>
| <jbossHome>${user.home}/java/jboss-4.2.0.GA</jbossHome>
| <serverName>default</serverName>
| <hostName>localhost</hostName>
| <port>8080</port>
| <deployUrlPath>
| <![CDATA[/jmx-console/HtmlAdaptor?action=invokeOpByName&name=jboss.system:service%3DMainDeployer&methodName=deploy&argType=java.net.URL&arg0=]]>
| </deployUrlPath>
| <undeployUrlPath>
| <![CDATA[/jmx-console/HtmlAdaptor?action=invokeOpByName&name=jboss.system:service%3DMainDeployer&methodName=undeploy&argType=java.net.URL&arg0=]]>
| </undeployUrlPath>
| <fileName>${project.build.directory}/${project.build.finalName}.esb</fileName>
| </configuration>
| </plugin>
terminal
[asalvati@localhost EntradaNotas]$ mvn -e jboss:undeploy
| + Error stacktraces are turned on.
| [INFO] Scanning for projects...
| [INFO] Searching repository for plugin with prefix: 'jboss'.
| [INFO] ------------------------------------------------------------------------
| [INFO] Building EntradaNotas
| [INFO] task-segment: [jboss:undeploy]
| [INFO] ------------------------------------------------------------------------
| [INFO] [jboss:undeploy]
| [INFO] Undeploying /home/asalvati/java/workspace/EntradaNotas/target/EntradaNotas-1.0-SNAPSHOT.esb from JBoss.
| [INFO] No server specified for authentication - using defaults
| [INFO] ------------------------------------------------------------------------
| [INFO] BUILD SUCCESSFUL
| [INFO] ------------------------------------------------------------------------
| [INFO] Total time: < 1 second
| [INFO] Finished at: Wed Apr 30 17:58:46 GMT-05:00 2008
| [INFO] Final Memory: 4M/53M
| [INFO] ------------------------------------------------------------------------
| [asalvati@localhost EntradaNotas]$
|
|
Thanks.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4148015#4148015
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4148015
16 years, 7 months
[Design of EJB 3.0] - Re: WS EJB invocation
by scott.stark＠jboss.org
"heiko.braun(a)jboss.com" wrote :
| Currently we use the MC kernel todo a lookup by name, which uses the legacy ObjectName.
|
Ok, are we comfortable as that as the lookup mechanism? We can make sure its available on the JBossEnterpriseBeanMetaData.
"heiko.braun(a)jboss.com" wrote :
| anonymous wrote :
| | DeploymentScope.getEjbContainer(String ejbLink, Class businessIntf, String vfsContext) works for the ejb-name.
| |
|
| Does this mean I can simply use the ejb-name for ejb-link and thus resolve the corresponding container? If that's the case, then I am all set.
That is what could be used now, but the problem with resolving the name is that its not unique. If for a given ejb deployment, you use its local ejb-names this will just work.
What I also proposed was ensuring the container name was made available on the JBossEnterpriseBeanMetaData, and DeploymentScope would support lookup of the EJBContainer by that name.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147999#4147999
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4147999
16 years, 7 months
[Design of JBoss Internal Benchmarking] - While starting JBOSS 5.0 unable to createMBean for jboss err
by pbmmohan
16:31:19,718 INFO [ServerInfo] Java VM: Java HotSpot(TM) Server VM 10.0-b19,Sun
Microsystems Inc.
16:31:19,718 INFO [ServerInfo] OS-System: Windows XP 5.1,x86
16:31:19,812 INFO [JMXKernel] Legacy JMX core initialized
16:31:25,812 ERROR [AbstractKernelController] Error installing to Instantiated:
name=jboss:service=AttributePersistenceService state=Described mode=Manual requi
redState=Configured
org.jboss.deployment.DeploymentException: Unable to createMBean for jboss:servic
e=AttributePersistenceService
at org.jboss.deployment.DeploymentException.rethrowAsDeploymentException
(DeploymentException.java:52)
at org.jboss.system.ServiceCreator.install(ServiceCreator.java:141)
at org.jboss.system.microcontainer.InstantiateAction.installAction(Insta
ntiateAction.java:45)
at org.jboss.system.microcontainer.InstantiateAction.installAction(Insta
ntiateAction.java:37)
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.sim
pleInstallAction(SimpleControllerContextAction.java:62)
at org.jboss.dependency.plugins.action.AccessControllerContextAction.ins
tall(AccessControllerContextAction.java:71)
at org.jboss.dependency.plugins.AbstractControllerContextActions.install
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147997#4147997
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4147997
16 years, 7 months
[Design of AOP on JBoss (Aspects/JBoss)] - Re: Classloading problems with ClassProxyFactory
by jason.greene＠jboss.com
The proxy CL approach is just creating a new simple classloader (could just be a URLClassLoader for example) for every source class' classloader (that is of course reused for other classes in the same classloader as the source class). These proxy classloaders would be associated with the lifespan of AOP, and anything using the proxies. So, for example, if AOP is undeployed, all generated proxies can and should be collected. If you start generating classes in a system classloader (or in the case of juliens recommendation the ext class loader), then these proxies will only go away when the JVM restarts.
I was doing a similar thing a few years ago (generating proxies that needed to be associated with a (possible) isolated deployment. I ran into an issue with the old jboss repository class loader, and its use of black lists. For awhile I detected them and flushed the bls using its api. I also later on had a problem with another thirdparty CL (can't remember which lib did this) that also ignored classes generated from defineClass. The solution I ended up using was the approach I describe above (although I did not use/need a registry since I generated classes only once, and at the start of a deployment).
I found the forum post where I discussed the issue with Scott, and he had mentioned that the end-goal was for aop to use a special repository for generated classes. To be honest, I haven't reviewed the new JBoss Classloader architecture yet, so not sure where things are right now:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986381
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147976#4147976
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4147976
16 years, 7 months
[Design of EJB 3.0] - Re: WS EJB invocation
by scott.stark＠jboss.org
"heiko.braun(a)jboss.com" wrote : For me the easiest would be to publish the ObjectName with DeploymentUnit attachments using a fixed property name that's part of the WS SPI.
|
| ...
| Looking closer makes me think that the best place would be JBossEnterpriseBeanMetaData.
|
Using an ObjectName certainly makes no sense. We don't even know if there is going to be a jmx view in the future. Its certainly not the api for invoking on the container.
Identifying the endpoints at the JBossEnterpriseBeanMetaData and on the servlet side, the JBossWebMetaData/JBossServletMetaData is what makes sense.
You would still need an api to get hold of the container to invoke on for the given ejb-name, servlet-name though. The DeploymentScope.getEjbContainer(String ejbLink, Class businessIntf, String vfsContext) works for the ejb-name. The businessIntf is just for fallback if known, but is not needed.
We can just add a method DeploymentScope.getEjbContainer(String containerName) and make the container name come from the getContainerName/setContainerName on the JBossEnterpriseBeanMetaData.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147975#4147975
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4147975
16 years, 7 months