jboss-dev-forums — The jboss development forum posts

[Jboss-dev-forums] [Design of JBoss/Tomcat Integration] - EJB3/Jboss/Remote Tomcat

[LordKaos <nu...@jb...>]

Does anyone know how to correctly package an EJB3 entity bean so that I can return an entity bean from a call to a session bean, to a remote Tomcat session?

I keep getting a ClassCastException in the way I am doing it now - though if I leave the return as an Object, then I can retrieve the data using Java reflection, so the data is clearly getting across.

For example:

I have a session bean with a function like:

public Account findAccountById(int id) {
       Account a = (Account)manager.find(Account.class, id);
} 

I.e. returning an instance of the entity bean "Account"

And then from Tomcat I call it like:

AccountServices service = (AccountServices) context.lookup(AccountServices.class.getName());
Account a = service.findAccountById(id); 


But this gives me:

java.lang.ClassCastException: db.mapping.Account
at $Proxy0.findAccountById(Unknown Source)
at web.AccountMAController.showAccountSummary(AccountMAController.java:43)


I have heard mentions of a packaging issue here, but no one seems to know what the problem is.

At the moment, I am including my entity beans in a .jar file within the tomcat/shared/lib directory - is this wrong?  

Any ideas would be greatly appreciated.

Cheers,
Alex.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880557#3880557

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880557

[Jboss-dev-forums] [Design of JBoss Profiler] - Jboss with only Stateless Session Bean : Memory leak problem

[Bala <nu...@jb...>]

Hi

we am using jboss 3.2.3 with only stateless Session Bean.   Whenever we 
re-started the server our application is  working in some good speed but after  4 to 5 hrs of execution our server started slowing down.  I think the reason for this is some kind of memory leak in jboss.. 

pls suggest me if any one had experience similar to this

tks
Bala


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880554#3880554

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880554

[Jboss-dev-forums] [Design of JBoss Portal] - Re: Encoding charset problem in client browser for RC2

[caigao <nu...@jb...>]

Thank you for your reply, ju...@jb....

Mybe my english is not so good, my expression is sometimes not so clearly. I am so sorry.

After my test, it is both error in database chars and cms files after edit it.

In database chars come from jbp_users and jbp_forums chars

i have checked hsqldb i think it is wrong char utf8 converting like this:
content in database.log

  | INSERT INTO JBP_USERS VALUES(1,1,'admin','\u00b9\u00dc\u00c0\u00ed\u00d4\u00b1','\u00d1\u00ee','21232f297a57a5a743894a0e4a801fc3','ad...@po...',NULL,'2005-06-07 09:22:50.684',TRUE,TRUE)
  | 

it should be

  | INSERT INTO JBP_USERS VALUES(1,1,'admin','\u7ba1\u7406\u5458','\u6768','21232f297a57a5a743894a0e4a801fc3','ad...@po...',NULL,'2005-06-07 09:22:50.684',TRUE,TRUE)
  | 

the attached image shows the errors.

[img]http://www.emig.cn/encodingerr.jpg[/img]
http://www.emig.cn/encodingerr.jpg


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880540#3880540

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880540

[Jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re: A single AspectFactory across multiple Aspects?

[flaviarnn <nu...@jb...>]

Hi, Neil,
I think meta data could do the trick, but there is a simpler way.
Your aspect factory could implement the org.jboss.util.xml.XmlLoadable interface.
This interface contains the method 
public void importXml(org.w3c.dom.Element element)
If you do this, JBoss AOP will call this method after instatiating your Aspect Factory, passing as argument the xml element used to declare your aspect factory in the jboss-aop.xml file.
This way, your jboss-aop.xml  could look like this:

  | <aspect name="Aspect1" class "my.aspect1l" factory="MyJBossAOPFactory" scope="PER_CLASS">
  |  <anyTagy>Aspect1</anyTag>
  | </aspect>
  | <aspect name="Aspect2" class "my.aspect2" factory="MyJBossAOPFactory" scope="PER_CLASS">
  | <anyTag>Aspect2</anyTag>
  | </aspect>
  | 
And your MyJBossAOPFactory.importXml method could retrieve the "anyTag" contents in order to determine the aspect context (i.e. the class).

Regards
Flavia

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880539#3880539

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880539

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: JBoss Bean Deployer - JMX Integration

[<sco...@jb...>]

I think we are still on topic target, its just a question of how the bean deployer is implementing the depends tag. Maybe I'm confusing the issue with the belief that the bean deployer already has a depends tag. That is what I am thinking and the question is one of making the jmx mc components available as dependencies targets in the bean deployers.

As you said, this has a straightforward impl if one uses the jmx mc component object name, and the bean deployer assumes valid jmx names refer to components in the jmx mc.

Beyond that is the question of mapping the jmx mc names into a non-jmx object name namespace for more natural pojo mc naming convention. Its a notion that has validity purely in the jmx mc as well given that there are more logical names/aliases for many services. 

For the not so logical names such as that assigned to an ejb local home or mdb deployment, there really is no natural name other than the existing ejb-name, but its far from being unique. I'm punting on this for now.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880537#3880537

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880537

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: JBoss Bean Deployer - JMX Integration

[<ad...@jb...>]

I'm not sure I follow, I think we have got a bit off-topic :-)

Certainly, I could make it a rule that if the depends or inject tag in the bean's xml
has a name that is a valid ObjectName, then it is assumed to
be a jmx dependency. This logic can be hidden away in the deployer/dependency
processing of JBoss4's BeanDeployer.

Whether we want to keep the jmx ObjectName as the namespace convention
down the road is a different issue. It does have some advantages in terms
of the flat namespace and querying, but it fails in its original intention of being a "logical"
name for the underlying object (which is probably partly a fault of the way we use it).

In many ways, querying on the real attribute/property values is probably better?

Like I expressed above, I don't think that just a name is necessarily the best/only way
to do this. Though using any other scheme will still require at least an internal unique "id".

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880536#3880536

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880536

[Jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Re: Deployment Enhancement - Custom Attribute handler

[<sco...@jb...>]

Use the code tag to encapsulate xml.

This looks like an extension to the existing attribute injection mechanism where instead of:


  |    <mbean code="org.jboss.test.jmx.proxy.ProxyTests"
  |           name="jboss.test:name=ProxyTestsAttribute">
  |       <depends optional-attribute-name="xxx"
  |               proxy-type="attribute">:name=ConfigService</depends>
  |    </mbean>
  | 

there is a key 

  |    <mbean code="org.jboss.test.jmx.proxy.ProxyTests"
  |           name="jboss.test:name=ProxyTestsAttribute">
  |       <depends optional-attribute-name="xxx" 
  |                proxy-type="attribute"
  |                handler="mydatahandler"
  |                key="some-key">:name=ConfigService</depends>
  |    </mbean>
  | 

where the handler knows how to extract the some-key value of type matching the attribute type from the dependency target.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880534#3880534

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880534

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: JBoss Bean Deployer - JMX Integration

[<sco...@jb...>]

So I'm not seeing why its not as simple as injecting an object name pattern matcher to the sar deployer that returns the string alias:


  | interface TheMinimalHackThing
  | {
  |    String mapObjectNameToAlias(ObjectName name);
  |    String getAlias(ObjectName name);
  |    ObjectName getObjectName(String alias);
  | }
  | 



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880532#3880532

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880532

[Jboss-dev-forums] [Design of JBoss Internal Benchmarking] - Re: FileBenchmarkReceiver Thread Model vs DatabaseBenchmarkR

[<cle...@jb...>]

I just converted everything to create a new thread as you created before. 
I placed it in an abstract class.  (AbstractBenchmarkReceiver)


Clebert Suconic

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880527#3880527

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880527

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: JBoss Bean Deployer - JMX Integration

[<ad...@jb...>]

"sco...@jb..." wrote : So what is the "minimiz(e) the kludges" approach? 

I don't know yet. 
If it was trivial, I probably wouldn't have mentioned the issue in the forums :-)

The issue is to spot that a dependency/injection is really an external dependency
outside the control of the bean MC and preprocess them into "depends"
to attach to the ServiceController registration, i.e. the wrapping container.

Anyway, we said we weren't going to worry too much about the JMX integration
for JBoss4 (at least in the initial release).

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880524#3880524

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880524

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: JBoss Bean Deployer - JMX Integration

[<sco...@jb...>]

So what is the "minimiz(e) the kludges" approach? 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880523#3880523

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880523

[Jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Deployment Enhancement - Custom Attribute handler

[<mik...@sy...>]

I was interested on whether or not the following enhancement request is of interest to others.

Problem.  Our application platform has a database for common configuration data.  It would be nice if there was some generic way to extend the \<attribute\> tag such that a custom handler could be invoked to get the data.

e.g. \<atttribute handler="mydatahandler" name="xxx"\>some-key\</attribute\>


In this case my custom handler, mydatahandler would use some-key to reference our configuration database, rather than treating it as a string literal.  This makes it much easier to manage site specific configuration data.

From an implementation standpoint, I was looking into whether or not I could use AOP as a means to intercept MBean provisioining and tag custom data with some unique string such as %% e.g.  so the intereceptor would see which attributes need to be handled specially.  While promising at first it seems like all of the access will typically be via reflection which is a bit of a pain for AOP.

Sorry about the \, was't sure how to escape the tags.

Any comments appreciated.

Thanks

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880522#3880522

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880522

[Jboss-dev-forums] [Design of JBoss Remoting, Unified Invokers] - Re: org.jboss.remoting.CannotConnectException (ejb3)

[<tom...@jb...>]

You will also need to add the following annotation to your bean:

  | @RemoteBinding(clientBindUrl="socket://[host]:[port]")
  | 
So an example from the ejb3 tutorial would be:

  | ...
  | @Stateful
  | @RemoteBinding(clientBindUrl="socket://66.56.72.34:3873")
  | public class ShoppingCartBean implements ShoppingCart, Serializable
  | {
  | ...
  | 
where the external address for my server is 66.56.72.34.  

In a future release of ejb3, this should not be required and should pick up the proper locator url as specified in the server (via the jboss-service.xml).  However, overriding the bind information for the client will always be allowed via the RemoteBinding annotation (if have a particular need for this).


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880515#3880515

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880515

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: JBoss Bean Deployer - JMX Integration

[<ad...@jb...>]

Yes, but as I said above, I want to "minimiz(e) the kludges".

This can be done by introducing something that is based on what we want
going forward (even if it is incomplete).

e.g. when I've integration the jmx/pojo MCs
the injection should be "transparent" between the two. The transaction manager
factory above, doesn't really know that it is using an MBeanProxy on the
TransactionManagerService.

The problem before that integration (jboss4) is that the lifecycles or
configuration spaces aren't linked, except that the whole bean deployment is
managed by an MBean known to the SARDeployer.

I can hack some things to make it work better, but it isn't going to work as well
as the real solution in JBoss5.
There is sort of cross over here, in that we still want the old loader-repository
config to work in JBoss5, even when the classloaders are part of the DI framework.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880514#3880514

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880514

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: JBoss Bean Deployer - JMX Integration

[<sco...@jb...>]

Ok, but we seem to be mixing legacy vs future naming issues. Just throwing an alias attribute onto the existing mbean would seem to ease integration of non-jmx based stuff into the jmx mc, and avoids the exposure of a jmx name dependency in the new bean deployer.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880510#3880510

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880510

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: JBoss Bean Deployer - JMX Integration

[<ad...@jb...>]

Yes, but surely all that does is introduce a binding to the new alias notion
rather than the ObjectName.

This might be useful for solving some problems like specifying the default datasource
(which already has an alias in that DefaultDS is already "hardwired" is some places)

To solve some other problems you would need to be able to specify an alias
based on some other name. e.g. automatically adding dependencies on
resource-refs based on jndi-name or ejb-refs based on ejb-name
i.e.

  | <depends type="ejb" name="MyEJB"/>
  | would resolve to
  | jboss.j2ee:service=EJB,jndiName=MyEJB
  | but this also depends upon context as well since MyEJB can exist in multiple
  | deployments.
  | 

I don't think adding a "trivial" alias notion would solve many problems,
and it would likely confuse some users. Users are confused enough
when the MBeans are created by deployers so they don't know what
names to use.

Instead, we should be working towards defining an
extensible dependency notion that understands context, type or anything
else that might be important.
This should produce something intuitive and allow users to "write their own
dependency" if nothing fits what they need.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880507#3880507

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880507

[Jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Deployment of JSP in JBOSS 4.0.2

[kollswe <nu...@jb...>]

Hello,

I have been trying to deploy a web application on JBOSS 4.0.2 with JSP and java activities. I am using jakarta struts-1.2.4 and javax.servlet.jar file in jre\lib\ext. 
I imported a class "com.khu.dto.HelpdeskDTO" in the JSP page as follows- 
<%@ page import="com.khu.dto.HelpdeskDTO" %>
BUT,

I get the following servlet error as shown from the log-

-----------------------------------------------------------------------------------
14:13:52,755 ERROR [[jsp]] Servlet.service() for servlet jsp threw exception
org.apache.jasper.JasperException: Unable to compile class for JSP

Generated servlet error:
Only a type can be imported. com.khu.dto.HelpdeskDTO resolves to a package

Generated servlet error:
Only a type can be imported. com.khu.cc.UserInfo resolves to a package

An error occurred at line: 16 in the jsp file: /jsps/helpdesk/HelpdeskRequest.jsp
Generated servlet error:
HelpdeskDTO cannot be resolved or is not a type

An error occurred at line: 16 in the jsp file: /jsps/helpdesk/HelpdeskRequest.jsp
Generated servlet error:
HelpdeskDTO cannot be resolved or is not a type


        at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:84)
        at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:328)
        at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:397)
        at org.apache.jasper.compiler.Compiler.compile(Compiler.java:288)
        at org.apache.jasper.compiler.Compiler.compile(Compiler.java:267)
        at org.apache.jasper.compiler.Compiler.compile(Compiler.java:255)
        at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:556)
        at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:293)
        at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
        at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
        at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574)
        at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
        at com.novell.afw.portlet.impl.PortletRequestDispatcherImpl.include(PortletRequestDispatcherImpl.java:139)
        at com.sssw.wf.xf.activity.EboJSPNode.doRender(EboJSPNode.java:121)
        at com.sssw.wf.xf.activity.EboRenderableNode.onRender(EboRenderableNode.java:105)
        at com.sssw.wf.xf.core.EboProcess.onRender(EboProcess.java:430)
        at com.sssw.wf.xf.core.EboEngine.onRender(EboEngine.java:190)
        at com.sssw.wf.xf.manager.EboProcessManager.onRender(EboProcessManager.java:104)
        at com.novell.afw.portal.portlet.pf.pageFlowRunner.onRender(pageFlowRunner.java:182)
        at com.novell.afw.portal.portlet.pf.baseRunner.doView(baseRunner.java:61)
        at javax.portlet.GenericPortlet.doDispatch(Unknown Source)
        at com.novell.afw.portal.portlet.pf.baseRunner.doDispatch(baseRunner.java:46)
        at javax.portlet.GenericPortlet.render(Unknown Source)
        at com.novell.afw.portlet.core.EboPortletContainer.processOperation(EboPortletContainer.java:698)
        at com.novell.afw.portlet.core.EboPortletContainer.processOperation(EboPortletContainer.java:549)
        at com.novell.afw.portlet.core.EboPortletContainer.getMarkup(EboPortletContainer.java:222)
        at com.novell.afw.portlet.consumer.core.EboPortletConsumerContainer.processOperation(EboPortletConsumerContainer.java:305)
        at com.novell.afw.portlet.consumer.core.EboPortletConsumerContainer.getMarkup(EboPortletConsumerContainer.java:175)
        at com.novell.afw.portal.proxy.EboPortletContainerProxy.getMarkup(EboPortletContainerProxy.java:240)
        at com.novell.afw.portal.aggregation.EboPortletProxyHelper.renderPortlet(EboPortletProxyHelper.java:271)
        at com.novell.afw.portal.aggregation.EboPortalAggregationHelper.runPortletsInTheMainThread(EboPortalAggregationHelper.java:1775)
        at com.novell.afw.portal.aggregation.EboPortalAggregationHelper.renderSynchPortlets(EboPortalAggregationHelper.java:1746)
        at com.novell.afw.portal.aggregation.EboPortalAggregationHelper.callRender(EboPortalAggregationHelper.java:2110)
        at com.novell.afw.portal.aggregation.EboPortalAggregationControllerImpl.initiateRendering(EboPortalAggregationControllerImpl.java:1326)
        at com.novell.afw.portal.aggregation.EboPortalAggregationControllerImpl.renderPortalResponse(EboPortalAggregationControllerImpl.java:531)
        at com.novell.afw.portal.aggregation.EboPortalAggregationServlet.handlePortalContainerRequest(EboPortalAggregationServlet.java:761)
        at com.novell.afw.portal.aggregation.EboPortalAggregationServlet.callService(EboPortalAggregationServlet.java:218)
        at com.novell.afw.portal.aggregation.EboPortalAggregationServlet.doGet(EboPortalAggregationServlet.java:90)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at com.novell.afw.portal.xforms.EboXFormClientDetectionFilter.doFilter(EboXFormClientDetectionFilter.java:97)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
        at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
        at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
        at java.lang.Thread.run(Thread.java:534)

