You seem to be fundamentally misunderstanding something. Your specific item types, like Weapon, shouldn't contain an item. That isn't going to help you at all. For a purely componentized approach, your item class should hold a list (or map) of Components. Specific components give the item its properties.
For example, you would have a Component base class and some subclasses might be WeaponComponent and BuffComponent. Your Item class maintains properties common to all items, like durability, weight, isTradeable, or whatever. A WeaponComponent would maintain properties that differentiate weapons from other items, damageAmount, damageType, requiredSkill, and so on. Using this approach, you could define your weapon components in a JSON file (or YAML/XML/Take Your Pick). Swords, maces, and bows become defined purely by data, rather than by concrete classes. Then, when you load in a weapon, you can do something like this:
WeaponComponent weapon = new WeaponComponent( /* values from wherever go here */ );
Item item = new Item( /* item values for this particular weapon * / );
item.addComponent( weapon );
// Let's make it magic
BuffComponent buff = new BuffComponent( /* buff values from somewhere */ );
item.addComponent( buff );
itemsList.add( item );
Using this, you can turn any item in the game, such as a chair, into a weapon. You can give any item, whether it's a weapon or not, a magic buff. It gives you a great deal of flexibility. However, you also increase the complexity a bit. For one thing, you'll need a way to tell if an item has a specific component or not. For example, when the player wants to attack an NPC, you'll want to check if the item he selects to attack with actually has a weapon component. How you do this mostly depends on what sort of container you choose to hold an Item's components, but also whether you want the item types to be fixed or want to allow modders to add new items, and so on.
Between the extreme of the purely data-driven component-based approach and the other extreme of the strict class hierarchy lies a middle ground where you can come up with a sort of hybrid system. In other words, there is more than one way to skin this cat. Every approach will come with its pros and cons. For games that are small in scope and that don't need the benefits of a component-based system, the class hierarchy is perfectly fine. Implementing one of these systems is the easy part. The hard part in making yourself aware of all of the options available to you and learning how to choose the approach that fits your needs.
