November 2007 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: BSH script from client

by adrian＠jboss.org

You need to change varia/build.xml such that it creates a structure like bsh.deployer/ bsh.deployer/META-INF/bsh-deployers-beans.xml bsh.deployer/bsh-deployer.jar Then update build/buid-distr such that this directory structure is copied into server/{all|default}/deployers View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102887#4102887 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102887

18 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Deployment.types not propagated

by adrian＠jboss.org

You're doing it wrong. :-) The types shouldn't even be on the deployment (I agreed this with Scott before) but it obviously hasn't been removed from the api yet. :-) The types should be part of the ManagedObject stuff for the profile service such that the console can sort the deployments into categories. Instead, you should add a marker into the attachments of the deployment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102881#4102881 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102881

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: BSH script from client

by alesj

We still need to port the actual deployer structure to <server-configruation>/deployers/bsh.deployer - META-INF/bsh-deployers-beans.xml - bsh-deployer.jar How does this - bsh-deployer.xml + coresponding lib - get into current AS build? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102868#4102868 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102868

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: BSH script from client

by alesj

I've created a separate bean shell client bean - LegacyBeanShellScriptClient. Its usage in bsh-deployers-beans.xml is currently commented. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102863#4102863 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102863

18 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Deployment.types not propagated

by thomas.diesler＠jboss.com

| [tdiesler@tddell trunk]$ ant -Dtest=org.jboss.test.ws.jaxws.jbws1762.packaged_jar_ejb3.Iteration1TestCase one-test | | Caused by: java.lang.IllegalStateException: Endpoint already registered: jboss.ws:context=jaxws-jbws1762-packaged,endpoint=EJB3Bean | at org.jboss.wsf.framework.management.DefaultEndpointRegistry.register(DefaultEndpointRegistry.java:89) | at org.jboss.wsf.framework.management.ManagedEndpointRegistry.register(ManagedEndpointRegistry.java:59) | at org.jboss.wsf.framework.deployment.EndpointRegistryDeploymentAspect.create(EndpointRegistryDeploymentAspect.java:46) | at org.jboss.wsf.framework.deployment.DeploymentAspectManagerImpl.deploy(DeploymentAspectManagerImpl.java:115) | at org.jboss.wsf.container.jboss50.ArchiveDeployerHook.deploy(ArchiveDeployerHook.java:95) | at org.jboss.wsf.container.jboss50.AbstractWebServiceDeployer.deploy(AbstractWebServiceDeployer.java:63) | The WebAppDeploymentAspect adds a type string like this | org.jboss.deployers.client.spi.Deployment deployment = createDeployment(warURL); | | // Mark the deployment as generated web app | // so the JSE deployer hook can ignore it | Set<String> types = deployment.getTypes(); | if (types == null) | { | types = new HashSet<String>(); | deployment.setTypes(types); | } | types.add(WebAppDesciptorModifier.PROPERTY_GENERATED_WEBAPP); | During deployment of the above using this code | public boolean isWebServiceDeployment(DeploymentUnit unit) | { | JBossWebMetaData webMetaData = unit.getAttachment(JBossWebMetaData.class); | boolean isGenerated = unit.getTypes().contains(WebAppDesciptorModifier.PROPERTY_GENERATED_WEBAPP); | return isGenerated == false && webMetaData != null; | } | isGenerated is always false. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102859#4102859 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102859

18 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Stable branch vs trunk?

by timfox

Also - and this critical - *please, please* make sure the merge history is updated when you do a merge: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingMergingActivity I notice that not everyone is doing this! You know who you are :) If you don't update this page it just screws it for the next person when they come to do a merge and end up re-merging the same stuff. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102847#4102847 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102847

18 years, 5 months

1
0
0 / 0

[QA of JBoss Portal] - JIRA update

by julien＠jboss.com

Thomas and myself discussed last week briefly about how to manage JIRA for the modules, my initial idea was to create one JIRA per module but it has drawbacks (mainly to create redundancy). Thomas suggested we could try to use the same JIRA but create versions per module x release, so we are going to try that for a while and see how it works. It has the benefit of being doable easily. I think the main cost we will pay in the increase of the complexity but it can be manageable somehow. So I have created the following versions: Common-1.0 Web-1.0 Identity-1.0 Portlet-1.0 and marked them as "released", they are just used as identifier for the "affect" version field. and I have also created: Common-1.0.1 Web-1.0.1 Identity-1.0.1 Portlet-1.0.1 Common-1.1 Web-1.1 Identity-1.1 Portlet-1.1 That can be used for "Affect" and "Fix" version fields. Any issue that matches a module version could also match a 2.6.x versions. For instance if there is a bug in common that it is fixed in 1.0.1 and 2.6.3. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102846#4102846 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102846

18 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Extension of the Designer

by magro1202

Hi everyone does anybody know how i can access the jpdl-3.2 xsd Schema file within the Designer at runtime? During Development the Schema files are located in a Folder named "schemas" but after Export as plugin the schema files aren't in the package. So where does the processdefinition find the right schema? regards Matthias View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102843#4102843 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102843

18 years, 5 months

1
0
0 / 0

[Design of JBoss Portal] - Security problem? ActiveDirectory users can login with blank

by marco.sarti

JBoss Portal 2.6.2-GA configured as described in: http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigurePortalForMicrosoftActiv... I have installed the Portal and I'm developing a portlet where LDAP/AD authentication/authorization is required. Unfortunately I have observed a very, very big problem using the ldap_identity-config: when the password field in login form is empty the module authenticates any user that exists in Active Directory, exactly as the right password was supplied. I have created a new issue on JIRA: http://jira.jboss.com/jira/browse/JBPORTAL-1785 Any suggestion? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102841#4102841 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102841

18 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: New Build Artifact - EJB3 External API

by wolfc

The current @Cache should not be in ext-api. Maybe we'll keep the construct in core. So for a bean developer we get either: @Cache("NoPassivationCache") or @CacheFactory("NoPassivationCache") By making the CacheFactoryRegistry a generic interface: interface CacheFactoryRegistry<T> { | CacheFactory<T> getFactory(String name); | } We can have typesafety in the core. On a related note: we still need something to pass in the cache configuration. interface CacheFactory<T> { | Cache<T> createCache(AnnotedElement element); | } I don't like it that we have two different @CacheConfig annotations. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102836#4102836 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102836

18 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2007