[JBoss JIRA] Created: (JBWS-2382) Fix JBossWS deployers processing
by Richard Opalka (JIRA)
Fix JBossWS deployers processing
--------------------------------
Key: JBWS-2382
URL: https://jira.jboss.org/jira/browse/JBWS-2382
Project: JBoss Web Services
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: jbossws-cxf, jbossws-metro, jbossws-native
Affects Versions: jbossws-cxf-3.0.4, jbossws-metro-3.0.4, jbossws-native-3.0.4, jbossws-cxf-3.0.3
Reporter: Richard Opalka
Assignee: Richard Opalka
Fix For: jbossws-native-3.0.5, jbossws-metro-3.0.5, jbossws-cxf-3.0.5
In general all your processing in the deployers should just be based on metadata
available to deployers or configuration on the deployers.
You shouldn't be looking at any services.
e.g. suppose the war had a dependency on an ejb from some other application
then its not going to be started until that ejb exists regardless of when jbossweb.sar
gets started.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months
[JBoss JIRA] Created: (JBWS-2370) Ensure correct JBossWS startup if there are Webservice archived in deploy directory during JBossAS bootstrap
by Richard Opalka (JIRA)
Ensure correct JBossWS startup if there are Webservice archived in deploy directory during JBossAS bootstrap
------------------------------------------------------------------------------------------------------------
Key: JBWS-2370
URL: https://jira.jboss.org/jira/browse/JBWS-2370
Project: JBoss Web Services
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: jbossws-cxf, jbossws-metro, jbossws-native
Affects Versions: jbossws-cxf-3.0.4, jbossws-metro-3.0.4, jbossws-native-3.0.4
Reporter: Richard Opalka
Assignee: Richard Opalka
Fix For: jbossws-native-3.0.5, jbossws-metro-3.0.5, jbossws-cxf-3.0.5
During deployment of the endpoints declared in my wars a call is made to AbstractServerConfig.getConnectorPort(). This fetches the WS Server MBean and tries to lookup objects of type "jboss.web:type=Connector,*". At the point where the lookup fails the jboss.web MBean has only one entry for the WebServer.
In the run that I managed to debug the type=Connector entries were added at a later point. So, some of the subsequent calls to getConnectorPort() succeeded and also the AS bootstrap did not hang. I was unable to debug a case where the bootstrap did hang.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months
[JBoss JIRA] Created: (JBWS-2521) Refactor / rewrite ServiceObjectFactory
by Alessio Soldano (JIRA)
Refactor / rewrite ServiceObjectFactory
---------------------------------------
Key: JBWS-2521
URL: https://jira.jboss.org/jira/browse/JBWS-2521
Project: JBoss Web Services
Issue Type: Task
Security Level: Public (Everyone can see)
Components: jbossws-cxf
Reporter: Alessio Soldano
Fix For: jbossws-cxf-3.1.1
The jbossws-cxf ServiceObjectFactory needs to be cleaned:
- Bus retrieval: this is currently performed through reflection on the Service class and following cast to cxf ServiceImpl; leveraging the BusFactory should be enough to get the default bus that is used by the cxf ProviderImpl for every Service creation
- ServiceRef stub properties setup: this is currently performed through reflection on Service class to get the ServiceDelegate and then chaning the ServiceDelegate instance at runtime with a custom onesetting the properties. Instead of doing this hack, we should evaluate leveraging the CXF configuration for runtime constructed objects (http://cwiki.apache.org/CXF20DOC/configuration-of-runtime-constructed-obj...). IOW cxf ServiceImpl looks for a bean named portName.toString() + ".jaxws-client.proxyFactory" to configure the JaxWsProxyFactoryBean used to build the port and that factory bean allows for setting the stub properties. We might be able to generate on the fly and supply a bean configuration to the cxf bus for having our stub properties automatically configured by the already existing cxf configuration system.
- perhaps even the handler chain configuration can be achieved in a way similar to the described in the previous point.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months
[JBoss JIRA] Created: (JBWS-2346) Issue with SAAJ API: SOAPBody.getElementsByTagNameNS() appears non-recursive
by David Boeren (JIRA)
Issue with SAAJ API: SOAPBody.getElementsByTagNameNS() appears non-recursive
----------------------------------------------------------------------------
Key: JBWS-2346
URL: https://jira.jboss.org/jira/browse/JBWS-2346
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-native
Affects Versions: jbossws-native-3.0.3
Reporter: David Boeren
We are trying to migrate our application into JBOSS 4.3EAP, perviously my webservice application was using Sun's saaj api. During the migration, we have been decided to use JBoss SAAJ api and we are seeing some weird problem with an API in SOAPBody class.
Here is the sample code:
NodeList list = soapMessage.getSOAPBody().getElementsByTagNameNS("urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0", "AdhocQueryResponse");
System.out.println(list.getLength());
list = soapMessage.getSOAPBody().getElementsByTagNameNS("urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0", "ExtrinsicObject");
System.out.println(list.getLength());
The first call to getElementsByTagNameNS() was returning the element list, but the subsequent call was returning an empty nodelist. I am attaching a sample java project created to reproduce the problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months
[JBoss JIRA] Created: (JBWS-2527) BeanFactory not initialized or already closed - call 'refresh' before accessing beans via the ApplicationContext
by Alessio Soldano (JIRA)
BeanFactory not initialized or already closed - call 'refresh' before accessing beans via the ApplicationContext
----------------------------------------------------------------------------------------------------------------
Key: JBWS-2527
URL: https://jira.jboss.org/jira/browse/JBWS-2527
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-cxf
Reporter: Alessio Soldano
Fix For: jbossws-cxf-3.1.0
02-11-2009 11:10:32: SVR-ERROR: java.lang.IllegalStateException: BeanFactory not initialized or already closed - call 'refresh' before accessing beans via the ApplicationContext
at org.springframework.context.support.AbstractRefreshableApplicationContext.getBeanFactory(AbstractRefreshableApplicationContext.java:121)
at org.springframework.context.support.AbstractApplicationContext.containsBean(AbstractApplicationContext.java:765)
at org.apache.cxf.configuration.spring.ConfigurerImpl.configureBean(ConfigurerImpl.java:118)
at org.apache.cxf.jaxws.ServiceImpl.configureObject(ServiceImpl.java:513)
at org.apache.cxf.jaxws.ServiceImpl.createPort(ServiceImpl.java:429)
at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:292)
at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:287)
at org.jboss.wsf.stack.cxf.client.ServiceRefStubPropertyServiceDelegate.getPort(ServiceRefStubPropertyServiceDelegate.java:172)
at javax.xml.ws.Service.getPort(Service.java:44)
at com.sun.ts.tests.jaxws.api.javax_xml_ws.Endpoint.Client.getPortJavaEE(Client.java:111)
at com.sun.ts.tests.jaxws.api.javax_xml_ws.Endpoint.Client.setup(Client.java:189)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 10 months
[JBoss JIRA] Created: (JBWS-2284) Using WSConsume on JBOSS 4.2.3.GA and JDK 1.6.0_07 leads to java.lang.NoClassDefFoundError: com/sun/tools/ws/wscompile/WsimportTool
by Hemant Satam (JIRA)
Using WSConsume on JBOSS 4.2.3.GA and JDK 1.6.0_07 leads to java.lang.NoClassDefFoundError: com/sun/tools/ws/wscompile/WsimportTool
-----------------------------------------------------------------------------------------------------------------------------------
Key: JBWS-2284
URL: https://jira.jboss.org/jira/browse/JBWS-2284
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: JBOSS 4.2.3.GA
JDK 1.6.0_07
Windows
Reporter: Hemant Satam
I have all the required files in jboss-4.2.3.GA\lib\endorsed. The classpath also ensures that jboss libraries are before jdk1.6 lib file. However on access of wsconsume the error produced is;
JBossWS-Native stack deployed
Exception in thread "main" java.lang.NoClassDefFoundError: com/sun/tools/ws/wscompile/WsimportTool
at org.jboss.ws.tools.jaxws.impl.SunRIConsumerFactoryImpl.createConsumer(SunRIConsumerFact
oryImpl.java:36)
at org.jboss.wsf.spi.tools.WSContractConsumer.newInstance(WSContractConsumer.java:73)
at org.jboss.wsf.spi.tools.WSContractConsumer.newInstance(WSContractConsumer.java:56)
at org.jboss.wsf.spi.tools.cmd.WSConsume.importServices(WSConsume.java:195)
at org.jboss.wsf.spi.tools.cmd.WSConsume.main(WSConsume.java:81)
Caused by: java.lang.ClassNotFoundException: com.sun.tools.ws.wscompile.WsimportTool
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
... 5 more
Is this a bug or something wrong that I am doing?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 10 months
[JBoss JIRA] Created: (JBWS-2413) WSDLPublisher fails when trying to publish include schemas that contain relative paths
by Alvaro (JIRA)
WSDLPublisher fails when trying to publish include schemas that contain relative paths
--------------------------------------------------------------------------------------
Key: JBWS-2413
URL: https://jira.jboss.org/jira/browse/JBWS-2413
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-native
Affects Versions: jbossws-native-3.0.4
Environment: OS: Windows Vista Business SP1
Java: 1.5 build 16
JBossWS: 3.0.4
JBossAS: 4.2.3
Reporter: Alvaro
When trying to deploy an EJB3 with a WebService endpoint and the property wsdlLocation set, the WSDLPublisher fails to publish schema imports if they contain relative paths.
For example, in the method "publishSchemaImports", if the variable "resourcePath" used in the statement "URL resourceURL = dep.getMetaDataFileURL(resourcePath);" resolves to "META-INF/wsdl/schemas/NE2006/multicacheschemas/../coreschemas/infrastructureRoot.xsd", there will be a java.io.FileNotFoundExeception is thrown:
org.jboss.ws.WSException: Cannot publish wsdl to: G:\Servidores\jboss-4.2.3.GA\server\default\data\wsdl\hl7-service-patient-administration-0.0.1-SNAPSHOT.jar\PRPA_AR101001UV01
.wsdl
at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishWsdlFiles(WSDLFilePublisher.java:149)
at org.jboss.wsf.stack.jbws.PublishContractDeploymentAspect.start(PublishContractDeploymentAspect.java:51)
at org.jboss.wsf.framework.deployment.DeploymentAspectManagerImpl.start(DeploymentAspectManagerImpl.java:144)
at org.jboss.wsf.container.jboss42.LazyAssemblyWSFRuntime.start(LazyAssemblyWSFRuntime.java:66)
at org.jboss.wsf.container.jboss42.AbstractDeployerHookEJB.deploy(AbstractDeployerHookEJB.java:50)
at org.jboss.wsf.container.jboss42.DeployerInterceptor.start(DeployerInterceptor.java:88)
at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.start(SubDeployerInterceptorSupport.java:188)
at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:95)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy34.start(Unknown Source)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy9.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:304)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
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:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
at org.jboss.Main.boot(Main.java:200)
at org.jboss.Main$1.run(Main.java:508)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.io.IOException: Cannot get URL for: META-INF/wsdl/schemas/NE2006/multicacheschemas/../coreschemas/infrastructureRoot.xsd
at org.jboss.wsf.common.URLLoaderAdapter.findChild(URLLoaderAdapter.java:103)
at org.jboss.wsf.framework.deployment.ArchiveDeploymentImpl.getMetaDataFileURL(ArchiveDeploymentImpl.java:97)
at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishSchemaImports(WSDLFilePublisher.java:274)
at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishSchemaImports(WSDLFilePublisher.java:297)
at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishSchemaImports(WSDLFilePublisher.java:303)
at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishSchemaImports(WSDLFilePublisher.java:303)
at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishWsdlFiles(WSDLFilePublisher.java:136)
... 79 more
If we replace the "resourcePath" with the canonical form, this error disappears.
As a solution, I've replaced the following code:
private void publishSchemaImports(URL parentURL, Element element, List<String> published) throws Exception
{
....
while (it.hasNext())
{
....
URL xsdURL = new URL(baseURI.substring(0, baseURI.lastIndexOf("/") + 1) + schemaLocation);
File targetFile = new File(xsdURL.getPath());
targetFile.getParentFile().mkdirs();
String deploymentName = dep.getCanonicalName();
// get the resource path including the separator
int index = baseURI.indexOf(deploymentName) + 1;
String resourcePath = baseURI.substring(index + deploymentName.length());
//check for sub-directories
resourcePath = resourcePath.substring(0, resourcePath.lastIndexOf("/") + 1);
resourcePath = expLocation + resourcePath + schemaLocation;
while (resourcePath.indexOf("//") != -1)
{
resourcePath = resourcePath.replace("//", "/");
}
URL resourceURL = dep.getMetaDataFileURL(resourcePath);
.....
}
....
}
with this one:
private void publishSchemaImports(URL parentURL, Element element, List<String> published) throws Exception
{
....
while (it.hasNext())
{
....
URL xsdURL = new URL(baseURI.substring(0, baseURI.lastIndexOf("/") + 1) + schemaLocation);
File targetFile = new File(xsdURL.getPath());
targetFile.getParentFile().mkdirs();
String deploymentName = dep.getCanonicalName();
// get the resource path including the separator
int index = baseURI.indexOf(deploymentName) + 1;
String resourcePath = baseURI.substring(index + deploymentName.length());
//check for sub-directories
resourcePath = resourcePath.substring(0, resourcePath.lastIndexOf("/") + 1);
resourcePath = expLocation + resourcePath + schemaLocation;
URI resourceURI = new URI(resourcePath);
URI resourceURI2 = resourceURI.resolve("");
resourcePath = resourceURI2.toString()+resourceURI2.relativize(resourceURI).toString();
URL resourceURL = dep.getMetaDataFileURL(resourcePath);
...
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 11 months
[JBoss JIRA] Created: (JBWS-2528) Missing parameterOrder in portType/operation
by Alessio Soldano (JIRA)
Missing parameterOrder in portType/operation
--------------------------------------------
Key: JBWS-2528
URL: https://jira.jboss.org/jira/browse/JBWS-2528
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-cxf
Reporter: Alessio Soldano
Fix For: jbossws-cxf-3.1.1
The cxf java2wsdl seems to fail in generating the wsdl portType/operation element in some cases where soapHeader and IN/OUT parameters are used at the same time. This was revealed by the webparam3 reverse test configuration in the jws tck5 module.
In that case we have
<wsdl:portType name="webParam3WebService">
<wsdl:operation name="hello3">
<wsdl:input name="hello3" message="tns:hello3">
</wsdl:input>
...
instead of
<wsdl:portType name="webParam3WebService">
<wsdl:operation name="hello3" parameterOrder="id Name Employee">
<wsdl:input name="hello3" message="tns:hello3">
</wsdl:input>
...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 11 months