May 2008 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: Multiple parsing implementation in RARDeployer

by alesj

"vickyk" wrote : I have noticed that the init(..) does not get called in the parse(..) implemetations of AbstractVFSParsingDeployer , here is the code | For merge where you have different metadata types, the original init cannot be called - its signature only matches parser's output type. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154580#4154580 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154580

16 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Annotation Tests in deployers-vfs

by alesj

"adrian(a)jboss.org" wrote : Of course you need a way to handle duplicate names but that should be | known by the processor. Can I add? | DeploymentUnit::getComponent(String name) --> DeploymentUnit | To ease up on component iteration regarding code duplication. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154578#4154578 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154578

16 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Annotation Tests in deployers-vfs

by alesj

"adrian(a)jboss.org" wrote : | Iteration and delegation, {insert explitive here :-) } | | | for (BeanMetaData bfb : bfBeans) | | { | | KernelDeploymentDeployer.addBeanComponent(unit, bfb); | | | | Who knows what happens when addBeanComponent throws an error? | Why do we treat component failure on deploy (AbstractComponentDeployer) | try | { | deployComponents(unit); | } | catch (Throwable t) | { | undeployComponents(unit); | throw DeploymentException.rethrowAsDeploymentException("Error deploying: " + unit.getName(), t); | } | differently then in AbstractRealDeployerWithInput | List<T> visited = new ArrayList(); | try | { | Set<? extends T> deployments = unit.getAllMetaData(getInput()); | for (T deployment : deployments) | { | visitor.deploy(unit, deployment); | visited.add(deployment); | } | } | catch (Throwable t) | { | for (int i = visited.size()-1; i >= 0; --i) | { | try | { | visitor.undeploy(unit, visited.get(i)); | } | catch (Throwable ignored) | { | log.warn("Error during undeploy: " + unit.getName(), ignored); | } | } | throw DeploymentException.rethrowAsDeploymentException("Error deploying: " + unit.getName(), t); | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154576#4154576 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154576

16 years, 7 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Exception propagation using HTTP servlet transport on 1.

by martinschweigert

Another problem, if you are updating jboss-remoting the jbossall-client.jar does not contain the "ServletThrowable" in JBoss 4.2.2GA... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154575#4154575 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154575

16 years, 7 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Exception propagation using HTTP servlet transport on 1.

by martinschweigert

Sorry, sorry, I did not see the second page... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154573#4154573 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154573

16 years, 7 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Exception propagation using HTTP servlet transport on 1.

by martinschweigert

| <mbean code="org.jboss.remoting.transport.Connector" | name="jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3"> | <depends>jboss.aop:service=AspectDeployer</depends> |  | | | <attribute name="Configuration"> | <config> | | <invoker transport="servlet"> | <attribute name="serverBindAddress">${http.rmi.host}</attribute> | <attribute name="serverBindPort">${http.rmi.port}</attribute> | <attribute name="path">servlet-invoker/ServerInvokerServlet</attribute> | <attribute name="return-exception" isParam="true">true</attribute> | </invoker> | <handlers> | <handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler> | </handlers> | </config> | </attribute> | </mbean> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154572#4154572 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154572

16 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Multiple parsing implementation in RARDeployer

by vickyk

I have noticed that the init(..) does not get called in the parse(..) implemetations of AbstractVFSParsingDeployer , here is the code | @Override | protected T parse(DeploymentUnit unit, String name, String suffix, T root) throws Exception | { | // Should we include the deployment | // The infrastructure will only check leafs anyway so no need to check here | if (name == null && isIncludeDeploymentFile()) | name = unit.getName(); | | // Try to find the metadata | VFSDeploymentUnit vfsDeploymentUnit = (VFSDeploymentUnit) unit; | List<VirtualFile> files = vfsDeploymentUnit.getMetaDataFiles(name, suffix); | | if (files.size() == 0) | { | return null; | } | else if (files.size() > 1) | { | return handleMultipleFiles(vfsDeploymentUnit, root, files); | } | else | { | VirtualFile file = (VirtualFile) unit.getAttachment(getOutput().getName() + ".altDD"); | if(file == null) | file = files.get(0); | | T result = parse(vfsDeploymentUnit, file, root); | if (result != null) | init(vfsDeploymentUnit, result, file); | return result; | } | } | | protected T parse(DeploymentUnit unit, Set<String> names, String suffix, T root) throws Exception | { | if (names == null || names.isEmpty()) | throw new IllegalArgumentException("Null or empty names."); | | VFSDeploymentUnit vfsDeploymentUnit = (VFSDeploymentUnit)unit; | | List<VirtualFile> files = new ArrayList<VirtualFile>(); | Set<String> missingFiles = new HashSet<String>(); | | for (String name : names) | { | List<VirtualFile> matched = vfsDeploymentUnit.getMetaDataFiles(name, suffix); | if (matched != null && matched.isEmpty() == false) | files.addAll(matched); | else | missingFiles.add(name); | } | | if (missingFiles.size() == names.size()) | return null; | | return mergeFiles(vfsDeploymentUnit, root, files, missingFiles); | } | | So if I am am overriding some functionality in the Deployer implementation of type MultipleObjectModelFactoryDeployer , the init(..) does not kick in . I have a hack to get the MetaData processing out from the init() and place in the mergeMetaData(...) but I wanted to make sure that the flow of the parse(..) is ok . Ales you need to check this . Here is the hack protected RARDeploymentMetaData mergeMetaData(VFSDeploymentUnit unit, Map<Class<?>, List<Object>> metadata) throws Exception | { | RARDeploymentMetaData deployment = new RARDeploymentMetaData(); | | // Getting the List of MetaData Objects | List<Object> cmdInstances = metadata.get(ConnectorMetaData.class); | if(cmdInstances != null && !cmdInstances.isEmpty()) | deployment.setConnectorMetaData(ConnectorMetaData.class.cast(cmdInstances.get(0))); | | List<Object> jmdInstances = metadata.get(JBossRAMetaData.class); | if(jmdInstances != null && !jmdInstances.isEmpty()) | deployment.setRaXmlMetaData(JBossRAMetaData.class.cast(jmdInstances.get(0))); | | // This is moved from the init() , got to verify if this in not a HACK ..... | /* | VFSDeploymentUnit parent = unit.getParent(); | String name = unit.getSimpleName(); | if( parent != null ) | name = parent.getSimpleName() + "#" + name; | System.out.println("--------> name -->"+name); | metaDataRepository.addConnectorMetaData(name, deployment.getConnectorMetaData()); | */ | // Check if this is hack. | | return deployment; | } The actual code which was part of the init(..) is @Override | protected void init(VFSDeploymentUnit unit, RARDeploymentMetaData rdmd, VirtualFile file) throws Exception | { | ConnectorMetaData cmd = rdmd.getConnectorMetaData(); | cmd.setURL(file.toURL()); | VFSDeploymentUnit parent = unit.getParent(); | String name = unit.getSimpleName(); | if( parent != null ) | name = parent.getSimpleName() + "#" + name; | metaDataRepository.addConnectorMetaData(name, cmd); | } | Right now I am not able to call cmd.setURL(file.toURL()); within the mergeMetaData(...) , I think I should be getting the VirtualFile reference from the VirtualDeploymentUnit. I am look at this . The URL set in the ConnectorMetaData is being used in the RARDeployment at here protected void startService() throws Exception | { | URL url = cmd.getURL(); | if (cmd.getLicense().getRequired()) | { | //log.info ("Required license terms exist, view " + ServerConfigUtil.shortUrlFromServerHome(url.toString())); | log.debug("License terms full URL: " + url); | } | //resourceAdapter = ResourceAdapterFactory.createResourceAdapter(cmd); | resourceAdapter = ResourceAdapterFactory.createResourceAdapter(rdmd); | resourceAdapter.start(this); | } Please note that url.toString() is yielding the NPE as it is not being set in RARParserDeployer . View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154570#4154570 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154570

16 years, 7 months

1
0
0 / 0

[Design of JBoss ESB] - Re: How to disable redelivery for sync message call?

by Kevin.Conner＠jboss.com

It depends on the version of JBossESB you are using. If you are using CP1 of the SOA Platform or ESB 4.3.GA then you can do one of the following to cause an exception to be thrown instead of retrying the delivery. Per message: set the property org.jboss.soa.esb.exceptionOnDeliverFailure on the message to 'true' Global: set the same property in jbossesb-properties.xml "core" to "true" The task covering this work is http://jira.jboss.com/jira/browse/JBESB-1556 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154563#4154563 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154563

16 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: Controlling deployments via a barrier bean

by alesj

"scott.stark(a)jboss.org" wrote : | To properly handle this we would need the ability to expand the states for the component in question to allow for alternate DESCRIBE, DESCRIBE_CLUSTERED, DESCRIBE_SINGLETON states depending on the cluster metadata associated with the bean. Currently the mc state machine does not allow for this choice type of state transition. I have not worked much with the lower level state manipulation so I could also be talking out of my ass, but I think this is the proper way to do it. | This could be achieved. OK, it would still depend on exactly what you wanted to do - no cyclic/fork states. You can do this atm. Add these two new states (DESCRIBE_CLUSTERED, DESCRIBE_SINGLETON) to Controller. Then when you install a bean that would use any of those two states, you need to push him your own ControllerContextActions impl. e.g. our alias handling | Map<ControllerState, ControllerContextAction> map = Collections.<ControllerState, ControllerContextAction>singletonMap(ControllerState.INSTALLED, new AliasControllerContextAction()); | ControllerContextActions actions = new AbstractControllerContextActions(map); | install(new AliasControllerContext(alias, original, actions)); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154547#4154547 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154547

16 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: VFS and directory handling

by alesj

"scott.stark(a)jboss.org" wrote : | Isn't the PersistenceUnitRootUrl always pointing to the contents containing the persistence-info.xml so that there really never is any navigation of ZipInputStreams within ZipInputStreams? | Yes. It should be / it is pointing to the module (jar or 'exploded' jar directory) that contains that persistence.xml. So, I'm probably reading your quote wrong ""scott.stark(a)jboss.org" wrote : | A nested jar should simply be seen as a JarInputStream. | If by that you mean that URL of nested jar should return JIS, then we're almost there - we return ZIS. Dunno if this is related, but I remember having problems finding MANIFEST.MF file if the IS impl in nested jar handling was JIS, instead of ZIS. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154537#4154537 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154537

16 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums May 2008