[JBoss Web Services] - Servlet.service() for servlet jsp threw exception
by juan pablo
juan pablo [http://community.jboss.org/people/jplistero] created the discussion
"Servlet.service() for servlet jsp threw exception"
To view the discussion, visit: http://community.jboss.org/message/550007#550007
--------------------------------------------------------------
Hi all,
I have a client soap web service with ws-security ...My problem is when I call for second time the code of the client, throw this exception (First time works perfect). I ' am using Jboss 4.0.5 + jdk 6, some jars for jbossws-native for the client soap.
My Client code ...
* System.setProperty("org.jboss.ws.wsse.keyStore", "/datos/store/keystore.jks");*
* System.setProperty("org.jboss.ws.wsse.keyStorePassword", "12345");
*
* System.setProperty("org.jboss.ws.wsse.keyStoreType", "jks");*
* System.setProperty("org.jboss.ws.wsse.trustStore", "/datos/store/client.trustore");*
* System.setProperty("org.jboss.ws.wsse.trustStorePassword", "123456");*
* System.setProperty("org.jboss.ws.wsse.trustStoreType", "jks"); *
*Service service = new Service();
*
*Port port = service.getServicePort(); // <--- frezee here!*
*((StubExt) port).setConfigName("Standard WSSecurity Client");*
[[jsp]] Servlet.service() for servlet jsp threw exception
java.lang.NoSuchMethodError: javax.xml.parsers.DocumentBuilderFactory.newInstance(Ljava/lang/String;Ljava/lang/ClassLoader;)Ljavax/xml/parsers/DocumentBuilderFactory;
at org.jboss.wsf.common.DOMUtils$1.initialValue(DOMUtils.java:106)
at org.jboss.wsf.common.DOMUtils$1.initialValue(DOMUtils.java:86)
at java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:141)
at java.lang.ThreadLocal.get(ThreadLocal.java:131)
at org.jboss.wsf.common.DOMUtils.getDocumentBuilder(DOMUtils.java:187)
at org.jboss.wsf.common.DOMUtils.parse(DOMUtils.java:212)
at org.jboss.ws.metadata.config.JBossWSConfigFactory.getNamespaceURI(JBossWSConfigFactory.java:128)
at org.jboss.ws.metadata.config.JBossWSConfigFactory.parse(JBossWSConfigFactory.java:82)
at org.jboss.ws.metadata.config.JBossWSConfigFactory.getConfig(JBossWSConfigFactory.java:151)
at org.jboss.ws.metadata.umdm.EndpointMetaData.initEndpointConfigMetaData(EndpointMetaData.java:923)
at org.jboss.ws.metadata.umdm.EndpointMetaData.initEndpointConfig(EndpointMetaData.java:899)
at org.jboss.ws.metadata.builder.jaxws.JAXWSClientMetaDataBuilder.rebuildEndpointMetaData(JAXWSClientMetaDataBuilder.java:300)
at org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.getPortInternal(ServiceDelegateImpl.java:234)
at org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.getPort(ServiceDelegateImpl.java:543)
at javax.xml.ws.Service.getPort(Service.java:92)
any idea to fix this ?
thanks a lot!
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/550007#550007]
Start a new discussion in JBoss Web Services at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 10 months
Re: [jboss-user] [JBoss Messaging] - Does the JBM bridge uses a connection pool?
by arjan tijms
arjan tijms [http://community.jboss.org/people/atijms] replied to the discussion
"Does the JBM bridge uses a connection pool?"
To view the discussion, visit: http://community.jboss.org/message/549953#549953
--------------------------------------------------------------
> henk de boer wrote:
>
> According to an article written by Tim Fox ( http://community.jboss.org/wiki/ShouldIcacheJMSconnectionsandJMSsessions http://community.jboss.org/wiki/ShouldIcacheJMSconnectionsandJMSsessions) my performance "+*will suck*"+, if I don't use a connection pool.
I was struggeling with the same thing, and as it appears the Bridge doesn't use a connection pool, but uses a different kind of pattern so it actually doesn't really need one. This pattern is not unlike e.g. a request queue for AJAX requests in JSF 2 and RichFaces, where instead of letting each part of the code sent something on its own (with or without a connection pool), all requests are collected in a single queue and sent out in batches by a single thread.
In fact, in our own software I have implemented the exact same pattern. We have tens to hundreds of small write requests per second, and originally we let each thread where the write request originated write to a DB directly. Of course there was a connection pool in between (for JDBC these are actually easy and actually work ;) ). This didn't scale very well, even though a connection pool was thus used.
So I rebuild the architecture to let all threads post their write requests to a single queue, which is read by 3 threads having a single fixed connection each to the DB, via which they sent the write requests in batches. (in case of many cores in both the client and DB and having sufficiently fast storage in the DB, we found 3 consumers for this queue to work more optimally than 1).
I scanned through the org.jboss.jms.server.bridge.Bridge code and found it basically does the following (omitting details about xa/non-xa, username/no username, etc):
1. Get source and target destinations from JNDI
2. Get source connection factory from JNDI1. Create connection
2. Create session
3. Create consumer(sourceDestination)
3. Get target connection factory from (remote) JNDI1. Create connection
2. Create session
3. Create producer(null)
4. consumer.setMessageListener(SourceListener)
5. SourceListener onMessage:1. Get global lock
2. Put message in list
3. If batch size reached1. For each message in list1. producer.send(targetDestination, message)
That's basically it. Apart from a very small hack to optimize forward_mode_xa if the source is jboss messaging, it's all just the pure and simple JMS API that's being used by the bridge. No JBoss internal magic and no JCA pools for remote connections.
Nevertheless, even in this case where the bridge uses a single fixed connection, it might be handy to have a connection pool anyway. Namely, such a pool could take care of validating that connections are still valid and destroy a connection and reconnect if needed.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/549953#549953]
Start a new discussion in JBoss Messaging at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 10 months
[JBoss Microcontainer Development] - Weld - pull from MC
by Kabir Khan
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] created the discussion
"Weld - pull from MC"
To view the discussion, visit: http://community.jboss.org/message/549944#549944
--------------------------------------------------------------
I have experimented with an alternate implementation of the weld-mc integration as discussed in Boston. I still need to write more tests but wanted to let the Weld guys know where I am at.
The idea is to "pull" data from the MC in special cases, which is different from the "push" we do at the moment for MC beans annotated with @WeldEnabled. I had a look at using the InjectionServices interface, but this has the following problems:
-It does not get triggered when calling constructors
-If using a separate @McInject annotation instead of @Inject to do injection the annotated field does not appear in invocation context's injection points meaning all the fields etc. need to be parsed from invocation context's target's class (I am not sure if the target will always be non-null?)
-If using the @Inject annotation with an additional @Mc annotation (to look up the particular injection point in the MC) falls over when calling proceed(), also again a problem is that you need to iterate over all fields etc. to look for the members. This also fails in the validation phase.
As mentioned the ability to do this injection from MC is something that most Weld applications would not want to do. What I have locally now is an extra service that can handle this:
package org.jboss.temp.weld.spi;
import java.lang.annotation.Annotation;
import java.util.Iterator;
import org.jboss.weld.bootstrap.api.Service;
public interface ExternalLookupRegistryService extends Service
{
Iterable<ExternalLookup<?>> getExternalLookups();
void addExternalLookup(ExternalLookup<?> externalLookup);
boolean removeExternalLookup(Class<? extends Annotation> clazz);
}
And then a service to handle particular annotations
package org.jboss.temp.weld.spi;
import java.lang.annotation.Annotation;
import java.lang.reflect.Type;
import java.util.Set;
public interface ExternalLookup<T extends Annotation>
{
Class<T> getAnnotation();
boolean isValid(Type type, Set<Annotation> qualifiers);
Object lookupValue(Type type, Set<Annotation> qualifiers);
}
I'm hoping to be able to push these interfaces into the main spi, the temp location I am using is just while playing.
Then I have modified the Validator and Field-/ParameterInjectionPoint to look for this service when validating/injecting:
> [kabir ~/sourcecontrol/weld/core/subversion]
> $svn diff impl/src/main/java/org/jboss/weld/bootstrap/Validator.java
> Index: impl/src/main/java/org/jboss/weld/bootstrap/Validator.java
> ===================================================================
> --- impl/src/main/java/org/jboss/weld/bootstrap/Validator.java (revision 6577)
> +++ impl/src/main/java/org/jboss/weld/bootstrap/Validator.java (working copy)
> @@ -83,6 +83,8 @@
> import javax.inject.Scope;
>
> import org.jboss.interceptor.model.InterceptionModel;
> +import org.jboss.temp.weld.spi.ExternalLookup;
> +import org.jboss.temp.weld.spi.ExternalLookupRegistryService;
> import org.jboss.weld.bean.AbstractClassBean;
> import org.jboss.weld.bean.AbstractProducerBean;
> import org.jboss.weld.bean.DisposalMethod;
> @@ -288,6 +290,16 @@
> Set<?> resolvedBeans = beanManager.getBeanResolver().resolve(beanManager.getBeans(ij));
> if (!isInjectionPointSatisfied(ij, resolvedBeans, beanManager))
> {
> + ExternalLookupRegistryService service = beanManager.getServices().get(ExternalLookupRegistryService.class);
> + if (service != null)
> + {
> + for (ExternalLookup<?> lookup : service.getExternalLookups())
> + {
> + if (ij.getAnnotated().isAnnotationPresent(lookup.getAnnotation()))
> + if (lookup.isValid(ij.getType(), ij.getQualifiers()))
> + return;
> + }
> + }
> throw new DeploymentException(INJECTION_POINT_HAS_UNSATISFIED_DEPENDENCIES, ij, Arrays.toString(bindings));
> }
> if (resolvedBeans.size() > 1 && !ij.isDelegate())
>
>
>
> [kabir ~/sourcecontrol/weld/core/subversion]
> $svn diff impl/src/main/java/org/jboss/weld/injection/
> Index: impl/src/main/java/org/jboss/weld/injection/FieldInjectionPoint.java
> ===================================================================
> --- impl/src/main/java/org/jboss/weld/injection/FieldInjectionPoint.java (revision 6577)
> +++ impl/src/main/java/org/jboss/weld/injection/FieldInjectionPoint.java (working copy)
> @@ -36,6 +36,8 @@
> import javax.inject.Inject;
>
> import org.jboss.interceptor.util.InterceptionUtils;
> +import org.jboss.temp.weld.spi.ExternalLookup;
> +import org.jboss.temp.weld.spi.ExternalLookupRegistryService;
> import org.jboss.weld.exceptions.IllegalStateException;
> import org.jboss.weld.exceptions.InvalidObjectException;
> import org.jboss.weld.introspector.ForwardingWeldField;
> @@ -114,7 +116,23 @@
> // if declaringInstance is a proxy, unwrap it
> instanceToInject = InterceptionUtils.getRawInstance(declaringInstance);
> }
> - delegate().set(instanceToInject, manager.getInjectableReference(this, creationalContext));
> +
> + Object value = null;
> + ExternalLookupRegistryService service = manager.getServices().get(ExternalLookupRegistryService.class);
> + if (service != null)
> + {
> + for (ExternalLookup<?> lookup : service.getExternalLookups())
> + {
> + if (getAnnotation(lookup.getAnnotation()) != null)
> + value = lookup.lookupValue(getBaseType(), getQualifiers());
> + }
> + }
> +
> + if (value == null)
> + value = manager.getInjectableReference(this, creationalContext);
> +
> +
> + delegate().set(instanceToInject, value);
> }
> catch (IllegalArgumentException e)
> {
> Index: impl/src/main/java/org/jboss/weld/injection/ParameterInjectionPoint.java
> ===================================================================
> --- impl/src/main/java/org/jboss/weld/injection/ParameterInjectionPoint.java (revision 6577)
> +++ impl/src/main/java/org/jboss/weld/injection/ParameterInjectionPoint.java (working copy)
> @@ -35,6 +35,8 @@
> import javax.enterprise.inject.spi.Bean;
> import javax.enterprise.inject.spi.Decorator;
>
> +import org.jboss.temp.weld.spi.ExternalLookup;
> +import org.jboss.temp.weld.spi.ExternalLookupRegistryService;
> import org.jboss.weld.exceptions.IllegalStateException;
> import org.jboss.weld.exceptions.InvalidObjectException;
> import org.jboss.weld.exceptions.UnsupportedOperationException;
> @@ -119,6 +121,15 @@
> @SuppressWarnings("unchecked")
> public T getValueToInject(BeanManagerImpl manager, CreationalContext<?> creationalContext)
> {
> + ExternalLookupRegistryService service = manager.getServices().get(ExternalLookupRegistryService.class);
> + if (service != null)
> + {
> + for (ExternalLookup<?> lookup : service.getExternalLookups())
> + {
> + if (getAnnotation(lookup.getAnnotation()) != null)
> + return (T)lookup.lookupValue(getBaseType(), getQualifiers());
> + }
> + }
> return (T) manager.getInjectableReference(this, creationalContext);
> }
In my test I have this implementation of the service classes
public class TestExternalLookup implements ExternalLookup<External>
{
@Override
public boolean isValid(Type type, Set<Annotation> qualifiers)
{
if (type == Bar.class)
return true;
return false;
}
@Override
public Class<External> getAnnotation()
{
return External.class;
}
@Override
public Object lookupValue(Type type, Set<Annotation> qualifiers)
{
if (type == Bar.class)
return new BarImpl();
return null;
}
}
public class TestExternalLookupRegistryService implements ExternalLookupRegistryService
{
private Map<Class<? extends Annotation>, ExternalLookup<?>> lookups = Collections.synchronizedMap(new HashMap<Class<? extends Annotation>, ExternalLookup<?>>());
public void addExternalLookup(ExternalLookup<?> externalLookup)
{
lookups.put(externalLookup.getAnnotation(), externalLookup);
}
public Iterable<ExternalLookup<?>> getExternalLookups()
{
synchronized (lookups)
{
return new HashSet<ExternalLookup<?>>(lookups.values());
}
}
public boolean removeExternalLookup(Class<? extends Annotation> clazz)
{
return lookups.remove(clazz) != null;
}
public void cleanup()
{
lookups.clear();
}
}
I register this service with the deployment and add the TestExternalLookup to it, meaning that when I create an instance of ExternalConstructorInjected the constructor parameter is found in TestExternalLookup.
public class ExternalConstructorInjected
{
Bar bar;
@Inject
public ExternalConstructorInjected(@External Bar bar)
{
this.bar = bar;
}
}
I think Pete is on vacation, so after adding a few more tests I'll add this to a branch somewhere so that it can be included once he okays it.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/549944#549944]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 10 months
