[JBoss ESB Development] - Naming for webservice endpoints
by Keith Babo
Keith Babo [http://community.jboss.org/people/kcbabo] created the discussion
"Naming for webservice endpoints"
To view the discussion, visit: http://community.jboss.org/message/559658#559658
--------------------------------------------------------------
Would like to get some community input on how we reference webservice endpoints in JBossWS from JBoss ESB configuration. Today, SOAPProcessor and SOAPProxy can be configured with the name of webservice endpoint hosted in JBoss WS in the following manner:
+*SOAPProcessor*+
+*SOAPProxy*+
Magesh is about to fix an https://jira.jboss.org/browse/JBESB-3420 issue with SOAPProcessor that will produce the following configuration change for SOAPProcessor:
The new jbossws-context property (optional and thus backward compatible) will allow JBossWS endpoints to be uniquely identified by using the combination of context and endpoint name.
David, Magesh, and I had a discussion last week around whether the SOAPProxy configuration should be updated to use a simplified syntax. The following was thrown out as an example:
<property name="wsdl" value="jbossws://foo:HelloWorldWS"/>
The idea being that the above configuration value is easier to type and parse for humans (eliminates the boilerplate ObjectName syntax). The question we have for the community is whether this would be desirable. Is this configuration a pain point today? Would changing it make the action significantly easier to use? Your feedback is very much appreciated.
Cheers!
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/559658#559658]
Start a new discussion in JBoss ESB Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 11 months
[JBoss AS7 Development] - Thoughts on hot deployment
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] created the discussion
"Thoughts on hot deployment"
To view the discussion, visit: http://community.jboss.org/message/559651#559651
--------------------------------------------------------------
Some thoughts on hot deployment support for further discussion (summarizing some thoughts from David, Jason, John, Jesper, all mistakes are my own)
First, terminology: what's being discussed here is hot-deploy in the traditional AS sense of detecting deployment archive changes and redeploying. It's not things like replacing classes in a running application. I assume though we want to support the exploded web archive resource (including jsp file) replacement we've traditionally supported (unless the JBW say otherwise).
Hot deploy support will be limited to the standalone server use case. Hot deployment will not be supported via the Domain Controller; users should use the regular deployment API.
*For zipped archives*:
Scanner will detect an archive in the hot-deploy dir, e.g. hot-deploy/foo.war. Scanner will use the same https://community.jboss.org/thread/155937?tstart=0 deployment API that an external client would use to register the content with the server and deploy it. Once the content is registered the server will maintain it's own copy in an internal directory (e.g. server/data/deployments). Scanner will replace the hot-deploy/foo.war file with a simple marker file hot-deploy/foo.war.deployed.
User can trigger a redeploy of the existing foo.war content by touching hot-deploy/foo.war.deployed.
User can trigger an undeploy of foo.war by deleting hot-deploy/foo.war.deployed.
User can trigger a replacement of foo.war (undeploy old, deploy new) by copying a new foo.war into hot-deploy/
*For exploded archives*:
User can copy an exploded archive into hot-deploy/ (e.g. hot-deploy/foo.war/) but this will not trigger a deployment.
It will trigger an INFO level message in the log noting that the exploded archive has been detected.
To trigger a deployment user must copy a marker file jboss.deploy to META-INF.
So, user can copy a large deployment without worrying that it will be deployed when only partly copied.
User can trigger a redeploy of the existing foo.war content by touching hot-deploy/foo.war/META-INF/jboss-deploy
User can trigger an undeploy of foo.war by deleting hot-deploy/foo.war/META-INF/jboss-deploy
+Undeploy by deleting the entire hot-deploy/foo.war/ directory is not supported!+ The user should delete hot-deploy/foo.war/META-INF/jboss-deploy to trigger undeploy, after which they can delete the entire directory if they so choose. If they leave the directory, that will not result in risk of another deploy (e.g. after server restart), since the META-INF/jboss-deploy won't be there.
Users can replace content in the exploded archive (e.g. hot-deploy/foo.war/index.html). We need to clarify exactly what the results of this will be; e.g. whether we support the current AS 6 behavior, something more, something less...
If we support something like the AS 6 behavior where some content changes are reflected in the runtime without a redeploy, the Scanner will be responsible to informing the server of the new content. It will do this via a separate internal API, not the regular end-user deployment API. If we end up adding methods needed for updating content without redeploy to the regular end-user deployment API, or to some other end-user API, the scanner should use that API. But we will not add methods to an end-user API solely to support scanner operations.
The current assumption is the scanner will tell the server to mount the exploded archive directly from the hot-deploy dir, rather than copying it. But that is an internal implementation detail subject to change.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/559651#559651]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 11 months
Re: [jboss-dev-forums] [JBoss AS7 Development] - AS 7 Deployment APIs
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] replied to the discussion
"AS 7 Deployment APIs"
To view the discussion, visit: http://community.jboss.org/message/559648#559648
--------------------------------------------------------------
Some discussion on deployment names.
Right now we have a "name" and a sha1 hash. But it seems we really need 3 things:
1) A common name. This would be the file name (if the content was presented as a file). This becomes the default value for an EE application name (and the EE module name for non-EAR EE archives).
2) An internal unique name. This is used internally, and allows the DC for example, to distinguish between two versions of the same archive. We can use the sha1 hash for this, although I think we shouldn't call it "sha1", since that ties us to a particular implementation choice.
3) An external (i.e. end-user) unique name. This is the name the end user uses to refer to the deployment in the API. This by default would be the same as 1). However, if the end user wanted two different foo.ear's active within the same domain, they could assign a different external unique name to one or both of them. The foo.ear common name is still needed for both so they have the expected EE application name.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/559648#559648]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 11 months
[EJB Development] - Client wont connect to remote interface of EJB
by Juan Camilo Prada
Juan Camilo Prada [http://community.jboss.org/people/juankprada] created the discussion
"Client wont connect to remote interface of EJB"
To view the discussion, visit: http://community.jboss.org/message/559641#559641
--------------------------------------------------------------
Hi guys, I'm really new to EJB and JEE in general.
So far im trying to make this EJB to work with no succes til now. I really dont know what is the problem. I'm following this book and I tried the examples and all works fine in a local server, but now, i deployed my beans to an external server, with a public IP, and I cant seem to get things work.
The Bean is this:
package server.ejb.gmail;
import javax.ejb.Stateless;
import com.google.gdata.data.appsforyourdomain.AppsForYourDomainException;
import com.google.gdata.client.appsforyourdomain.*;
import sample.appsforyourdomain.*;
@Stateless
public class GmailBean implements GmailBeanRemote, GmailBeanLocal {
public void ConexionGmail()
{
AppsForYourDomainClient client = null;
try {
client = new AppsForYourDomainClient("user(a)domain.com",
"password", "domain.com");
System.out.println("Hello world");
} catch (Exception e) {
System.out.println("Error conexion gmail:" + e.getMessage());
}
}
}
GmailBeanRemote looks like this:
package server.ejb.gmail;
import javax.ejb.Remote;
@Remote
public interface GmailBeanRemote {
public void ConexionGmail();
}
GmailBeanLocal is exactly like the remote counterpart, the only difference is the tag which uses @Local instead of @Remote
The client Im using is this:
package client.usuario;
import java.util.Properties;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.rmi.PortableRemoteObject;
import server.ejb.gmail.GmailBeanRemote;
import server.ejb.usuario.UsuarioBeanRemote;
public class CrearUsuario {
public static void main(String[] args) {
try {
Properties p = new Properties();
p.put(Context.INITIAL_CONTEXT_FACTORY,
"org.jnp.interfaces.NamingContextFactory");
p.put(Context.URL_PKG_PREFIXES,
"org.jboss.naming:org.jnp.interfaces");
p.put(Context.PROVIDER_URL, "jnp://myhost:1099");
Context ctx = new InitialContext(p);
Object ref = ctx.lookup("GmailBean/remote");
GmailBeanRemote ebr = (GmailBeanRemote) PortableRemoteObject.narrow(ref, GmailBeanRemote.class);
ebr.ConexionGmail();
} catch (NamingException e)
{
e.printStackTrace();
}
}
}
If there is any way the JNDI output is useful, here it is:
+- UserTransactionSessionFactory (proxy: $Proxy112 implements interface org.jboss.tm.usertx.interfaces.UserTransactionSessionFactory)
+- UUIDKeyGeneratorFactory (class: org.jboss.ejb.plugins.keygenerator.uuid.UUIDKeyGeneratorFactory)
+- HiLoKeyGeneratorFactory (class: org.jboss.ejb.plugins.keygenerator.hilo.HiLoKeyGeneratorFactory)
+- SecureDeploymentManager (class: org.jnp.interfaces.NamingContext)
| +- remote[link -> DeploymentManager] (class: javax.naming.LinkRef)
+- SecureManagementView (class: org.jnp.interfaces.NamingContext)
| +- remote[link -> ManagementView] (class: javax.naming.LinkRef)
+- DeploymentManager (class: org.jboss.aop.generatedproxies.AOPProxy$4)
+- UsuarioBean (class: org.jnp.interfaces.NamingContext)
| +- local (class: Proxy for: server.ejb.usuario.UsuarioBeanLocal)
| +- local-server.ejb.usuario.UsuarioBeanLocal (class: Proxy for: server.ejb.usuario.UsuarioBeanLocal)
| +- remote-server.ejb.usuario.UsuarioBeanRemote (class: Proxy for: server.ejb.usuario.UsuarioBeanRemote)
| +- remote (class: Proxy for: server.ejb.usuario.UsuarioBeanRemote)
+- XAConnectionFactory (class: org.hornetq.jms.client.HornetQConnectionFactory)
+- ProfileService (class: org.jboss.aop.generatedproxies.AOPProxy$2)
+- SecureProfileService (class: org.jnp.interfaces.NamingContext)
| +- remote[link -> ProfileService] (class: javax.naming.LinkRef)
+- queue (class: org.jnp.interfaces.NamingContext)
| +- DLQ (class: org.hornetq.jms.client.HornetQQueue)
| +- ExpiryQueue (class: org.hornetq.jms.client.HornetQQueue)
+- UserTransaction (class: org.jboss.tm.usertx.client.ClientUserTransaction)
+- ConnectionFactory (class: org.hornetq.jms.client.HornetQConnectionFactory)
+- jmx (class: org.jnp.interfaces.NamingContext)
| +- invoker (class: org.jnp.interfaces.NamingContext)
| | +- RMIAdaptor (class: javax.management.MBeanServerConnection)
| +- rmi (class: org.jnp.interfaces.NamingContext)
| | +- RMIAdaptor (class: javax.management.MBeanServerConnection)
+- ProxyFactory (class: org.jnp.interfaces.NamingContext)
| +- UsuarioUnico (class: org.jnp.interfaces.NamingContext)
| | +- UsuarioBean (class: org.jnp.interfaces.NamingContext)
| | | +- UsuarioBean (class: org.jnp.interfaces.NamingContext)
| | | | +- remote (proxy: $Proxy197 implements interface org.jboss.ejb3.proxy.impl.factory.session.SessionSpecProxyFactory,interface org.jboss.ejb3.proxy.impl.factory.session.SessionProxyFactory,interface org.jboss.ejb3.proxy.impl.factory.ProxyFactory)
| | +- GmailBean (class: org.jnp.interfaces.NamingContext)
| | | +- GmailBean (class: org.jnp.interfaces.NamingContext)
| | | | +- remote (proxy: $Proxy197 implements interface org.jboss.ejb3.proxy.impl.factory.session.SessionSpecProxyFactory,interface org.jboss.ejb3.proxy.impl.factory.session.SessionProxyFactory,interface org.jboss.ejb3.proxy.impl.factory.ProxyFactory)
+- BeanValidatorFactories (class: org.jnp.interfaces.NamingContext)
+- persistence.unit:unitName=#timerdb (class: org.hibernate.impl.SessionFactoryImpl)
+- TomcatAuthenticators (class: java.util.Properties)
+- GmailBean (class: org.jnp.interfaces.NamingContext)
| +- local (class: Proxy for: server.ejb.gmail.GmailBeanLocal)
| +- remote (class: Proxy for: server.ejb.gmail.GmailBeanRemote)
| +- local-server.ejb.gmail.GmailBeanLocal (class: Proxy for: server.ejb.gmail.GmailBeanLocal)
| +- remote-server.ejb.gmail.GmailBeanRemote (class: Proxy for: server.ejb.gmail.GmailBeanRemote)
+- XAThroughputConnectionFactory (class: org.hornetq.jms.client.HornetQConnectionFactory)
+- ManagementView (class: org.jboss.aop.generatedproxies.AOPProxy$3)
+- ThroughputConnectionFactory (class: org.hornetq.jms.client.HornetQConnectionFactory)
I dont know what to do to make it work, so any help would be really appreciated.
Thanks
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/559641#559641]
Start a new discussion in EJB Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 11 months