------------------------------------------------------------------------------------
Any ideas of where the flaw could be?

Thanks,
Kollswe

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880505#3880505

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880505

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: JBoss Bean Deployer - JMX Integration

[<sco...@jb...>]

So use both an explicit alias attribute on the legacy mbean for complete control, and allow for a mapping function on the SARDeployer to transform ObjectNames meeting understood patterns to be transformed into a unique alias. The latter should generally be universially applicable as one would expect a convention was in place for all object names. 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880502#3880502

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880502

[Jboss-dev-forums] [Design of Mail Services] - Re: Cont: need help running code from HEAD

[mikezzz <nu...@jb...>]

You probably won't need encryption to work on bugs, but it's probably worth figuring it out at some point for completness and understanding.

Mike.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880496#3880496

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880496

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: JBoss Bean Deployer - JMX Integration

[<ad...@jb...>]

Yes, I would segment the namespace by type IF I were going to do it that way.

The trouble is that it relies on something that does not really exist, i.e.
some notion of an abstract Queue MBean or class/grouping of such MBeans.

Such a notion could be retrofitted to the MBeans with a
getAliasType()/getAliasName()
but that is pretty intrusive to the implementation 
or it requires more xml in the deployment to state it,
or it requires another listener on deployments to generate the alias database
from known patterns in MBean deployments (often with those patterns being conventions
only).

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880489#3880489

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880489

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: JBoss Bean Deployer - JMX Integration

