Problem with Classpath specified in manifest.mf
by sandesh g
Hi All,
I have small issue, I added one jar in system classpath of JBoss
server (ie added to JBOSS_CLASSPATH in run.bat) say mycp.jar. In my jar file
there is a manifest.mf file and I specified the classpath in Manifest file
as below e.g.:
Class-Path: ./regexp.jar ./xmlapi.jar ./cloudscape.jar
My application refers to classes in these jar files. But it looks like it
does not get the classes specified in jars which are added to classpath in
manifest.mf (NoClassDefFoundError for these classes).
If I specify these jars in jboss-service.xml instead then everythig works
fine.
Is there any issue in JBoss with the classpath jar entries in manifest.mf
file?
Note: I have to put these jars in system classpath only. Our this approach
works properly for other AppServers like Weblogic, WebSphere & Pramati.
Your help is highly appreciated!
Thanks & Regards,
Sandesh
--
View this message in context: http://www.nabble.com/Problem-with-Classpath-specified-in-manifest.mf-tp2...
Sent from the JBoss - Dev mailing list archive at Nabble.com.
17 years
Re: [jboss-dev] Splitting system and user deployments
by Jaikiran Pai
Adrian Cole wrote:
> This does lead to another point, the
> lib directory. one way to address this is to put all jboss internal
> stuff under internal and leave the existing lib/deploy to the users.
>
> internal/lib
> internal/deploy
>
> lib <- user libraries
> deploy <- user deployables
>
> WDYT?
> -Adrian Cole
>
In my opinion, the user libraries should be packaged within the user
applications.
regards,
-Jaikiran
>
>
> On Sun, Mar 29, 2009 at 12:30 PM, Jaikiran Pai <jpai(a)redhat.com> wrote:
>
>> I think we already have the
>> BootstrapProfileFactory/SerializableDeploymentRepositoryFactory [1] which we
>> can leverage to take a step towards accomplishing this.
>>
>> As a first step, we could let the "deploy" folder be meant only for
>> JBoss/server specific deployments. We could add a new empty "user-apps" (or
>> any better named folder) at the same level as "deploy" and then ship the
>> server which scans this "user-apps" folder (through an appropriate
>> configuration in the
>> BootstrapProfileFactory/SerializableDeploymentRepositoryFactory). We then
>> start documenting/letting users know that the "deploy" folder is deprecated
>> and the support for user applications in that folder will be removed soon.
>>
>> Some users will continue deploying the application in the system "deploy"
>> folder, but they won't/shouldn't be complaining, if in later releases, we
>> decide to rename the system deploy folder or even do something more drastic.
>>
>> [1] http://www.jboss.org/community/docs/DOC-13241
>>
>>
>> regards,
>> -Jaikiran
>>
>>
>> ||Jason T. Greene wrote:
>>
>>> Hi Everyone,
>>>
>>> One topic that seems to come up often, but yet we never get around to
>>> addressing, is adding a user specific deploy directory that is empty by
>>> default [1].
>>>
>>> If we go this route, what should we call such directories?
>>>
>>> I added a few
>>>
>>> Pros = + Cons = -
>>>
>>> Option A
>>> --------
>>> System = deploy
>>> User = apps
>>>
>>> + Users that expect system configuration files in deploy (like tomcat)
>>> won't be caught off-guard
>>> - Users might not notice the apps directory and put things in deploy
>>> anyway
>>>
>>> Option B
>>> --------
>>> System = system
>>> User = apps
>>>
>>> + Looks nice
>>> - New locations may be hard to find
>>>
>>> Option C
>>> --------
>>> System = system
>>> User = deploy
>>>
>>> + Users can still put apps in deploy, as they expect, and they no longer
>>> see system deployments
>>> - Users will have to find the new config location
>>>
>>>
>>> Option D
>>> --------
>>> System = deploy/system
>>> User = deploy/apps
>>>
>>> + Looks the nicest
>>> + Not too hard to find the new location
>>> - Users will put things in deploy and it won't work!
>>>
>>>
>>> Option E
>>> --------
>>> System = deploy-system
>>> Apps = deploy-apps
>>>
>>> + Putting files in the deploy dir is no longer a problem since it doesn't
>>> exist
>>> + Not too hard to find the new location
>>> - Deploy no longer exists
>>> - Kind of ugly
>>>
>>>
>>> [1] https://jira.jboss.org/jira/browse/JBAS-5954
>>>
>>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>>
17 years
Problem with Classpath specified in Manifest.mf file.
by sandesh g
Hi All,
I have small issue, I added one jar in system classpath of JBoss
server (ie added to JBOSS_CLASSPATH in run.bat) say mycp.jar. In my jar file
there is a manifest.mf file and I specified the classpath in Manifest file
as below e.g.:
Class-Path: ./regexp.jar ./xmlapi.jar ./cloudscape.jar
My application refers to classes in these jar files. But it looks like it
does not get the classes specified in jars which are added to classpath in
manifest.mf (NoClassDefFoundError for these classes).
If I specify these jars in jboss-service.xml instead then everythig works
fine.
Is there any issue in JBoss with the classpath jar entries in manifest.mf
file?
Your help is highly appreciated!
Thanks & Regards,
Sandesh
--
View this message in context: http://www.nabble.com/Problem-with-Classpath-specified-in-Manifest.mf-fil...
Sent from the JBoss - Dev mailing list archive at Nabble.com.
17 years
New thread management in appserver deployments
by David M. Lloyd
Since 5.1.0.Beta1, there is a new way to define thread pools, thread
factories, and other thread-related stuff. If you've got a service
(especially a POJO-ized service) that is deployed in the AS, I recommend
that you have a look at migrating your deployment to use this new mechanism.
The project is called JBoss Threads, and there's a bug tracker for it here:
https://jira.jboss.org/jira/secure/project/ViewProject.jspa?pid=12310786
The idea is that you can declare a thread pool in your service deployment
descriptor, and then you can inject this thread pool as an Executor into a
managed bean, sort of like this example jboss-beans.xml file:
<deployment xmlns="urn:jboss:bean-deployer:2.0">
<threads xmlns="urn:jboss:threads:1.0">
<thread-group name="MyThreadGroup" group-name="mine"/>
<thread-factory name="MyThreadFactory" group="MyThreadGroup"
thread-name-pattern="my-pool%f-%t"/>
<thread-pool-executor name="MyExecutor"
thread-factory="MyThreadFactory" allow-core-timeout="true" queue-length="50">
<core-pool-size count="5"/>
<max-pool-size count="10" per-cpu="2"/>
<keepalive-time time="10" unit="seconds"/>
<reject-policy name="block"/>
</thread-pool-executor>
</threads>
<bean class="your.bean.Class">
<property name="executor">
<inject bean="MyExecutor"/>
</property>
</bean>
</deployment>
This example makes a thread pool executor that has no threads until tasks
are submitted, and keeps idle threads around for 10 seconds before cleaning
them up. The pool will not grow larger than 10 threads plus 2 threads per
detected CPU.
If your component already expects an injected Executor, then this should be
a trivial change to make. This implementation does not implement the older
ThreadPool-related interfaces from jboss-common-core. My personal
inclination is to leave it off and migrate to a fully Executor-based
system. Things that require functionality only provided by the older API
could perhaps still be accomodated by some kind of wrapper mechanism, if
necessary.
There are some todo items, like developing a mechanism to automatically
propagate relevant contextual information from the executing thread to the
executor thread (including but not limited to the thread context class
loader). I'd like to develop a more generic mechanism though (the idea
being that the average user can inject an Executor to use from any old
deployment, and everything that can just magically work, will). Ideas are
welcome. :-) Also, there is no JMX management view yet (this is a TODO for
CR1).
The advantage to this model is that implementation details (class name,
property names) of the thread pool are no longer specified in the
deployment descriptor, which means that the class can change under certain
circumstances (in fact, the class is already substituted when there are
parameter combinations which are not supported by the standard
ThreadPoolExecutor). This is a model I hope that we can continue to move
towards.
- DML
17 years
AS 5.1.CR1 component updates
by Dimitris Andreadis
Please make sure you get your component updates in by April/20th, the freeze date.
https://jira.jboss.org/jira/browse/JBAS-6552
jboss-profiler-jvmti - Clebert Suconic
apache-beanutils - David Walluck
JBoss Negotiation - Darran Lofthouse
jboss-metadata - Alexey Loubyansky
JBossXB - Alexey Loubyansky
JPA - Carlo de Wolf
jboss-managed - Scott M Stark
jboss-ha-server-api - Paul Ferraro
JBossWS Native - Alessio Soldano
JAXB - Shelly McGowan
JBoss Cache - Brian Stansberry
AOP - Kabir Khan
We have 4 weeks left, so the earlier the updates are made the better, so we have time to
test them.
If something should be added or removed from the list, speak up!
Cheers
/Dimitris
17 years
Maven Issues
by Paul Gier
Hey Guys,
I was asked to put together a list of issues/problems/features with maven that
we would like to see improved. Please let me know of any specific things that
you want in the near future and I will add them to the list.
Thanks!
17 years