[<sco...@jb...>]

How is the type enabling the namespace management? In you example it would seem that you are carving out a Queue namespace that can be augmented with keys known to be unique in the Queue namespace. So you want a type based name to ObjectName mapping function on the alias aspect of the SARDeployer?


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880486#3880486

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880486

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: JBoss Bean Deployer - deployment names

[<ju...@jb...>]

cool...

foo.bar had some potential too though


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880485#3880485

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880485

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: JBoss Bean Deployer - deployment names

[<ad...@jb...>]

"ju...@jb..." wrote : "ad...@jb..." wrote : 
  |   | What do you want to call the bean deployments?
  |   | 
  | 
  | *.beans ?
  | 
  | Who says everyone has to stick to a stupid three letter convention anyway? We already have *.class
  | 
  | 

That's what I called it in the code I just committed.
So you can have deployments like "full.of.beans" :-)

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880484#3880484

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880484

[Jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Re: Resolving issue JBAS-1801

[<ad...@jb...>]

OK, I'll fix the EAR deployer.

The other issue would be things like the rar deployer not including the "."

  |    public String getExtension()
  |    {
  |       return "rar";
  |    }
  | 
in its checking.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880483#3880483

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880483

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: JBoss Bean Deployer - deployment names

[<ju...@jb...>]

"ad...@jb..." wrote : 
  | What do you want to call the bean deployments?
  | 

*.beans ?

Who says everyone has to stick to a stupid three letter convention anyway? We already have *.class



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880482#3880482

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880482